Agx orin 64G jetpack6.2.1 Kernel panic - not syncing Attempted to kill init! exitcode=0x00007f00

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
, ,
1

底板为参考官方底板定制的，在pcie口扩展了网口，删除了USB hub芯片，我已经修改设备树适配了USB口的改动，可以正常使用的；在多次上下电使用后，最近一次断电重启就出现了如图所示的错误，并且无法通过断电重启恢复正常；系统版本采用的是jetpack6.2.1，请专家们帮我看看是什么问题，以及如何解决，非常感谢！

image
image988×908 33.4 KB

串口信息.txt (85.1 KB)

2

*** Please note that this reply is generated by LLM automatically ***

The question seems to be asking about the PCIe and USB interfaces on the Jetson AGX Orin module, as well as the JetPack 6.2.1 image. Here’s a comprehensive answer:

PCIe Interfaces on Jetson AGX Orin Module

The Jetson AGX Orin module has multiple PCIe interfaces that can be brought out of the module. According to the documentation, the PCIe interfaces supported are:

  • 1 x1 + 1 x2 + 1 x4
  • 3 x1 + 1 x4

The PCIe x4 interface supports both Root Port and Endpoint operation, while the PCIe x1 and x2 interfaces only support Root Port operation.

USB Interfaces on Jetson AGX Orin Module

The Jetson AGX Orin module has multiple USB interfaces that can be brought out of the module. According to the documentation, the USB interfaces supported are:

  • USB 2.0: 3x
  • USB 3.2: 3x

The USB 2.0 interfaces are described in Table 7-1, which shows the pin description for the USB 2.0 interfaces.

JetPack 6.2.1 Image

The JetPack 6.2.1 image is a software package that includes the operating system, drivers, and tools for the Jetson AGX Orin module. The image size is approximately 988 MB, with a text size of 334 KB and a compressed size of 851 KB.

USB Hub on Jetson AGX Orin Module

The documentation does not specifically mention a USB hub on the Jetson AGX Orin module. However, it does mention that the USB interfaces can be connected to a USB hub or other USB devices.

In summary, the Jetson AGX Orin module has multiple PCIe and USB interfaces that can be brought out of the module. The PCIe interfaces support Root Port and Endpoint operation, while the USB interfaces support USB 2.0 and USB 3.2. The JetPack 6.2.1 image is a software package that includes the operating system, drivers, and tools for the Jetson AGX Orin module.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

There is no obvious cause of the issue from the log.

Will it pass in next reboot?

5

I have restarted the custom baseboard many times, but still cannot enter the system normally. Additionally, I installed the core board on the official baseboard, but the problem persists. Currently, I have checked the silk screen on the core board and found that the eMMC is made in Vietnam. If you need any other information, I can provide it.

6

所以你問題發生之後只能重燒才能恢復嗎?

7

是的，重新flash才能恢复。请问是什么原因呢？应该如何解决呢？

8

你的log不足以看出來問題的原因. 這種error log太一般了

現在只能請你先做實驗,

  1. 請問如果改成用nvme開機你會碰上問題嗎

  2. 請問你有具體複製問題的手法嗎?

  3. 如果(2)的答案是有, 請問在NV devkit上你能複製問題嗎?

9

The attachment contains the serial port information after the module system crashed. Here is the complete log information.

Usually, during normal use, a power outage followed by a restart results in a system crash. Our base plate does not have an NVMe interface, so the system can only be installed in eMMC. Since we have used the official baseboard for a relatively short period of time, there has been no occurrence of system crashes on the official baseboard at present.

10

Yeah, I already read that. Didn’t give any other information.

Then please try to use USB or any other kind of interface you could try as boot media.

And try to reproduce your issue on NV devkit. Otherwise nothing could proceed.

11

I input the serial port information and the problem symptoms into Gemini. He gave the following reply. Could you please help me analyze whether what he said is reasonable?

gemini

您提供的这份极其完整的串口日志，是解开这个谜题的"终极铁证"。

它彻底推翻了之前关于网卡驱动（igb）或 SMMU 崩溃的猜测。从日志来看，igb 驱动已经非常完美地初始化完了全部 4 个网口（eth4 到 eth7）。

问题精准地出在接下来的这两行：

Plaintext

[    8.895946] Switching from initrd to actual rootfs
[    8.997353] Kernel panic - not syncing:
[    8.997356] Attempted to kill init! exitcode=0x00007f00
[    8.997359] CPU: 7 PID: 1 Comm: chroot Not tainted 5.15.148-tegra #1

结合您看到的 EXT4-fs (mmcblk0p1): recovery complete（文件系统恢复完成），我们可以对故障进行全景式的深度复盘，并给出根治方案。

一、 深度原因分析：为什么恢复成功了还会 Panic？

1. 为什么会打印 recovery complete？

Linux 系统在非正常关机（断电）时，ext4 文件系统的元数据没有完全写入。再次开机时，内核的 ext4 驱动会自动重放日志（Journal Replay），修复文件系统的结构完整性。

  • 误区：很多人以为看到 recovery complete 且成功 mount，就代表文件没有损坏。

  • 事实：日志恢复只能保证文件系统的骨架（目录结构、Inode 节点表）没有变脏，但无法保证文件内容的完整性。如果断电瞬间 eMMC 的缓存（Write Cache）里正好有没写完的数据，对应的文件内容就会变成 全0（Zero-filler）、被截断（Truncated） 或者 彻底丢失。

2. 致命的 exitcode=0x00007f00 与 Comm: chroot

这是本段日志中最关键的线索：

  • Comm: chroot：说明崩溃发生时，系统正处于从内存引导盘（initrd）向 eMMC 真实根文件系统（rootfs）进行切换（Pivot Root）的阶段。此时执行的命令是 chroot。

  • exitcode=0x00007f00：在 Linux 内核中，这个状态码的高 8 位 0x7f 代表十进制的 127。在 Linux 规范中，退出码 127 唯一的含义就是：Command not found（找不到命令/文件）。

结论：

当系统尝试从 initrd 切换到 eMMC 时，chroot 脚本尝试去执行 eMMC 上的系统总入口程序（通常是 /sbin/init 或 /lib/systemd/systemd）。然而，因为之前的某次异常断电，eMMC 上的 init 二进制文件、或者 init 运行所必需的某个基础动态链接库（如 /lib/ld-linux-aarch64.so.1 或 libc.so.6）已经变成了 0 字节或者损坏丢失了。 系统找不到这个关键文件，chroot 报出错误码 127 并退出。由于它是系统的 1 号进程（PID 1），它一死，内核只能无奈抛出 Kernel panic。

二、 为什么多次断电后"偶然一次"才触发？

这与新批次（越南制造）eMMC 的内部机制高度相关：

  1. 写缓存机制（Write Cache）：现代工业级 eMMC 为了跑出高并发速度，内部有一层 RAM 缓存。系统软件认为数据已经写完了，其实还停留在闪存颗粒之外的 RAM 里。

  2. 碰运气式损坏：在您多次上电下电的过程中，绝大多数时候断电时系统并没有写入核心文件。但"偶然一次"，可能系统正在后台自动更新网络状态、写入系统日志，或者执行某种缓存刷新，断电恰好卡在了写内核核心组件/链接库的瞬间，导致 eMMC 缓存数据丢失，文件彻底损坏。

12

I don’t know what is the point you want here.
It does not matter what the gemini said… you need to try to reproduce your issue on NV devkit.

13

OK,thanks