ubifs panic with 2.6.39 stable

[Artem Bityutskiy]

On Mon, 2012-01-02 at 13:14 -0700, Brad Parker wrote:
> Running and older 2.6.31 kernel with UBIFS I saw a panic which appears
> to be during recovery
> of a bad block. The root fs (which is UBIFS) won't mount and the kernel
> panics.
> 
> I upgraded the kernel 2.6.39-stable, hoping that would fix the problem,
> as I noticed a lot of
> recovery fixes had gone in.  It still panics; it appears the recovery
> fails.
> 
> The board is essentially an Olimex SAM9-L9260, with Samsung NAND.
> 
> Below are the interesting parts of the log (and the panic).  I'm curious
> if this looks familiar
> and if there might be fixes post 2.5.39...  thanks for any insight.

You have a corrupted node on the media. In general, UBIFS cleans-up the
file-system automatically if the corruption is caused by a power-cut.
But when it is caused by something else, it refuses to mount.

In your case UBIFS thinks it is not a power cut. What you need to do is
to figure out why this happened. One of the possible reasons is unstable
bits - this problem is not resolved in UBIFS and no one is working on
this AFAIK. But this depends on your NAND. E.g., in older NANDs we did
not notice this. Also, modern SLCs have some properties of MLCs, which
may cause issues.

Basically, here you can find a list of things which may cause this:

http://www.linux-mtd.infradead.org/doc/ubifs.html#L_ubifs_mlc
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits

> VFP support v0.3: not present
> UBIFS: recovery needed
> UBI error: ubi_io_read: error -74 (ECC error) while reading 126976 bytes
> from PEB 2970:4096, read 126976 bytes
> UBIFS error (pid 1): ubifs_check_node: bad CRC: calculated 0xf510fb95,
> read 0x4f0a3196

When UBIFS debugging is enabled, it prints much more information. But it
uses KERN_DEBUG level, so you do not see it. I think I have to change it
to KERN_ERR, because so many people are confused. I wrote about this
many times, documented in the web site (may be in not the most readable
form, though), but people keep sending partial logs - just what they get
in their serial console. Not, I do not blame you, just thinking
aloud :-)

Anyway, try to type dmesg or boot with ignore_loglevel to make sure
_all_ kernel messages go to your serial console. If you dig the MTD
web-site, you'll find more info, e.g., by starting here:

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_how_send_bugreport

Please, send the full log - may be I'll spot something useful.

Thanks!

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120104/2c4fe9ed/attachment-0001.sig>