[Balloon] Nand/Yaffs Wierdness?

I have a Balloon 3 (P2) that has spent most of the afternoon spitting
out error messages like this whenever I've tried to boot it:

BUG: soft lockup detected on CPU#0!

Pid: 711, comm: depmod CPU: 0 PC is at nand_read_byte+0x18/0x20 LR is at
nand_command+0x114/0x1f4 pc : [<c0145850>] lr : [<c0145ea4>] Not tainted sp
: c3cbd9cc ip : c3cbd9dc fp : c3cbd9d8 r10: 00000000 r9 : 00000000 r8 :
ffffffff r7 : 000000ff r6 : c3c46000 r5 : c3c46180 r4 : ffffffff r3 :
c3c46180 r2 : c4812000 r1 : c4814014 r0 : 00000000 Flags: nZcv IRQs on FIQs
on Mode SVC_32 Segment user Control: 397F Table: A3AB4000 DAC: 00000015
[<c002393c>] (show_regs+0x0/0x4c) from [<c00595f0>]
(softlockup_tick+0x68/0x80)
r4 = C3CBD984 [<c0059588>] (softlockup_tick+0x0/0x80) from [<c0043804>]
(do_timer+0x70/0x10c)
r4 = 00000001 [<c0043794>] (do_timer+0x0/0x10c) from [<c0026ecc>]
(timer_tick+0xe0/0x134) [<c0026dec>] (timer_tick+0x0/0x134) from
[<c002d488>] (pxa_timer_interrupt+0x34/0x84)
r6 = 00000001 r5 = C3CBD984 r4 = F2A00000 [<c002d454>]
(pxa_timer_interrupt+0x0/0x84) from [<c0022980>] (__do_irq+0x4c/0x90)
r8 = 00000000 r7 = 0000001A r6 = C3CBD984 r5 = 00000000
r4 = C027B2F8
[<c0022934>] (__do_irq+0x0/0x90) from [<c0022bd0>] (do_level_IRQ+0x68/0xc0)
r8 = FFFFFFFF r7 = 000000FF r6 = C3CBD984 r5 = 0000001A
r4 = C02D22C8 [<c0022b68>] (do_level_IRQ+0x0/0xc0) from [<c0022d70>]
(asm_do_IRQ+0x4c/0x74)
r6 = 04000000 r5 = C3CBD9B8 r4 = C3CBD984
[<c0022d24>] (asm_do_IRQ+0x0/0x74) from [<c0021924>] (__irq_svc+0x24/0x60)
r4 = FFFFFFFF [<c0145838>] (nand_read_byte+0x0/0x20) from [<c0145ea4>]
(nand_command+0x114/0x1f4) [<c0145d90>] (nand_command+0x0/0x1f4) from
[<c0147a20>] (nand_write_oob+0xc8/0x22c)
r8 = C3C46000 r7 = C3C46180 r6 = FFFFFFFB r5 = FFFFFFFF
r4 = 00000000 [<c0147958>] (nand_write_oob+0x0/0x22c) from [<c013aed4>]
(part_write_oob+0x78/0xb0) [<c013ae5c>] (part_write_oob+0x0/0xb0) from
[<c00c5780>] (nandmtd_WriteChunkToNAND+0x108/0x114)
r6 = C3DAF600 r5 = 00000000 r4 = 00F83E00 [<c00c5678>]
(nandmtd_WriteChunkToNAND+0x0/0x114) from [<c00c4eb0>]
(yaffs_WriteChunkToNAND+0x4c/0x54)
r8 = C3CBDAB8 r7 = 00000000 r6 = C3DEF000 r5 = 00000000
r4 = 00007C1F [<c00c4e64>] (yaffs_WriteChunkToNAND+0x0/0x54) from
[<c00c5354>] (yaffs_TagsCompatabilityWriteChunkWithTagsToNAND+0xf0/0xfc)
r6 = 00007C1F r5 = C3DEF000 r4 = C3CBDB1C [<c00c5264>]
(yaffs_TagsCompatabilityWriteChunkWithTagsToNAND+0x0/0xfc) from
[<c00c603c>] (yaffs_WriteChunkWithTagsToNAND+0xac/0x114) [<c00c5f90>]
(yaffs_WriteChunkWithTagsToNAND+0x0/0x114) from [<c00bfed0>]
(yaffs_DeleteChunk+0x20c/0x264)
r8 = 00000000 r7 = 00007C3F r6 = 000003E1 r5 = C3DEF000
r4 = C3CBDB1C [<c00bfcc4>] (yaffs_DeleteChunk+0x0/0x264) from [<c00bccfc>]
(yaffs_HandleWriteChunkError+0x94/0xb4) [<c00bcc68>]
(yaffs_HandleWriteChunkError+0x0/0xb4) from [<c00bcb80>]
(yaffs_WriteNewChunkWithTagsToNAND+0xc0/0xe0)
r6 = 00000000 r5 = C3DEF000 r4 = 00007C3F [<c00bcac0>]
(yaffs_WriteNewChunkWithTagsToNAND+0x0/0xe0) from [<c00bffac>]
(yaffs_WriteChunkDataToObject+0x84/0xc8) [<c00bff28>]
(yaffs_WriteChunkDataToObject+0x0/0xc8) from [<c00c1854>]
(yaffs_WriteDataToFile+0x2a0/0x2bc) [<c00c15b4>]
(yaffs_WriteDataToFile+0x0/0x2bc) from [<c00ba98c>]
(yaffs_file_write+0x98/0x190) [<c00ba8f4>] (yaffs_file_write+0x0/0x190)
from [<c00ba560>] (yaffs_commit_write+0x90/0x160) [<c00ba4d0>]
(yaffs_commit_write+0x0/0x160) from [<c005c074>]
(generic_file_buffered_write+0x26c/0x614) [<c005be0c>]
(generic_file_buffered_write+0x4/0x614) from [<c005c67c>]
(__generic_file_aio_write_nolock+0x260/0x500) [<c005c41c>]
(__generic_file_aio_write_nolock+0x0/0x500) from [<c005ca28>]
(__generic_file_write_nolock+0x84/0xb0) [<c005c9a4>]
(__generic_file_write_nolock+0x0/0xb0) from [<c005cc48>]
(generic_file_write+0x48/0xbc) [<c005cc00>] (generic_file_write+0x0/0xbc)
from [<c007a6bc>] (vfs_write+0xc0/0x184) [<c007a5fc>] (vfs_write+0x0/0x184)
from [<c007a84c>] (sys_write+0x50/0x7c) [<c007a7fc>] (sys_write+0x0/0x7c)
from [<c0021ca0>] (ret_fast_syscall+0x0/0x2c)
r9 = C3CBC000 r8 = C0021E44 r7 = 00000004 r6 = 000185F8
r5 = 00001000 r4 = 40330000
**>> Block 993 retired
**>> yaffs chunk 31808 was not erased
**>> yaffs chunk 31809 was not erased
**>> yaffs chunk 31810 was not erased
**>> yaffs chunk 31811 was not erased
**>> yaffs chunk 31812 was not erased
**>> yaffs chunk 31813 was not erased
**>> yaffs chunk 31814 was not erased
**>> yaffs chunk 31815 was not erased
**>> yaffs chunk 31816 was not erased
**>> yaffs chunk 31817 was not erased
**>> yaffs chunk 31818 was not erased
**>> yaffs chunk 31819 was not erased
**>> yaffs chunk 31820 was not erased
**>> yaffs chunk 31821 was not erased
**>> yaffs chunk 31822 was not erased
**>> yaffs chunk 31823 was not erased
**>> yaffs chunk 31824 was not erased
**>> yaffs chunk 31825 was not erased

It keeps doing this (but with progressively higher chunk numbers) until
grinding to a halt after several minutes. It also occasionally throws
out a message about retiring a block.

This evening however, it has started behaving normally again and it
boots all the way through to the login prompt, but I hadn't done anything
to it to try and fix it.


The same board was producing similar 'yaffs chunk n was not erased'
messages on Thursday, but while trying to download a big file via zmodem,
not while booting. On that occasion the only way to cure it and get a
stable system again was a force-erase of the nand. (A non-forced erase
didn't seem to work). It's been back to TCL and there doesn't seem to be
anything wrong with the hardware. TCL were also able to cure it by doing a
force-erase and managed to squirt several MBs over zmodem without
reproducing any sysmptons.

Any suggestions as to what's going on? Is it just encountering bad nand
that's been marked as good (thanks to the forced erasing), or is there
something else going on?


Paul Fidler
--
Cambridge University Engineering Department | Tel: +44 1223 332816
Trumpington Street, Cambridge, CB2 1PZ, UK | Fax: +44 1223 332662