UBIFS Corrupt during power failure

news rw_nospam at gmx.de
Tue Jul 28 08:01:25 EDT 2009


Artem Bityutskiy schrieb:
> On Wed, 2009-06-03 at 07:50 -0600, Eric Holmberg wrote:
>   
>> Sorry for the delays on getting you real information - I am working on it as much as I can.  Due to our project schedule here, I can only work on this a few minutes a day.
>>
>> I have reproduced the CRC error, but looking at the data (shown below), I am not sure what data is expected in LEB 1 at the failed position.  I don't see anything that indicates that the write-buffer behavior that I have avoided by limiting the write-buffer size to 8 bytes is causing the problem.
>>
>> [42949375.500000] UBIFS error (pid 1): ubifs_check_node: bad CRC: calculated 0x714960f4, read 0x3dae4f0a
>> [42949375.510000] UBIFS error (pid 1): ubifs_check_node: bad node at LEB 1:89600
>> [42949375.520000] UBIFS error (pid 1): ubifs_scanned_corruption: corrupted data at LEB 1:89600
>> [42949375.540000] UBIFS error (pid 1): ubifs_scan: LEB 1 scanning failed
>> [42949375.580000] UBIFS error (pid 1): ubifs_recover_master_node: failed to recover master node
>>
>> LEB 1:89600 refers to address 0x31c75e00 for the NOR flash and looks like it contains nothing but zeros.
>>
>> 31c75e00: 00000000 00000000 00000000 00000000    ................
>> 31c75e10: 00000000 00000000 00000000 00000000    ................
>> 31c75e20: 00000000 00000000 00000000 00000000    ................
>> 31c75e30: 00000000 00000000 00000000 00000000    ................
>> 31c75e40: 00000000 00000000 00000000 00000000    ................
>> 31c75e50: 00000000 00000000 00000000 00000000    ................
>> 31c75e60: 00000000 00000000 00000000 00000000    ................
>> 31c75e70: 00000000 00000000 00000000 00000000    ................
>> 31c75e80: 06101831 3dae4f0a 000ecc9b 00000000    1....O.=........
>>
>> Since this is the root file system and is 28MB in size, I am working on creating a smaller file system and writing a fixed test pattern to it.  I will provide the dd images of these files along with log files as soon as possible which will hopefully be next Monday (June 8).
>>
>> If you have any addition suggestions or requests, please let me know.
>>     
>
> Well, I would be cool to have full UBIFS debugging output, or better
> the image of the partition.
>
>   
We have similar problems with a SPANSION falsh (S29GL01GP).
I think the reason of the problem is a feature of the chip.

I reduced the problem to the MTD access (without ubi/ubifs).
We noticed toggle flash-bit(s) after power off during a write cycle.
The toggle flash-bit(s) may occure after power of during an sector-erase
too.

Simple testsequence:
* flash_erase ...
* cp testfile /dev/mtd0
- automatic or manuel power off during the cp
Check the flash after reboot (e.g md5sum /dev/mtd0 helps).

We used the default settings from the CFI (MaxBufWriteSize=6 == 64 byte
buffer).






More information about the linux-mtd mailing list