From: news <rw_nospam@gmx.de>
To: dedekind@infradead.org
Cc: Stefan Roese <sr@denx.de>,
linux-mtd@lists.infradead.org,
Eric Holmberg <Eric_Holmberg@Trimble.com>,
Jamie Lokier <jamie@shareable.org>,
Adrian Hunter <adrian.hunter@nokia.com>
Subject: Re: UBIFS Corrupt during power failure
Date: Tue, 28 Jul 2009 14:01:25 +0200 [thread overview]
Message-ID: <4A6EE895.9050008@gmx.de> (raw)
In-Reply-To: <1244369819.5847.321.camel@localhost.localdomain>
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).
next prev parent reply other threads:[~2009-07-28 12:01 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 13:45 UBIFS Corrupt during power failure Eric Holmberg
2009-03-24 15:30 ` Adrian Hunter
2009-03-24 17:04 ` Eric Holmberg
2009-03-24 18:16 ` Eric Holmberg
2009-03-25 6:32 ` Artem Bityutskiy
2009-03-26 6:59 ` Artem Bityutskiy
2009-03-26 14:09 ` Eric Holmberg
2009-03-30 19:00 ` Eric Holmberg
2009-03-31 14:45 ` Artem Bityutskiy
2009-04-10 12:25 ` Artem Bityutskiy
2009-04-10 14:27 ` Eric Holmberg
2009-04-10 15:17 ` Artem Bityutskiy
2009-04-10 15:49 ` Artem Bityutskiy
2009-04-10 17:00 ` Eric Holmberg
2009-04-10 17:11 ` Artem Bityutskiy
2009-04-10 18:33 ` Eric Holmberg
2009-04-14 6:11 ` Artem Bityutskiy
2009-04-14 15:09 ` Eric Holmberg
2009-04-14 15:45 ` Artem Bityutskiy
2009-04-14 15:53 ` Artem Bityutskiy
2009-04-14 18:00 ` Jamie Lokier
2009-04-15 6:00 ` Artem Bityutskiy
2009-04-15 15:17 ` Eric Holmberg
2009-04-15 16:09 ` Jamie Lokier
2009-04-15 16:12 ` Artem Bityutskiy
2009-04-15 16:32 ` Eric Holmberg
2009-04-15 16:44 ` Jamie Lokier
2009-04-15 18:26 ` Nicolas Pitre
2009-04-15 18:38 ` Jamie Lokier
2009-04-15 19:33 ` Eric Holmberg
2009-04-15 20:15 ` Nicolas Pitre
2009-04-15 20:46 ` Jamie Lokier
2009-04-16 5:51 ` Artem Bityutskiy
2009-04-16 5:46 ` Artem Bityutskiy
2009-04-16 21:34 ` Jamie Lokier
2009-04-17 8:56 ` Artem Bityutskiy
2009-04-17 13:51 ` Jamie Lokier
2009-04-17 14:36 ` Artem Bityutskiy
2009-04-17 23:49 ` Eric Holmberg
2009-05-15 7:16 ` Stefan Roese
2009-05-18 17:30 ` Eric Holmberg
2009-05-19 8:18 ` Artem Bityutskiy
2009-05-19 22:16 ` Eric Holmberg
2009-05-25 8:38 ` Artem Bityutskiy
2009-05-25 12:54 ` Artem Bityutskiy
2009-05-25 12:57 ` Artem Bityutskiy
2009-07-03 13:26 ` Artem Bityutskiy
2009-07-03 13:29 ` Artem Bityutskiy
2009-07-03 13:33 ` Urs Muff
2009-07-03 14:05 ` Artem Bityutskiy
2009-07-03 14:47 ` Urs Muff
2009-07-03 14:58 ` Artem Bityutskiy
2009-07-06 4:30 ` Artem Bityutskiy
2009-07-06 4:51 ` Artem Bityutskiy
2009-07-06 6:43 ` Artem Bityutskiy
2009-07-07 6:46 ` Artem Bityutskiy
2009-07-07 7:05 ` Urs Muff
2009-07-13 18:22 ` Eric Holmberg
2009-07-14 5:34 ` Artem Bityutskiy
2009-07-15 20:52 ` Jamie Lokier
2009-07-15 21:35 ` Eric Holmberg
2009-07-16 7:33 ` Artem Bityutskiy
2009-07-24 6:49 ` Artem Bityutskiy
2009-07-24 12:00 ` Artem Bityutskiy
2009-07-24 13:39 ` Eric Holmberg
2009-07-24 14:55 ` Artem Bityutskiy
2009-07-24 14:05 ` Jamie Lokier
2009-07-24 14:09 ` Artem Bityutskiy
2009-07-16 7:09 ` Artem Bityutskiy
2009-07-16 16:49 ` Jamie Lokier
2009-07-17 7:07 ` Artem Bityutskiy
2009-07-15 20:55 ` Jamie Lokier
2009-07-15 21:36 ` Eric Holmberg
2009-07-15 22:09 ` Jamie Lokier
2009-07-16 7:22 ` Artem Bityutskiy
2009-07-16 7:16 ` Artem Bityutskiy
2009-07-16 20:54 ` Gilles Casse
2009-07-17 0:29 ` Carl-Daniel Hailfinger
2009-07-24 14:08 ` Jamie Lokier
2009-07-16 7:14 ` Artem Bityutskiy
2009-06-03 8:08 ` Artem Bityutskiy
2009-06-03 8:25 ` Stefan Roese
2009-06-03 13:50 ` Eric Holmberg
2009-06-07 10:16 ` Artem Bityutskiy
2009-07-28 12:01 ` news [this message]
2009-07-28 12:24 ` Adrian Hunter
2009-07-28 17:19 ` Eric Holmberg
2009-08-09 4:59 ` Artem Bityutskiy
2009-04-17 8:58 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A6EE895.9050008@gmx.de \
--to=rw_nospam@gmx.de \
--cc=Eric_Holmberg@Trimble.com \
--cc=adrian.hunter@nokia.com \
--cc=dedekind@infradead.org \
--cc=jamie@shareable.org \
--cc=linux-mtd@lists.infradead.org \
--cc=sr@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).