2403246_ja-JP

はい

i.MX8M Plus EXT4-fs エラー

EXT4-fs エラー (デバイス 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

追加のトレースは、パニックがdm-6のEXT4メタデータエラーに対する設定された応答であることを確認できます。Binderはおそらく、EXT4が破損したディレクトリブロックを検出した際にファイルを作成・開いたユーザースペースのThreadだと思います。

どうしたの：

EXT4 はファイルの作成中に無効なディレクトリエントリを検出しました。呼び出しパスは openat() → ext4_create() → ext4_add_entry() → ext4_find_dest_de() です。
ディレクトリブロックが破損しています。inode=0、rec_len=0、offset=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の破損事例1件はe2fsckで解決されました。

ユニットが開発ボードであり、データ保存が不要な場合、よりクリーンな復旧は通常以下の通りです:

fastbootでユーザーデータを消去

fastboot reboot

またはAndroidイメージセットを再フラッシュする。Androidは通常のユーザーデータ暗号化フローで、初回起動時にユーザーデータを再作成します。

根本原因を突き止めるには、以下の点に注目してください。

eMMCへの書き込み中に、予期せぬ電源喪失またはリセットが発生しました。NXPの資料は、eMMC書き込み中の電力喪失がファイルシステムやスーパーブロックの損傷を再現し、突然の電力喪失や電源サイクル負荷がeMMC/SDのデータ破損を引き起こす可能性があると指摘しています。
eMMC / ストレージエラー。EXT4 メッセージの前に、下位レベルの mmc、cqhci、タイムアウト、または I/O エラーを探してください。
電源の完全性／リセットシーケンス。電源のオン/オフを繰り返している際にこの問題が発生する場合は、電源のオン/オフ間隔を長くし、起動前にPMIC/eMMCレールが安定していることを確認してください。
DDRの不安定性。NXPフォーラムのEXT4ディレクトリ破損に関する同様のガイダンスでは、電源タイミングの調整で問題が解決しない場合は、すべてのパッチが適用されているかどうかを確認し、DDRストレステストを使用してDDRキャリブレーションを検証することも推奨されています。

要点：dm-6 をマップします。それがユーザーデータの場合は、オフラインで e2fsck を実行するか、ユーザーデータを消去/再作成し、eMMC の電源喪失/リセット、低レベルの MMC I/O エラー、および DDR の安定性を根本原因として調査します。