Cannot use ethernet after reboot, Re-Plug Solves

Hello,

I cannot use (ping) eth0 after rebooting the device. But if disconnect and connect ethernet cable again, I can use the eth0.

Module : Orin NX 16 GB with Connect Tech Hadron Carrier (Headless, no display connection)
Software : L4T R35.4.1
Host : Ubuntu 18_04

I have added the logs that can be helpful. All these logs are printed when I cannot use eth0, cannot ping host.

ifconfig

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:11:08:ef:22  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 11.0.0.99  netmask 255.255.255.0  broadcast 11.0.0.255
        inet6 fe80::4ab0:2dff:feea:770f  prefixlen 64  scopeid 0x20<link>
        ether 48:b0:2d:ea:77:0f  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 56  bytes 5714 (5.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 253  base 0x8000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 91  bytes 7821 (7.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 91  bytes 7821 (7.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rndis0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether a6:e9:6d:ef:7a:55  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether a6:e9:6d:ef:7a:57  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    600    0        0 wlan0
10.0.128.0      0.0.0.0         255.255.192.0   U     600    0        0 wlan0
11.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

sudo dmesg | grep eth0

[   12.481778] eth0: 0xffff800010c78000, 48:b0:2d:ea:77:0f, IRQ 253
[   16.620931] r8168: eth0: link up
[   16.621076] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

sudo dmesg | grep ethernet

[   12.593743] using random self ethernet address
[   12.601079] using random host ethernet address
[   13.064682] using random self ethernet address
[   13.069583] using random host ethernet address

cat /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
# source-directory /etc/network/interfaces.d

auto lo eth0
iface eth0 inet static
address 11.0.0.99
netmask 255.255.255.0

Thanks.

UPDATE:

In addition to re-plugging cable, if I execute following commands in order to restart eth0, mostly it starts to work successfully:

sudo ip link set eth0 down
sudo ip link set eth0 up

However, this approach also fails sometimes.

Will this situation happen when using dhcp case?

Hi,

I am connecting host ubuntu computer directly to the board. There is no external DHCP server. With this configuration can I try DCHP?

UPDATE

If do the network interface restart by:

sudo ip link set eno2 down
sudo ip link set eno2 up

on host computer too, ethernet connection starts successfully.

I have done the same test with official Orin Nano developer kit. Result is same. Sometimes I need to re-plug the cable or restart the Ethernet interface from terminal. I have also replaced the Ethernet cable. Can it be about host computer settings ?

Thanks.

If I install another Orin NX module on the Hadron carrier board with same SSD, I do not encounter this problem. Just switching the module solves the problem. On the other hand, when I install the Orin NX module, which I have problems with, on another Hadron carrier board, the problem occurs again. I also tried with another SSD. If I change SSD, which works fine with another Orin NX module, problem still continues. problem seems to be related to the Orin NX module.

Other information that may be a clue:

Additionally, the “detecting hardware” phase takes a very short time when installing Ubuntu with this Orin NX module. The Orin NX module, which I just took out of the box and works fine, took relatively longer. At the same time, when I first flash this problematic Orin NX module, I encounter the following error when I do sudo apt-get update:

E: Could not get lock /var/lib/apt/lists/lock. It is held by process <pid_no_here> (packagekitd)

When I flash the same image from the same Linux For Tegra folder into another Orin NX module, I do not receive this error after fresh install.

Could the problem be related to the QSPI module of the Orin NX module? The first installation of the Orin NX module, which was causing problems, was interrupted due to temperature. Is there a process such as completely resetting this module or returning it to factory settings? Can QSPI be completely reset?

Hi,

There is nothing called factory reset on Jetson platform. What we provide is reflash your whole board with sdkmanager.

I don’t know what is Hadron carrier board. If it is a custom board, then contact with the board vendor how to flash their board.

I have faced the same issue on developer kit. If I switch Orin NX module both on developer kit and carrier board, there is no problem.

Third party carrier boards route pins differently (many pins on the module can be switched to different functions). The device tree/firmware determines how to route those pins with any given function. The NVIDIA software assumes an NVIDIA dev kit carrier board. Unless your Hadron is a 100% exact layout match to the dev kit that firmware/device tree won’t work. The third party supplier of the Hadron will do one of the following (you must consult them to get the answer):

  • They might say that this carrier board matches a dev kit and to use the NVIDIA dev kit software (not often).
  • They might provide a patch to the NVIDIA flash software (BSP), in which case you apply that download from them to the otherwise stock NVIDIA flash software (this is usually just a device tree, but might also include a flash target).
  • They might provide a complete Board Support Package (which is usually a rebranded NVIDIA flash software with patches for their carrier board routing).

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.