I placed the Jetson core board on a custom circuit module. After booting, it runs normally for a while but then encounters a network card issue. The debug port outputs the following:
[ 89.383472] Trying to unregister non-registered hwtime source
[ 89.385262] RTL8211F Gigabit Ethernet 2490000.ethernet:01: Master/Slave resolution failed, maybe conflicting manual settings?
[0000.025] W RATCHET MB1 binary rat.txt (65.0 KB)
The module mounts on a carrier board. Are you talking about mounting a module on a custom carrier board (there isn’t really a custom module itself)? When you purchase modules separately though they are commercial modules and not developer kit modules (a commercial Xavier NX module would differ from a dev kit module by having eMMC instead of an SD card slot, and the commercial module would arrive without a carrier board unless it was also purchased from a third party).
Whenever you have a third party carrier board it is possible (and probable) that one or more of the pins on the module will have their function reassigned in order to use a different carrier board layout. The device tree (part of firmware) is how the module is told about the carrier board layout, and if you were to use NVIDIA’s device tree, then the parts which differ in layout would fail. Possibly this would also crash the system.
The manufacturer of the carrier board provides the device tree since only the manufacturer knows how the layout of its carrier board differs from the sample case of the dev kit. It might be provided in the form of a patch to the NVIDIA dev kit software, or in the form of a rebranded flash setup. On some occasions a third party carrier board will have the same electrical layout as the dev kit, and in that case, the manufacturer will state that the dev kit software should be used directly without any patches. I have no doubt though that your case has a different layout for how the Ethernet is connected.
Thank you for your prompt response. I’ve found the reason: I wrote a script that repeatedly executes the following commands when the network is unstable, causing the system to crash:
systemctl restart NetworkManager
time.sleep(5)
ifconfig eth0 down
time.sleep(2)
ifconfig eth0 up
time.sleep(3)
nmcli connection up liantong
time.sleep(3)
systemctl restart openvpn-client.service
time.sleep(2)
systemctl restart systemd-resolved
time.sleep(2)
Did that get all of the information you need? If not, then you might monitor “dmesg --follow” just prior to your script, and watch for whatever new log lines occur. The lines just before the crash and during the crash would be relevant. Your script could also add debug content such as “ifconfig” between steps if you need more detail.