On Fri, 2003-03-07 at 18:27, Wisor, Eugene wrote:
> Greetings,
>
> I've been working on resolving a jffs2 problem I'm seeing on initialization.
> I now have a kernel patch (listed below) that seems to resolve the problems.
>
> Here is some background:
>
> We are using a 2.4.19-rmk4-pxa2-hh8 kernel built from source and configured
> for our application. We create a separate jffs2 partition that is used to
> store user configuration data and files. By default, it is initially empty.
> To initially set it up, we simply erase the partition via the bootloader
> "eflash config" command (instead of loading an empty jffs2 image file). We
> then boot to Linux and mount it as a jffs2 filesystem on initialization.
> The jffs2 drivers then detect the partition is erased but not formatted and
> automatically formats it.
>
> However, we discovered a bug in recent handheld kernels that does not
> correctly format the erased partition. As a result, the following console
> messages are reported the next time the partition is mounted:
>
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000:
> 0x2003 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004:
> 0x000c instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008:
> 0xdc6d instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040000:
> 0x2003 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040004:
> 0x000c instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040008:
> 0xdc6d instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00080000:
> 0x2003 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00080004:
> 0x000c instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00080008:
> 0xdc6d instead
> .
> .
> .
>
> The incorrectly formatted filesystem may or may not mount, depending on
> whether any good blocks are found.
>
> I found that the jffs2 magic bitmask was not being correctly set in
> jffs2_mark_erased_block().
>
> Specifically, the jffs2_unknown_node marker structure initialization code
> that initializes the nodetype member also overwrites the magic member that
> was previously set. I carefully inspected this marker structure
> initialization code but did not see a cause for the failure.
>
> In fact, it bug appears to be a compiler related code generation bug since
> the magic member is not overwritten when the members are initialized outside
> the marker declaration. See the workaround patch below for clarification.
> I'm not sure if it is the correct and final fix but at least it works.
Which compiler were you using? I do not think I have seen this problem
with arm-linux-gcc 2.95.3 nor with arm-linux-gcc 3.2.1.
-Jamey
Received on Sat Mar 08 14:20:08 2003
This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:45:01 EDT