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 (Артём Битюцкий)
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.