Hi Robert,
Thanks for the reply. Here is the status of each of my issues. I think
Issues 1,2,4 of mine are simple compilation issues that should still be
fixed and for issues 3,5 I tried to explain them better to make sure wasn't
doing anything wrong.
For Issue 4:
----------------------------
Thanks for finding that previous submission, I didn't see it was already
posted. Looks like it is still unfixed - how/when will this be implemented?
I'd like to fix this for others if possible.
For Issue 1:
----------------------------
I don't think you have the compilation error for my "issue 1" regarding the
zero_user_segment(...) function because of the "#if" before that checks the
linux kernel version. Compilation for the zero_user_segment(...) only
happens if the kernel version is less than version 2,6,25. My kernel is
before this and yours is after that, which is why I see the issue and you
don't. I'm guessing if you remove the #if around the
zero_user_segment(...), your yaffs won't compile - just as a double check
if you really wanted to. Either way, the function zero_user_segment(...)
should still be moved above where it is used in yaffs_vfs.c.
For Issue 2:
----------------------------
Similar to Issue #1, I don't think you saw this issue because of the "#if
(LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 28))" surrounding the macro.
Again, your linux kernel version is greater than the checked version, while
mine is less. This is why lowering the Kernel Version check from 2,6,28 to
2,6,17 allows for my kernel version to compile, while yours and probably
most every other user's kernel compiles fine.
It looks like issues 1 and 2 for me are from using a really old kernel
version that probably doesn't get tested much. I believe the version I'm
using (2.6.18), should be supported right, or is there a minimum kernel
version I am unaware of?
Issue 3:
-----------------------------
Thanks - I didn't see the mounting option for ecc tags that seems to work
too. I was merely concerned that changing my menuconfig options didn't
actually do anything regarding the no_tags_ecc. It was just really
misleading to change an option in the menuconfig that doesn't actually do
anything. If passing a flag in during mount is the standard way to do this,
I'd like to see the "Disable yaffs from doing ECC on tags by default"
kernel option removed from the menuconfig as it doesn't do anything (or at
least it doesn't for me...). Otherwise, adding my fix allows for the
menuconfig option to be checked and used.
What happens if you don't use the mount option, then try and change the
menuconfig option for Ecc on tags? I'd be curious to see if the value of
your "param0>no_tags_ecc" properly changes with the menuconfig option.
Adding a printk in yaffs_vfs.c in function yaffs_internal_read_super(...),
on approx. line 2870, right above where the tags are checked: "if
(options.tags_ecc_overridden)".
Issue 5:
-----------------------------
I'll just disable this auto checking for my use - doesn't sound like this
is an issue for other people. For updating my system, updating the kernel
causes the FileSystem to become unbootable because yaffs code does an
auto-check and says inband tags should be on, which is fine. The problem
happens when the FileSystem that is currently installed on the device does
not have inband tags, then on the next power-cycle yaffs assumes in-band
tags should be on when they aren't. Then the format of the FileSystem is
out of sync / wrong with the configuration. Hopefully that makes sense?
This is just a problem from going from an old to new version of yaffs where
the inband tags option changes. If I do a fresh install of the FileSystem,
there is no issue as the FileSystem is written with the tags and is assumed
to have them enabled too.
-
Sean Seifert
EMBEDDED SOFTWARE ENGINEER
Appareo Systems, LLC
1810 NDSU Research Circle N
Fargo ND
58102
P: (701) 356-2200 Ext 349
F: (701) 356-3157
sseifert@appareo.com
NOTICE: This message {including attachments} is covered by the Electronic
Communication Privacy Act, 18 U.S.C. sections 2510-2521, is confidential
and may also be protected by attorney-client or other privilege. If you
believe that it has been sent to you in error, do not read it. If you are
not the intended recipient, you are hereby notified that any retention,
dissemination, distribution, or copying of this communication is strictly
prohibited. Please reply to the sender that you have received the message
in error and then delete it.
On Tue, Oct 28, 2014 at 2:50 PM, Robert Calhoun <
rcalhoun@shotspotter.com>
wrote:
> (My apologies if you receive this twice; I sent from the wrong account)
>
> From: Sean Seifert <sseifert@appareo.com>
> Date: 22 Oct 2014 6:26 PM
> To: "yaffs@lists.aleph1.co.uk" <yaffs@lists.aleph1.co.uk>
> Subject: [Yaffs] Current Yaffs2 Compilation Bugs with Some Fixes
>
> (...)
>
> *Issue 4 (w/ fix):*
>
> *------------------------------------------------------------------------------------------------------*
> Compilation broke on commit: 30f956c32c235e6b5fa77fb29965ababbd497561,
> Jul 22, 2014. Not all functions were updated for the new discard parameter.
> Here are the following that have been missed that discard parameter:
> fs/yaffs2/yaffs_vfs.c:2205: error: too few arguments to function
> ‘yaffs_flush_whole_cache’
> fs/yaffs2/yaffs_vfs.c:751: error: too few arguments to function
> ‘yaffs_flush_file’
> fs/yaffs2/yaffs_vfs.c:781: error: too few arguments to function
> ‘yaffs_flush_file’
> fs/yaffs2/yaffs_vfs.c:2192: error: too few arguments to function
> ‘yaffs_flush_file’
>
> Simply adding the extra discard parameter to these functions makes
> compilation work. What is the proper number to pass to each? I added a "1"
> to each for the sake of getting this compiling in my code, but want to make
> sure that the correct parameter gets passed into the functions.
>
> (...)
>
>
> I can reproduce Sean Seifert's issue #4, also reported by
> wikimfw@lotte.net in September.
>
> I am also compiling an updated version of yaffs on an older kernel
> (2.6.34) following our discovery of very severe data corruption issues
> traced to the obsolete version of yaffs we were using
> (99c62e39578113a798483b5dc6c13a80737163f1 on branch yaffs2, from March
> 2010.) Thank you to William Juul for his help in diagnosing this!
>
> Like Sean Seifert I could not get yaffs master HEAD to compile due the
> inconsistent definitions of yaffs_flush_file() in yaffs_guts and yaffs_vfs.
>
> Rather than modify the source I rolled back to the commit before the new
> cache policy changes (to 4e188b08c5531f99f73383a85251e03a1e667b26, "Update
> to support Linux 3.14/3.15") and was able to successfully build using that
> tree. We are now testing that build for deployment.
>
>
> Question for Charles Manning/branch maintainers: Is there some release
> branch we should be using in lieu of integrating branch master at an
> arbitrary commit? Master seems like a work in progress at the moment.
>
>
> re: Sean Seifert's issues 1 and 2:
> I did not encounter these with kernel 2.6.34 and an (old-ish) version
> of gcc (4.4.7).
>
> re: Sean Seifert's issues 3 and 5:
> Sean, if I read your email correctly you have a yaffs2 system with
> out-of-band tags and no yaffs ECC on those tags.
>
> Our defconfig (old and new) use the default (do not disable tag ECC) i.e.
> # CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
> so we did not encounter this problem.
>
> The Kconfig documentation says "This behavior can also be overridden
> with tags_ecc_on and tags_ecc_off mount options" so you may be able to
> compile with ECC tags on but then disable tag ECC at runtime with your
> kernel command line mount argument and still mount your filesystem.
>
> Based on /proc/yaffs we are using out-of-band area for tags. It is
> probably desirable to to have YAFFS do ECC on the tags, because in many
> flash devices the OOB area is not entirely protected by ECC. For example we
> use Micron MT29F2G16ABBEAHC, which I believe is a typical SLC NAND device.
> It has 16 OOB bytes (2 bytes bad block marker, 8 bytes ECC parity, 6 bytes
> "user data") for each 512 byte partial page, so a full 2048-byte page has 6
> * 4 = 24 user bytes, which are not fully protected by ECC using either the
> on-chip correction or (SoC controller + MTD driver). I assume this is why
> YAFFS does tag ECC by default on OOB tags even when the user data is
> protected at the MTD layer and below.
>
> I find the whole use of OOB a bit difficult to follow.
> yaffs_packed_tags2 seems to comprise (4 x uint32) of tag data plus (uint8,
> uint32, unit32) of ECC data for a total of 25 bytes, one byte more than
> space available for user data. Clearly there is something I am not
> understanding here.
>
> Anyway, we are using the following defconfig:
>
> CONFIG_YAFFS_FS=y
> CONFIG_YAFFS_YAFFS1=y
> # CONFIG_YAFFS_9BYTE_TAGS is not set
> # CONFIG_YAFFS_DOES_ECC is not set
> CONFIG_YAFFS_YAFFS2=y
> CONFIG_YAFFS_AUTO_YAFFS2=y
> # CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
> CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED=y
> # CONFIG_YAFFS_EMPTY_LOST_AND_FOUND is not set
> # CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is not set
> # CONFIG_YAFFS_DISABLE_BACKGROUND is not set
> # CONFIG_YAFFS_DISABLE_BAD_BLOCK_MARKING is not set
> CONFIG_YAFFS_XATTR=y
>
> and are able to read our existing filesystem without issues. These are
> all defaults set by patch-ker.sh for 2.6.34 except
> for CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED, which I carried forward from
> our old defconfig.
>
>
> -Rob Calhoun
>
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
>
(text/plain)