UBIFS partition on NOR flash not mountable after power cut test

[Artem Bityutskiy]

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 at 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 (Артём Битюцкий)