2403246_zh-CN

はい

i.MX8M Plus EXT4 文件系统错误

EXT4 文件系统错误（设备 dm-6）：ext4_find_dest_de:2030：inode #228492：块 918033：comm Binder:296_3：目录中的条目错误：rec_len 小于最小值 - offset=0，inode=0，rec_len=0，lblk=0，size=4096 fake=1

Re: i.MX8M Plus EXT4-fs error

添加的跟踪证实，panic 是对 dm-6 上 EXT4 元数据错误的配置响应；Binder 可能只是用户空间线程，恰好在 EXT4 检测到损坏的目录块时创建/打开了一个文件。

发生了什么：

EXT4 在创建文件时检测到无效的目录条目：调用路径为 openat() → ext4_create() → ext4_add_entry() → ext4_find_dest_de()。
目录块已损坏：inode=0，rec_len=0，偏移量=0 不是有效的 EXT4 目录项。
然后 EXT4 中止了日志记录：中止设备 dm-6-8 上的日志记录。
内核崩溃了，因为文件系统配置为 errors=panic；EXT4 具有显式的错误时崩溃模式（EXT4_MOUNT_ERRORS_PANIC、EXT4_ERRORS_PANIC）。

因此，目前的问题是dm-6 后面的块设备上的文件系统损坏，而不是 Binder 驱动程序故障。

如果 dm-6 是一个已映射加密用户数据的设备，则最可能的位置是 Android /data / userdata。NXP i.MX Linux 文档显示，可以在设备映射器加密设备上创建 EXT4 文件系统，并且加密目标拦截块 I/O。NXP Android 说明还指出，在擦除用户数据后，Android 会在首次启动时重新创建 EXT4 文件系统和加密设置，正常启动时可以调用 e2fsck 来检查文件系统。

推荐的调试顺序：

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 表

然后检查 EXT4 崩溃之前的真正底层原因：

如果 dm-6 映射到 /data / userdata：

启动到恢复模式、initramfs 模式或其他用户数据未以读写方式挂载的模式。

运行：

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

或者，仅当目标文件系统是预期的未挂载文件系统时，才在正确的映射节点上运行它：

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

NXP 社区针对类似的 EXT4 损坏的指导意见是使用 fsck / e2fsck 检查/修复文件系统；一个已报告的 EXT4 损坏案例已通过 e2fsck 解决。

如果设备是开发板且不需要数据保留，通常更干净的恢复方法是：

fastboot erase userdata

fastboot 重启

或者重新刷写 Android 镜像集。在正常的用户数据加密流程中，Android 将在首次启动时重新创建用户数据。

要找出根本原因，请重点关注以下几个方面：

eMMC写入过程中意外断电或重启。NXP 的资料指出，在 eMMC 写入过程中断电可能会重现文件系统/超级块损坏，而突然断电或电源循环压力会导致 eMMC/SD 数据损坏。
eMMC/存储错误。在 EXT4 消息之前，查找较低级别的 mmc、cqhci、超时或 I/O 错误。
电源完整性/RESET排序。如果在反复断电重启过程中出现这种情况，请增加断电/开机间隔，并在启动前验证 PMIC/eMMC 电源轨是否稳定。
DDR不稳定。NXP 论坛上针对 EXT4 目录损坏的类似指导还建议，如果电源时序问题没有解决，则应检查是否应用了所有补丁，并使用 DDR 压力测试验证 DDR 校准。

要点：映射 dm-6；如果是用户数据，则运行离线 e2fsck 或擦除/重新创建用户数据，然后调查 eMMC 断电/重置、低级 MMC I/O 错误和 DDR 稳定性作为可能的根本原因。