> 
> 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?
> 

I have also seen this. I was investigating this stable bad behaviour and 
then .. it went away. Gah! I have not (yet) been able to make it do it 
again except that on my E1 board a reboot of the kernel sometimes spits out 
loads of bad blocks where it was working fine. After I sort out bootldr 
(again) I need to look at this. Note that the balloon mtd nand interface is 
using absolute timings to wait for the nand to become ready (no ready/busy 
line available to linux yet - being fixed). For 2k nand I had to increase 
it. If you probelem is repeatable, maybe testing it with a higher value on 
512b nand might change its behaviour.

Nick Bane

> Paul Fidler