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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.