Re: UBIFS error (pid 564): read_znode: bad indexing node at LEB 484:66064, error 2

[Artem Bityutskiy <dedekind1@gmail.com>]

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

On Fri, 2012-11-16 at 11:09 -0500, micah anderson wrote:
> [   97.273764] UBIFS error (pid 564): read_znode: bad indexing node at LEB 484:66064, error 2
> [   97.282188] UBIFS warning (pid 564): ubifs_ro_mode: switched to read-only mode, error -22

Did you re-size you UBI partition? The corresponding code in
'read_znode' is:

                if (zbr->lnum < c->main_first ||
                    zbr->lnum >= c->leb_cnt || zbr->offs < 0 ||
                    zbr->offs + zbr->len > c->leb_size || zbr->offs & 7) {
                        ubifs_err("bad branch %d", i);
                        err = 2;
                        goto out_dump;
                }

But I do not see the 'bad branch' message. Your UBIFS code-base is so ancient?

Then, in 'out_dump' we actually dump the znode. But this is not in your
logs. Most probably because we dump with KERN_DEBUG level, which does
not make it to your console. You need to boot with the 'ignore_loglevel'
kernel parameter.

But anyway, this does not look like something related to your flash
driver - the znode CRC checksum is correct, but the contents makes no
sense. This can be an UBIFS bug, but this is the first time I see this.
Often things like this are caused by memory corruption - if you have a
buggy driver which corrupts memory and writes garbage to UBIFS memory,
this kind of stuff may happen. You can try to enable memory
instrumentation like full slab/slub debugging and red zones, and
validate your system. Read carefully the docs - AFAIR slub debugging
options in the kernel config only add debugging support, but do not
enable it by default - you need to enable it separately.

Also, try to take the latest code from a UBIFS back-port tree, although
ubifs-v2.6.32 is not supported any more, but at least it is a lot newer
than vanilla 2.6.32, which is only interesting for archaeologists
nowadays :-)

-- 
Best Regards,
Artem Bityutskiy

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