UBI problems on 2nd mount

[Uwe Kleine-König]

Hello,

On Thu, Aug 16, 2012 at 12:54:45PM +0200, Uwe Kleine-König wrote:
> I'm on v3.6-rc1 with a few patches, but all unrelated to ubi/ubifs.
> I'm experiencing a very similar problem to the one James Nute and Iwo
> Mergler reported which resulted in commit c6727932c (included in
> v3.6-rc1).
> 
> The first boot looks ok, but on the second boot it fails with 
> 
> 	[   14.843501] UBIFS error (pid 1): replay_log_leb: first CS node at LEB 3:0 has wrong commit number 0 expected 1
> 	[   14.853626] UBIFS error (pid 1): replay_log_leb: log error detected while replaying the log at LEB 3:0
> 
> It doesn't reproduce 100%, I only saw it after issuing $(poweroff) and
> then only if that resulted in the error
> 
> 	[  173.019073] UBI error: ubi_io_write: error -5 while writing 64 bytes to PEB 30:0, written 0 bytes
> 
> $(reboot) and just switching off + reenabling the power supply don't
> yield this problem.
> 
> The same happes if I don't use -F (space_fixup) for mkfs.ubifs.
> (Then the two ubifs_assert(!c->space_fixup); in ubifs_write_node are not
> hit which I think are a seperate problem.) The kernel panic after power
> off is a seperate problem that is triggered because poweroff doesn't
> stop the cpu.
While bisecting I noticed that doing poweroff after the machine is up
for some time the issue doesn't occur. Bisection yielded commit

commit d51f17ea0a3afe11fb4c4ad6635877e24df2758f
Author: Artem Bityutskiy <Artem.Bityutskiy at linux.intel.com>
Date:   Sat Jul 14 20:52:58 2012 +0300

    UBIFS: simplify reply code a bit
    
    In the log reply code we assume that 'c->lhead_offs' is known and may be
    non-zero, which is not the case because we do not store it in the master
    node and have to find out by scanning on every mount. Knowing this fact
    allows us to simplify the log scanning loop a bit and remove a couple
    of unneeded local variables.
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at linux.intel.com>

 fs/ubifs/replay.c |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

AFAICT the replay function runs early after the filesystem was mounted,
so this seems to match.

I didn't try yet to debug that further or even test a revert of this
commit on top of v3.6-rc1. Will take a look later today.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |