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