linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Matthew L. Creech" <mlcreech@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: ubi_eba_init_scan: cannot reserve enough PEBs
Date: Sun, 22 Aug 2010 21:30:32 +0300	[thread overview]
Message-ID: <1282501832.16502.97.camel@brekeke> (raw)
In-Reply-To: <1280243535.3021.29.camel@localhost.localdomain>

On Tue, 2010-07-27 at 18:12 +0300, Artem Bityutskiy wrote:
> > Certainly.  I enabled all the relevant UBI and UBIFS debugging options
> > that I saw, along with internal self-checks, but there's still not a
> > whole lot of output.  Full console dump is attached - this is a
> > different device than the first, but exhibits the same problem.
> 
> I'm sure your ring buffer contains more information. This is one of the
> reasons I gave you the above link - it explains that not all messages go
> to console and how to get all meassages. Try to use dmesg. In UBIFS code
> I see that 'ubifs_read_node()' calls 'dbg_dump_node()' which should dump
> the node.
> 
> But '255' is 0xFF, so probably UBIFS read all 0xFF. This may be an UBIFS
> bug, or some corruption, difficult to say. For some reason the place
> where a valid znode should live is erased.
> 
> May be if I have a NAND dump of your broken device I can look at it, but
> do not promise anything, and I'm also on holiday :-)

Could you please dump LEB 5586 and check whether it is really erased or
not? Please, apply the following patch:

>From feb1616809b0bebeaf0cb596fdb5d715f6d75700 Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Date: Sun, 22 Aug 2010 21:27:30 +0300
Subject: [PATCH] UBIFS: improve error reporting when reading bad node

When an error happens during validation of read node, the typical situation is that
the LEB we read is unmapped (due to some bug). It is handy to include the mapping
status into the error message.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
 fs/ubifs/io.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
index bcf5a16..9432431 100644
--- a/fs/ubifs/io.c
+++ b/fs/ubifs/io.c
@@ -815,7 +815,8 @@ int ubifs_read_node(const struct ubifs_info *c, void *buf, int type, int len,
 	return 0;
 
 out:
-	ubifs_err("bad node at LEB %d:%d", lnum, offs);
+	ubifs_err("bad node at LEB %d:%d, LEB mapping status %d", lnum, offs,
+		  ubi_is_mapped(c->ubi, lnum));
 	dbg_dump_node(c, buf);
 	dbg_dump_stack();
 	return -EINVAL;
-- 
1.7.2.1

  parent reply	other threads:[~2010-08-22 18:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-22 18:37 ubi_eba_init_scan: cannot reserve enough PEBs Matthew L. Creech
2010-07-26  5:21 ` Artem Bityutskiy
2010-07-26 21:13   ` Matthew L. Creech
2010-07-27 15:12     ` Artem Bityutskiy
2010-07-27 15:21       ` Artem Bityutskiy
2010-07-28  5:46         ` Stefani Seibold
2010-08-22 15:04           ` Artem Bityutskiy
2010-08-31 12:09             ` Stefani Seibold
2010-09-01 15:47               ` Artem Bityutskiy
2010-09-02  6:47                 ` Stefani Seibold
2010-09-02  9:45                   ` Artem Bityutskiy
2010-08-22 15:02         ` Artem Bityutskiy
2010-07-27 20:47       ` Matthew L. Creech
2010-07-30 16:12         ` Artem Bityutskiy
2010-07-30 17:51           ` Matthew L. Creech
2010-08-02  4:22             ` Artem Bityutskiy
2010-08-22 18:30       ` Artem Bityutskiy [this message]
2010-08-24 22:38         ` Matthew L. Creech
2010-08-25  3:51           ` Artem Bityutskiy
2010-08-31 15:36           ` Matthew L. Creech
2010-09-01 18:57             ` Artem Bityutskiy
2010-09-06  9:17               ` Artem Bityutskiy
2010-09-07 15:59                 ` Matthew L. Creech
2010-09-07 17:17                   ` Artem Bityutskiy
2010-09-07 17:48                     ` 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=1282501832.16502.97.camel@brekeke \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mlcreech@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).