linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Rick Johnson <rick22@wi.rr.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: read_pnode: error -22 reading pnode at XX:YYYYY
Date: Fri, 06 May 2011 21:32:30 +0300	[thread overview]
Message-ID: <1304706750.7222.95.camel@localhost> (raw)
In-Reply-To: <4DC31183.8060807@wi.rr.com>

On Thu, 2011-05-05 at 16:07 -0500, Rick Johnson wrote:
> Hi Artem,
> 
> Thanks for your advice!  We were finally able to reproduce the problem.
> 
> > 1. Validate the pnode before packing, do the same validate_pnode() does.
> > May be you'll catch the place where it we write incorrect pnode. Because
> > what you see is a result of an error which might have happend long
> > before you hit it.
> 
> We did validate_pnode() before the pnode was packed and have this output 
> from dbg_dump_pnode():
> 
> (pid 6298) dumping pnode:
> 	address c631d380 parent c6005720 cnext c6005720
> 	flags 3 iip 3 level 0 num -969086448
> 	0: free 0 dirty 127984 flags 1 lnum 514
> 	1: free 129024 dirty 0 flags 4 lnum 515
> 	2: free 0 dirty 127920 flags 1 lnum 516
> 	3: free 129024 dirty 0 flags 4 lnum 517
> 
> 
> It looks like 'num' is not valid.  Also, is it normal for 'parent' to be 
> equal to 'cnext'?

This code was written by Adiran and I do not know it, and it was a
little of "very quick programming", so it is not the cleanest code in
UBIFS, sorry.

I do not know by heart, but I think cnext is about the list of nodes
which should be written to the flash at the next commit. So if ->cnext
== ->parent this means that our parent is the next in the list. Hmm, and
I think we dirty nodes in the LPT tree from the bottom up to the root,
and add them to the commit list (cnext), so cnext == parent should be
very common.

But in 'read_pnode()' cnext must be NULL, I think.

Anyway, as I said, that was not my code, so I myself have difficulties
to deal with it. I asked Adrian to help  - may be he'll take a look at
this if he has time.

> We'll continue to look into this, but I thought it wouldn't hurt to get 
> your opinion on the above debug.

Sure. I hope you'll nail this. How well is it reproducible? Can you
reproduce this on nandsim which has equivalent characteristics (PEB
size, page size, count of PEBs) ?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2011-05-06 18:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19 21:08 read_pnode: error -22 reading pnode at XX:YYYYY Rick Johnson
2011-04-21 13:20 ` Artem Bityutskiy
2011-05-05 21:07   ` Rick Johnson
2011-05-06 18:32     ` Artem Bityutskiy [this message]
2011-05-09 17:41       ` Rick Johnson
2011-05-20 21:16       ` Rick Johnson
2011-05-24  8:41         ` Artem Bityutskiy
2011-05-24 11:43           ` Artem Bityutskiy
2011-05-27 20:26             ` Rick Johnson
2011-05-30 16:07               ` Artem Bityutskiy
2011-05-24 19:37           ` Rick Johnson

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=1304706750.7222.95.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rick22@wi.rr.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).