I previous reported problems with jffs2 on the Zaurus. I tested
2.6.18-rc4 and nothing has changed - I see the following when booting,
both with filesystems that work with 2.6.17 and freshly reflashed
systems:
Linux version 2.6.18-rc4-.dev-snapshot-20060807 (richard@tim) (gcc version 3.4.3) #1 PREEMPT Mon Aug 7 17:47:07 BST 2006
CPU: XScale-PXA250 [69052904] revision 4 (ARMv5TE), cr=0000397f
Machine: SHARP Poodle
[...]
Sharp SL series flash device: 800000 at 0
Using static partision definition
Creating 1 MTD partitions on "sharpsl-flash":
0x00120000-0x007f0000 : "Boot PROM Filesystem"
NAND device: Manufacturer ID: 0x98, Chip ID: 0x76 (Toshiba NAND 64MiB 3,3V 8-bit)
Scanning device for bad blocks
Creating 3 MTD partitions on "sharpsl-nand":
0x00000000-0x00700000 : "System Area"
0x00700000-0x01d00000 : "Root Filesystem"
0x01d00000-0x04000000 : "Home Filesystem"
[...]
Empty flash at 0x0054bc5c ends at 0x0054be00
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing init memory: 100K
JFFS2 error: (472) jffs2_get_inode_nodes: short read at 0x074e84: 68 instead of 380.
JFFS2 error: (472) jffs2_do_read_inode_internal: cannot read nodes for ino 153, returned error is -5
The empty flash warning is probably due to a slightly corrupted image
due to a reboot. The last two messages appear on freshly flashed images
on both this and other Zaurus devices (all using nand/sharpsl.c).
Experience shows I can lock the device up with filesystem corruption if
I use the device :-(.
Does anyone know what the problem is or have an idea of where I should
start debugging this?
Regards,
Richard
On Mon, 07 Aug 2006 19:41:50 +0100
Richard Purdie <[email protected]> wrote:
> I previous reported problems with jffs2 on the Zaurus. I tested
> 2.6.18-rc4 and nothing has changed - I see the following when booting,
> both with filesystems that work with 2.6.17 and freshly reflashed
> systems:
>
> Linux version 2.6.18-rc4-.dev-snapshot-20060807 (richard@tim) (gcc version 3.4.3) #1 PREEMPT Mon Aug 7 17:47:07 BST 2006
> CPU: XScale-PXA250 [69052904] revision 4 (ARMv5TE), cr=0000397f
> Machine: SHARP Poodle
> [...]
> Sharp SL series flash device: 800000 at 0
> Using static partision definition
> Creating 1 MTD partitions on "sharpsl-flash":
> 0x00120000-0x007f0000 : "Boot PROM Filesystem"
> NAND device: Manufacturer ID: 0x98, Chip ID: 0x76 (Toshiba NAND 64MiB 3,3V 8-bit)
> Scanning device for bad blocks
> Creating 3 MTD partitions on "sharpsl-nand":
> 0x00000000-0x00700000 : "System Area"
> 0x00700000-0x01d00000 : "Root Filesystem"
> 0x01d00000-0x04000000 : "Home Filesystem"
> [...]
> Empty flash at 0x0054bc5c ends at 0x0054be00
> VFS: Mounted root (jffs2 filesystem) readonly.
> Freeing init memory: 100K
> JFFS2 error: (472) jffs2_get_inode_nodes: short read at 0x074e84: 68 instead of 380.
> JFFS2 error: (472) jffs2_do_read_inode_internal: cannot read nodes for ino 153, returned error is -5
>
> The empty flash warning is probably due to a slightly corrupted image
> due to a reboot. The last two messages appear on freshly flashed images
> on both this and other Zaurus devices (all using nand/sharpsl.c).
>
> Experience shows I can lock the device up with filesystem corruption if
> I use the device :-(.
>
> Does anyone know what the problem is or have an idea of where I should
> start debugging this?
>
Nope, but please be sure to take a block-level copy of the filesystem so
that you and others can reproduce the problem.
Richard Purdie wrote:
> JFFS2 error: (472) jffs2_get_inode_nodes: short read at 0x074e84: 68 instead of 380.
> JFFS2 error: (472) jffs2_do_read_inode_internal: cannot read nodes for ino 153, returned error is -5
>
This looks like an MTD problem, not JFFS2.
Try to reproduce this on the mtdram flash emulator. Also, please, check
if mtd->writesize is correct at your setup (I suppose your flash is NOR
and it has to be 1).
--
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Artem B. Bityutskiy
> Sent: Tuesday, August 08, 2006 9:15 AM
> To: Richard Purdie
> Cc: linux-mtd; LKML
> Subject: Re: 2.6.18-rc4 jffs2 problems
>
> Richard Purdie wrote:
> > JFFS2 error: (472) jffs2_get_inode_nodes: short read at
> 0x074e84: 68 instead of 380.
> > JFFS2 error: (472) jffs2_do_read_inode_internal: cannot
> read nodes for ino 153, returned error is -5
> >
> This looks like an MTD problem, not JFFS2.
>
> Try to reproduce this on the mtdram flash emulator. Also,
> please, check
> if mtd->writesize is correct at your setup (I suppose your
> flash is NOR
> and it has to be 1).
>
> --
> Best Regards,
> Artem B. Bityutskiy,
> St.-Petersburg, Russia.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
I am currently updating a nand flash driver that used to work
with kernel 2.6.16-rc4 to current git. Doing so, I encountered
exactly this problem, but suspected a problem with my driver,
of course. However, so far I have not been able to find out
what's wrong. Another symptom I observed is that when doing
'ls -l /dev/mtdblock0', the size displayed is zero.
tk
-----------------------------------------------
Thomas Koeller, Software Development
Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany
Tel +49 (4102) 463-390
Fax +49 (4102) 463-46390
mailto:[email protected]
http://www.baslerweb.com
Read the return value before we release the nand device otherwise the
value can become corrupted by another user of chip->ops, ultimately
resulting in filesystem corruption.
Signed-off-by: Richard Purdie <[email protected]>
---
This fixes the jffs2 errors and filesystem corruption I reported. It
should be applied for 2.6.18.
drivers/mtd/nand/nand_base.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Index: git/drivers/mtd/nand/nand_base.c
===================================================================
--- git.orig/drivers/mtd/nand/nand_base.c 2006-08-17 22:46:19.000000000 +0100
+++ git/drivers/mtd/nand/nand_base.c 2006-08-17 22:47:27.000000000 +0100
@@ -1093,9 +1093,10 @@ static int nand_read(struct mtd_info *mt
ret = nand_do_read_ops(mtd, from, &chip->ops);
+ *retlen = chip->ops.retlen;
+
nand_release_device(mtd);
- *retlen = chip->ops.retlen;
return ret;
}
@@ -1691,9 +1692,10 @@ static int nand_write(struct mtd_info *m
ret = nand_do_write_ops(mtd, to, &chip->ops);
+ *retlen = chip->ops.retlen;
+
nand_release_device(mtd);
- *retlen = chip->ops.retlen;
return ret;
}
On 8/17/06, Richard Purdie <[email protected]> wrote:
> Read the return value before we release the nand device otherwise the
> value can become corrupted by another user of chip->ops, ultimately
> resulting in filesystem corruption.
>
We have multiple confirmations that this patch fixes the issue
reported. I agree it should go in 2.6.18.
Greg, can you add this to your tree?
> Signed-off-by: Richard Purdie <[email protected]>
Acked-by: Josh Boyer <[email protected]>
josh
On Sat, Aug 19, 2006 at 08:34:46PM -0500, Josh Boyer wrote:
> On 8/17/06, Richard Purdie <[email protected]> wrote:
> >Read the return value before we release the nand device otherwise the
> >value can become corrupted by another user of chip->ops, ultimately
> >resulting in filesystem corruption.
> >
>
> We have multiple confirmations that this patch fixes the issue
> reported. I agree it should go in 2.6.18.
>
> Greg, can you add this to your tree?
Add what to what tree? I need things to be a bit more specific here :)
thanks,
greg k-h
On Sun, 2006-08-20 at 18:35 -0700, Greg KH wrote:
> Add what to what tree? I need things to be a bit more specific
> here :)
I think he means the tree you were keeping while Linus was away. I'll
sort out this and one or two more to send to Linus shortly.
--
dwmw2
On 8/22/06, David Woodhouse <[email protected]> wrote:
> On Sun, 2006-08-20 at 18:35 -0700, Greg KH wrote:
> > Add what to what tree? I need things to be a bit more specific
> > here :)
>
> I think he means the tree you were keeping while Linus was away. I'll
> sort out this and one or two more to send to Linus shortly.
Yeah, I did. Sorry, I can see how that was confusing. Richard was
kind enough to follow up by sending the patch directly to Greg.
josh