Re: ubifs panic with 2.6.39 stable - followup

[Artem Bityutskiy <dedekind1@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

On Wed, 2012-01-04 at 06:39 -0500, Brad Parker wrote:
> [sorry for the duplicate post; I tried to post a followup with just
>   the url to the pastebin log but for some reason  it got stuck
>   waiting for the moderator]
> 
> Running and older 2.6.31 kernel with UBIFS I see 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.
> 
> I rebooted with "ignore_loglevel" and the output is here:
> 
>      http://pastebin.com/ETJjP4uw
> 
> The board is essentially an Olimex SAM9-L9260, with Samsung NAND.
> 
> I'm curious if this looks familiar and if it might be fixed post 2.5.39
> 
> thanks for any insight.
> 
> -brad
> 
> 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

So there is a corrupted inode node, and UBIFS believes it has been
corrupted not because of a power cut. I do not know why it is corrupted,
but if you use MLC then this may be related to the paired pages problem.

Anyway, there is another issue I see from the dump. Even if you somehow
make the node good again, UBIFS will still fail saying something like
"corrupt empty space". Look at line 292 in your pastebin:

ffffffff ffffffff ffffffff ffffffff ffffffff ffdfffff ffffffff ffffffff

See that little "d"? It means that the empty space has a bit-flip. The
question is why? Unstable bit I guess? Does your NAND driver / HW
provides ECC protection for empty pages?

Anyway, currently UBIFS cannot handle these situation. Someone needs to
do this - I can assist by reviewing and advising.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]