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 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).