Thanks for the feedback!

I failed to mention we NEVER see a data ECC error, which means to me 
that the data is getting written out the the NAND along with the 
oob/data ECC correctly.

A scenario we do see, although it points to something that corrupted the 
file system in the before "this" reboot, is an oops when we reboot:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
Internal error: Oops: 7
CPU: 0
pc : [<c00844f0>]    lr : [<0000000d>]    Not tainted
sp : c0c95ef4  ip : 00000000  fp : c0c95f04
r10: 401e564c  r9 : c0c94000  r8 : c001a6c4
r7 : c01464e8  r6 : c0146474  r5 : c3ee8000  r4 : c3ee8000
r3 : 00000000  r2 : 00000005  r1 : 00000001  r0 : 00000000
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 397F  Table: A3F64000  DAC: 00000015
Stack: (0xc0c95ef4 to 0xc0c96000)
5ee0: 00000000 c0c95f1c c0c95f08
5f00: c007ea4c c008444c c3ee8000 c01462c4 c0c95f34 c0c95f20 c007ec18 
c007ea2c
5f20: c3ee8000 c3ee9000 c0c95f4c c0c95f38 c0079160 c007ebcc c3ee9000 
c3ee9044
5f40: c0c95f6c c0c95f50 c0050ccc c0079124 00000000 c0c95f70 00000000 
00000016
5f60: c0c95fa4 c0c95f70 c0063804 c0050b94 c3edeca0 c02fe420 00000000 
401e564c
5f80: c0c95fac 00000009 00000001 00149ad0 00149ae8 00149ae8 00000000 
c0c95fa8
5fa0: c001a520 c00637c0 00149ad0 c0020754 00149ae8 00149aea 00149ad2 
00000075
5fc0: 00149ad0 00149ae8 00149ae8 00000000 0000cf5c 00000000 401e564c 
00000000
5fe0: 000779cc bfffee58 000553cc 40195454 a0000010 00149ae8 00000000 
00000000
Backtrace:
Function entered at [<c0084440>] from [<c007ea4c>]
 r4 = 00000000
Function entered at [<c007ea20>] from [<c007ec18>]
 r5 = C01462C4  r4 = C3EE8000
Function entered at [<c007ebc0>] from [<c0079160>]
 r5 = C3EE9000  r4 = C3EE8000
Function entered at [<c0079118>] from [<c0050ccc>]
 r5 = C3EE9044  r4 = C3EE9000
Function entered at [<c0050b88>] from [<c0063804>]
 r7 = 00000016  r6 = 00000000  r5 = C0C95F70  r4 = 00000000
Function entered at [<c00637b4>] from [<c001a520>]
 r6 = 00149AE8  r5 = 00149AE8  r4 = 00149AD0
Code: e153000e a59000e4 aa000015 e59000e4 (e7903103)
Error (Oops_bfd_perror): /tmp/ksymoops.ZwvjnG Invalid bfd target


 >>PC;  c00844f0 <yaffs_CheckpointClose+b8/11c>   <=====

 >>r8; c001a6c4 <sys_call_table+0/0>
 >>r7; c01464e8 <yaffs2_fs_type+0/1c>
 >>r6; c0146474 <yaffs_super_ops+0/50>

Trace; c0084440 <yaffs_CheckpointClose+8/11c>
Trace; c007ea4c <yaffs_WriteCheckpointData+34/a0>
Trace; c007ea20 <yaffs_WriteCheckpointData+8/a0>
Trace; c007ec18 <yaffs_CheckpointSave+60/7c>

 >>r5; c01462c4 <yaffs_traceMask+0/4>

Trace; c007ebc0 <yaffs_CheckpointSave+8/7c>
Trace; c0079160 <yaffs_put_super+50/bc>
Trace; c0079118 <yaffs_put_super+8/bc>
Trace; c0050ccc <kill_super+14c/168>
Trace; c0050b88 <kill_super+8/168>
Trace; c0063804 <sys_umount+58/9c>
Trace; c00637b4 <sys_umount+8/9c>
Trace; c001a520 <ret_fast_syscall+0/38>

Does this look familiar or ring any bells?

Charles Manning wrote:
> On Friday 16 February 2007 05:12, ian@brightstareng.com wrote:
>   
>> On Wednesday 14 February 2007 18:49, Blair Barnett wrote:
>>     
>>> We're experiencing what appear to be file system corruption
>>> due to power fail. I just got done looking at a nanddump of a
>>> yaffs2 file system that looks like the block header (first
>>> page in the block) was overwritten with garbage data (can't
>>> tell whether it's "good" data from some where else yet).
>>>       
>> If power is lost during an erase, the memory cells are left in an
>> undefined state with a "half bucket" of electrons which can be
>> read as a one or a zero depending on the temperature, supply
>> voltage, age and the wind ;-) The garbage data would very
>> propably produce a data ECC error (mtd ecc), but this is not
>> guaranteed.
>>     
>
> This scenario seems to make the most sense.
>
> While this sort of thing is pretty easy to see on NOR (which takes a long time 
> to erase), there is only a very small window for this to happen on NAND since 
> an erase only takes 2 or 3 msec or so. How often do you see this?
>
> I would suggest that you check the power rails etc. If your CPU can run at 
> voltages where the NAND is marginal, then you have the potential to be 
> telling the NAND to do stuff which it can't do properly. ie. During a power 
> failure you'd ideally be shutting down the CPU while the NAND still has 
> enough power to be sane.
>
> Also look carefully at the WP pin. Yanking the WP pin during a program/erase 
> can cause problems.
>
> You should ideally be doing power OK check in the NAND driver before starting 
> an erase or write to ensire that the system will have residual power to 
> complete an erase.
>
>   
>> If an error is detected by a failed read (mtd ecc), I would
>> expect Yaffs to recover.  If not, and Yaffs' test of it's own
>> spare/tags "mini ECC" looks good, then the data would be assumed
>> valid and presented as part of a Yaffs file.
>> [Have I got this right Charles?]
>>     
>
> There are places where the ecc is ignored.
>
>   
>> If you compute the ECC data for the "corrupted" block header
>> page, is it correct?
>> Is the mini-ecc that runs over the Yaffs tags correct?
>>
>>     
>>> I'm running 2.4.27 linux with the latest yaffs2 tarball. I'm
>>> unable to quickly move to 2.6.
>>>       
>> Linux 2.5 vs. 2.6 should not matter; there are many others
>> in the same boat (real world).
>>     
>
> Correct. That's why we consider it important to support 2.4.x rather than give 
> out abuse!
>
>   
>> -imcd
>>
>> _______________________________________________
>> yaffs mailing list
>> yaffs@lists.aleph1.co.uk
>> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>>     
>
>