2403246_en-US

Yes

i.MX8M Plus EXT4-fs error

EXT4-fs error (device dm-6): ext4_find_dest_de:2030: inode #228492: block 918033: comm Binder:296_3: bad entry in directory: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, lblk=0, size=4096 fake=1

Re: i.MX8M Plus EXT4-fs error

The added trace confirms the panic is a configured response to an EXT4 metadata error on dm-6 ; Binder is probably just the userspace thread that happened to create/open a file when EXT4 detected the corrupt directory block.

What happened:

EXT4 detected an invalid directory entry while creating a file: the call path is openat() → ext4_create() → ext4_add_entry() → ext4_find_dest_de() .
The directory block is corrupt: inode=0, rec_len=0 at offset=0 is not a valid EXT4 directory entry.
EXT4 then aborted the journal: Aborting journal on device dm-6-8 .
The kernel panicked because the filesystem is configured for errors=panic ; EXT4 has explicit panic-on-error modes ( EXT4_MOUNT_ERRORS_PANIC , EXT4_ERRORS_PANIC ).

So the immediate issue is filesystem corruption on the block device behind dm-6 , not a Binder driver failure.

Most likely location is Android /data / userdata if dm-6 is a mapped encrypted userdata device. NXP i.MX Linux documentation shows EXT4 filesystems can be created on device-mapper crypt devices, and the crypt target intercepts block I/O . NXP Android notes also state that after erasing userdata, Android recreates the EXT4 filesystem and encryption setup on first boot, and normal boot can call e2fsck to check the filesystem .

Recommended debug sequence:

adb root

adb shell mount | grep dm-6

adb shell cat /proc/mounts | grep dm-6

adb shell ls -l /dev/block/mapper

adb shell ls -l /dev/block/by-name

adb shell dmctl list devices

adb shell dmsetup table

Then check for the real lower-layer cause before the EXT4 panic:

If dm-6 maps to /data / userdata:

Boot to recovery, initramfs, or another mode where userdata is not mounted read-write .

Run:

e2fsck -f -y /dev/block/by-name/userdata

or run it on the correct mapped node only if that is the intended unmounted filesystem target:

e2fsck -f -y /dev/block/dm-6

NXP community guidance for similar EXT4 corruption is to check/repair the filesystem with fsck / e2fsck ; one reported EXT4 corruption case was resolved with e2fsck .

If the unit is a development board and data preservation is not required, the cleaner recovery is usually:

fastboot erase userdata

fastboot reboot

or reflash the Android image set. Android will recreate userdata on first boot in the normal userdata-encryption flow .

For root cause, focus on these areas:

Unexpected power loss or reset during eMMC writes. NXP material notes that power loss during eMMC writing can reproduce filesystem/superblock damage, and sudden power loss or power-cycle stress can cause eMMC/SD data corruption.
eMMC / storage errors. Look for lower-level mmc , cqhci , timeout, or I/O errors before the EXT4 message.
Power integrity / reset sequencing. If this happens during repeated power cycling, increase the off/on interval and verify the PMIC/eMMC rails are stable before boot.
DDR instability. Similar NXP forum guidance for EXT4 directory corruption also suggested checking whether all patches are applied and validating DDR calibration with the DDR stress test when power timing did not resolve the issue.

Takeaway: map dm-6 ; if it is userdata, run offline e2fsck or erase/recreate userdata, then investigate eMMC power-loss/reset, lower-level MMC I/O errors, and DDR stability as the likely root causes.