UBIFS Corrupt during power failure

Adrian Hunter adrian.hunter at nokia.com
Tue Jul 28 08:24:27 EDT 2009


news wrote:
> 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).

Artem is on holiday.

Have you read the rest of this thread?  Does any of it help you?




More information about the linux-mtd mailing list