linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Matthieu CASTET <matthieu.castet@parrot.com>
Cc: Anatolij Gustschin <agust@denx.de>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Detlev Zundel <dzu@denx.de>
Subject: Re: UBIFS partition on NOR flash not mountable after power cut test
Date: Thu, 02 Dec 2010 14:18:49 +0200	[thread overview]
Message-ID: <1291292329.2526.24.camel@localhost> (raw)
In-Reply-To: <4CF76B09.1020503@parrot.com>

On Thu, 2010-12-02 at 10:46 +0100, Matthieu CASTET wrote:
> Hi,
> 
> Artem Bityutskiy a écrit :
> > On Wed, 2010-12-01 at 16:44 +0100, Anatolij Gustschin wrote:
> >> On Wed, 1 Dec 2010 13:05:34 +0100
> >> Anatolij Gustschin <agust@denx.de> wrote:
> >> ... 
> >>> My question is:
> >>> Is it possible that the reset occured while running in
> >>> nor_erase_prepare() just after clearing the VID header magic,
> >>> but before clearing the EC header magic?
> >> yes, it is possible and it seems this is the reason for
> >> that next issue we've observed. Adding the call to the
> >> machine restart callback in nor_erase_prepare() just before
> >> clearing EC header magic to simulate this hypothetical case
> >> we see:
> > You are right, Anatoli.
> > 
> > Looking closer to my own code, I see that I treat PEB as
> > "corrupted and should be preserved" if:
> > 
> > 1. EC header is OK.
> > 2. VID header is corrupted.
> > 3. data area is not "all 0xFFs".
> > 
> > And in 'nor_erase_prepare()' we first invalidate the VID header, and
> > then invalidate the EC header. So there is a small window where you can
> > end up with all 3 conditions to be true.
> > 
> > The solution is to first invalidate the EC header, and only then the VID
> > header. Then in case of the race, we just lose the EC header, but VID
> > header will be all-right, and UBI will handle this - it'll move the data
> > from this PEB to another one, re-create EC header and use average EC
> > count. But if you test this scenario, it will be great!!
> > 
> > This patch should help (compile-tested only).
> > 
> Shouldn't the correct solution will come with handling unstable page 
> problem [1] ?

Err, yes, these things are related, but it is long way to go before we
have the unstable bits issues solved. The NOR quirk is the current
solution for slow and peculiar NOR erasure, it works, and should be kept
working, I think.

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

  reply	other threads:[~2010-12-02 12:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-29 18:50 UBIFS partition on NOR flash not mountable after power cut test Anatolij Gustschin
2010-11-29 20:33 ` Mark Mason
2010-12-02  3:47   ` Artem Bityutskiy
2010-12-02  4:10     ` Mark Mason
2010-12-02  9:17       ` Detlev Zundel
2010-11-30 10:41 ` Norbert van Bolhuis
2010-11-30 15:35   ` Anatolij Gustschin
2010-12-01  9:38     ` Anatolij Gustschin
     [not found]     ` <AANLkTikEDQyNttTcKgHLwhR53sYSFbtVK-oy2S3END46@mail.gmail.com>
2010-12-01  9:47       ` Norbert van Bolhuis
2010-12-01  9:55       ` Anatolij Gustschin
     [not found]         ` <AANLkTikci0e2jaHCarA9HG86b_C-1UUcT_PMy-Q_mBrP@mail.gmail.com>
2010-12-01 13:06           ` Norbert van Bolhuis
2010-12-02  3:51   ` Artem Bityutskiy
2010-12-01 12:05 ` Anatolij Gustschin
2010-12-01 15:44   ` Anatolij Gustschin
2010-12-02  4:01     ` Artem Bityutskiy
2010-12-02  4:42     ` Artem Bityutskiy
2010-12-02  9:46       ` Matthieu CASTET
2010-12-02 12:18         ` Artem Bityutskiy [this message]
2010-12-02  9:57       ` Anatolij Gustschin
2010-12-02 12:18         ` Artem Bityutskiy
2010-12-02 13:23           ` Anatolij Gustschin
2010-12-02 13:35             ` Artem Bityutskiy
2010-12-02 13:50               ` Anatolij Gustschin
2010-12-02 13:57                 ` Artem Bityutskiy
2010-12-02 14:18                   ` Anatolij Gustschin
2010-12-03 10:07       ` Anatolij Gustschin
2010-12-03 10:23         ` Anatolij Gustschin
2010-12-03 10:28         ` Artem Bityutskiy
2010-12-03 10:41           ` Anatolij Gustschin
2010-12-03 10:49         ` Artem Bityutskiy
2010-12-03 11:15       ` Anatolij Gustschin
2010-12-02  3:46 ` 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=1291292329.2526.24.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=agust@denx.de \
    --cc=dzu@denx.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.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).