RE: [iPAQ] Patch for bug found in linux/kernel/fs/jffs2/erase.c

Jamey,

I'm using GCC v3.2 from a pre-built toolchain available at

ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain/cross-3.2.tar.gz

I picked it since it was referenced in a number of postings on this list and
at the time (2-3 month ago) and it seemed to be the consensus choice of the
pre-built ones. I realize other pre-built options are now available.

I'm willing to switch to another toolchain, especially a pre-built one that
you guys have been using.

Any suggestions?

Thanks,

*E

-----Original Message-----
From: Jamey Hicks [mailto:jamey.hicks@hp.com]
Sent: Saturday, March 08, 2003 6:15 AM
To: Wisor, Eugene
Cc: 'ipaq@handhelds.org'; 'David Woodhouse'
Subject: Re: [iPAQ] Patch for bug found in linux/kernel/fs/jffs2/erase.c

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 Mon Mar 10 17:45:55 2003