UBIFS remounted ro during operation or from boot time

Thomas Kaufmann Thomas.Kaufmann at duagon.com
Fri Oct 30 06:42:00 PDT 2015


Richard,

thank for the quick reply, see the answers below:

> How does the problem during operation look like? Is it exactly the same?

This is hard to say, I did not manage to get a proper dmesg from the incident. There are lot of irrelevant kernel messages in our system.
If possible I try soon with a kernel with less debugging messages.

> 
> > [   12.224090] UBIFS: recovery needed
> > [   12.800018] UBIFS: recovery completed
> > [   12.803894] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
> > [   12.810180] UBIFS: file system size:   407715840 bytes (398160 KiB, 388
> MiB, 790 LEBs)
> > [   12.818420] UBIFS: journal size:       10452992 bytes (10208 KiB, 9 MiB, 21
> LEBs)
> > [   12.826232] UBIFS: media format:       w4/r0 (latest is w4/r0)
> > [   12.832336] UBIFS: default compressor: lzo
> > [   12.836578] UBIFS: reserved for root:  0 bytes (0 KiB)
> > [   12.844970] VFS: Mounted root (ubifs filesystem) on device 0:13.
> >
> > [   18.899841] UBIFS error (pid 1800): ubifs_check_node: bad CRC: calculated
> 0xc6fd2232, read 0xef37a8c0
> 
> UBIFS got something unexpected.
> It would be interesting what the LEB in question contains.
> Does it contain garbage, are just a few bits flipped, is only a page bad?

The printout I removed starts like this:
[   18.925872] 00000000: 06101831 ef37a8c0 0d2ef7fa 00000000 00000661 00000001 000087f2 20000041  1.....7.........a...........A.. 
[   18.925903] 00000020: 00000000 00000000 00001000 00000001 706d610c 2020203d 30312e34 200a2020  .................amp=   4.10  . 
[   18.925903] 00000040: 00010220 00003c3d 640a0800 7473614c 74736948 5279726f 3d206d70 35393720   ...=<.....dLastHistoryRpm = 795
[   18.925933] 00000060: 6c0a302e 02000258 65705320 61566465 74616972 206e6f69 3720203d 0700036c  .0.lX... SpeedVariation =  7l...

this looks like file contantes, until here

[   18.929565] 000012c0: 00000000 00000000 0000001c 00000005 00000e0c 00000000 00000000 00000000  ................................

to here, all is 0.

[   18.932037] 00001fe0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  ................................

> 
> > [   18.909515] UBIFS error (pid 1800): ubifs_check_node: bad node at LEB
> 486:200480
> > [   18.917205] UBIFS error (pid 1800): ubifs_scanned_corruption: corruption
> at LEB 486:200480
> > <then I think it prints the LEB>
> > [   18.932037] UBIFS error (pid 1800): ubifs_scan: LEB 486 scanning failed
> > [   18.939056] UBIFS warning (pid 1800): ubifs_ro_mode: switched to read-
> only mode, error -117
> > <more kernel traces>
> > [   19.095581] UBIFS error (pid 1800): make_reservation: cannot reserve 83
> bytes in jhead 2, error -117
> > [   19.105102] UBIFS error (pid 1800): do_writepage: cannot write page 0 of
> inode 10754, error -117
> >
> > This is when the issue is present at bootup.
> > Sometimes this issue can be resolved by rebooting, but not always.
> >
> > Is this happening due to a corrupted or defective flash (hardware problem)?
> 
> MTD did not report an ECC error nor a bad block -> from MTD's point of view
> everything is ok.
> It does not prove the that hardware is perfectly fine but at least the NAND did
> not turn bad.

thanks, this is good to know, So I will look further into the UBI part.

> 
> > Or is there a known problem in the software versions we are using?
> 
> Can be. Maybe a driver issue.
> Does your board pass all MTD/UBI tests?

I will discuss this with my colleagues who developed the board.

Thank you
-Thomas


More information about the linux-mtd mailing list