[BUG] UBIFS corruption on powerpc 32-bit targets
Zhihao Cheng
chengzhihao1 at huawei.com
Thu Jan 29 17:34:14 PST 2026
在 2026/1/29 18:30, Tomas Alvarez Vanoli 写道:
> Hello,
>
> I am writing beacuse we are experiencing ubifs corruption on our powerpc boards
> after updating from 6.1 to 6.12.57.
> I haven't pulled the latest UBIFS or UBI code, I looked around the changes some
> weeks ago and did not find something that seemed relevant.
>
> We have a variety of architectures running practically the same application
> (w.r.t. file/db writing), and have only experienced this in the powerpc boards,
> namely one using the layerscape t1040 in 32-bit mode and another one using
> MPC8360.
>
> Corruption appears only with the newer kernel, same compiler and libraries as
> older one.
>
> We've ran integck and fsstress for long periods of time in various boards but we
> have not been able to reproduce it, it happens with some automated tests on our
> test lab, after some hours of running tests (not stress tests). The application
> uses c++'s filesystem library.
>
> We have an ubi device (nand flash) holding mostly read-only volumes with kernels
> and rootfses, one rw volume for configurations (ubifs) and one for storing
> coredumps (jffs2).
>
[...]
> ```
>
> The error we are seeing is:
>
> ```
> root at kmcent2:~# find /cfg/ -name *tar.gz
> UBIFS error (ubi1:0 pid 134): ubifs_iget: failed to read inode 3917759, error -2
> UBIFS error (ubi1:0 pid 134): ubifs_lookup: dead directory entry 'ne_config.xml.gz', error -2
> UBIFS warning (ubi1:0 pid 134): ubifs_ro_mode: switched to read-only mode, error -2
Hi,
What is the type of volume ubi1:0, ro or rw?
The apparent reason is that the UBIFS image is inconsistent, the inode
cannot be found but the dentry(ne_config.xml.gz) still exists on flash.
Which means that user can see all directory entries under
/cfg/board/cfg/mob/backup/ne/, but file 'ne_config.xml.gz' cannot be
accessed.
You could dump the mtd image for 'ubi1' by the command 'dd if=/dev/mtd10
of=mtd_image bs=1M', and send the file 'mtd_image' to us by email, maybe
we could get more information from the image.
BTW, are there any abnormal history logs about ubi1 before the error
message?
> find: /cfg/board/cfg/mob/backup/ne/ne_config.xml.gz: No such fiCPU: 1 UID: 0 PID: 134 Comm: find Not tainted 6.12.57-00435-gf9e139970f1f #0
> Hardware name: keymile,kmcent2 e5500 0x80241021 CoreNet Generic
> Call Trace:
> [c2cabba0] [c0bbf558] dump_stack_lvl+0xfc/0x120 (unreliable)
> [c2cabbc0] [c041c8e4] ubifs_lookup+0x378/0x394
> [c2cabc20] [c02f100c] __lookup_slow+0xb0/0x1c0
> [c2cabc60] [c02f60d4] walk_component+0x158/0x24c
> [c2cabc90] [c02f7078] path_lookupat+0xa4/0x238
> [c2cabcc0] [c02f77b8] filename_lookup+0xcc/0x200
> [c2cabd90] [c02e7b08] vfs_statx+0xa0/0x150
> [c2cabdd0] [c02e858c] do_statx+0x84/0xe4
> [c2cabec0] [c02e87cc] sys_statx+0x8c/0x120
> [c2cabef0] [c00127bc] system_call_exception+0x9c/0x1e0
> [c2cabf10] [c00170e8] ret_from_syscall+0x0/0x28
> --- interrupt: c00 at 0xfe37b04
> NIP: 0fe37b04 LR: 0fe37ad0 CTR: 00000000
> REGS: c2cabf20 TRAP: 0c00 Not tainted (6.12.57-00435-gf9e139970f1f)
> MSR: 0002d002 <CE,EE,PR,ME> CR: 24008483 XER: 20000000
>
> GPR00: 0000017f bfe51f30 b7e51800 ffffff9c 100dc360 00000900 000007ff bfe51f38
> GPR08: 00000001 00000008 00008ffa c2cabf10 24004884 100c365a 00000000 10144bf0
> GPR16: 10140000 00000000 1015c110 00000000 10140000 100042d0 b7e7ebe8 100c0000
> GPR24: 00000000 00000000 100c0000 100dc360 b7e2e010 100dc360 0ff2afa8 bfe520c8
> NIP [0fe37b04] 0xfe37b04
> LR [0fe37ad0] 0xfe37ad0
> --- interrupt: c00
> le or directory
> ```
>
> I wanted to pick the lists' brain to figure out what else to try to debug or try
> to reproduce this more reliably, or if there's any relevant changes that you
> recall that could be causing this issue.
>
> I would also like to know how to go about dumping and flashing this into another
> board or to investigating it in my own pc.
Try following commands?
nanddump -n -o -f flash_image /dev/mtdX
nandwrite -o -n /dev/mtdY flash_image
>
> I tried dumping with mtd_debug and nanddump and then writing it to another board
> but I get ECC errors, surely I am doing something wrong.
>
> Thanks and best regards,
> Tomas Alvarez Vanoli
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> .
>
More information about the linux-mtd
mailing list