From: Artem Bityutskiy <dedekind1@gmail.com>
To: Steve B <steve@baconbits.demon.co.uk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI/UBFS: ubi_eba_read_leb() reporting unmapped LEB
Date: Mon, 20 Oct 2014 17:05:12 +0300 [thread overview]
Message-ID: <1413813912.7906.305.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1410201442380.2556@ubuntu>
On Mon, 2014-10-20 at 14:48 +0100, Steve B wrote:
> Hi Artem,
>
> Thanks for the reply.
>
> I have the kernel built with:
> CONFIG_MTD_UBI_DEBUG=y
> CONFIG_UBIFS_FS=y
>
> The failure was seen on an embedded device, I dumped the flash
> contents (raw format) and then re-constructed the image on my Linux PC
> using nandsim with UBI and UBIFS modules i've built with some extra debugging.
> The call stack in the log posted is the same as the one seen on the device
> that showed the original problem.
>
I see. Would you post the full log, not just the extract near the
failure message?
>From what I see so far, UBIFS believes that the data of a file is stored
in LEB 352. But UBI says: "nope, this LEB was unmapped".
So the bug may be in both UBIFS and UBI.
When we were writing this code years ago, we were stressing UBIFS
power-cut tolerance a lot. We dead real power cuts, but we did emulated
power cuts a lot more than real. And emulated power cuts only test
UBIFS, not UBI. On the other hand, UBI is very simple comparing to
UBIFS.
BTW, do you have fastmap enabled or disabled?
Are you doing deliberate power cut testing, or you hit this error by
chance? In the former case, you may enable additional debugging,
probably, depending on how many test-boxes are you stressing
simultaneously.
Also, are you 100% sure you "reconstructed" the image correctly, and you
are not wasting time looking at irrelevant errors?
Artem.
next prev parent reply other threads:[~2014-10-20 14:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-10 13:45 UBI/UBFS: ubi_eba_read_leb() reporting unmapped LEB Steve B
2014-10-20 8:54 ` Steve B
2014-10-20 13:35 ` Artem Bityutskiy
2014-10-20 13:48 ` Steve B
2014-10-20 14:05 ` Artem Bityutskiy [this message]
2014-10-20 14:51 ` Steve B
2014-10-20 15:19 ` Artem Bityutskiy
2014-10-20 15:25 ` Steve B
2014-10-20 15:47 ` Artem Bityutskiy
2014-10-20 16:33 ` Steve B
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=1413813912.7906.305.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=steve@baconbits.demon.co.uk \
/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