Eth0 not starting automatically on boot

Trying to get my Xavier NX working with latest Jetpack 5,
but statically configured ip address eth0 192.168.0.1 doesn’t start at boot.
I checked Advanced network Configuration applet, and “Connect automatically with priority” is checked, and priority is set to -999.
Nothing I’ve tried seems to start this connection. The other end of the cable is is connected to a raspberrypi which comes up just fine as 192.168.0.10.

It was working before I setup auto-login today, if that is any help.

Hmm. It started working as mysteriously as it stopped. No idea why.
Never mind, I guess (I don’t have a very warm feeling about this though).

Whenever you have similar network issues post the output of “ifconfig” and “route”.

Will do. Thanks for your response!

OK, I have determined that if I leave the network cable unconnected during bootup, then all works fine, then eth0 section shows up in ifconfig and route output. If I then connect the cable. the connection to the raspberry pi is made and the ifconfig shows the correct static address of 192.168.0.1.

However, If I leave the cable connected and reboot, however, ifconfig and route have no entry for eth0.

Any advice?

Oh, yeah. More info:

For some reason that only makes sense to Nvidia, Jetpack 5 seems to default to PXE boot if a network cable is plugged in at boot time.

I have reconfigured the bootloader to boot off the NVME SSD, and modified /etc/NetworkManager/NetworkManager.conf to set [ifupdown]managed=true to get the thing to boot at all with a network cable plugged in.

Still more network magic needed, I guess. Nvidia, PLEASE turn off the PXE default and configure the eth0 to work out of the box.

I would think that normally there would be no PXE server. Perhaps the PXE is mistaking a simple DHCP for PXE, but that’s just a wild possibility/guess.

I don’t know. All I found was that if I had a network cable plugged in, it never booted untill I reconfigured the bootloader.

I checked into this more. It looks like it only defaults to PXE if no SD card is in Xavier NX module (I’m booting directly from NVMe SSD). Also, it does EVENTUALLY boot if it can’t find a PXE server, but it the timeout is around a minute. Anyway, PXE is not normally the default, as I first reported.

Also, I have an Xavier AGX set up the same way, and it ALWAYS seems to work fine when eth0 is connected while booting, so my problem seems to be Xavier NX - specific. Still no idea why, as clearly, the same settings work fine on the Xavier AGX. Maybe some kind of race condition at boot?

CHecked dmesg:

tonyvr@ubuntu:~$ sudo dmesg | grep eth0
[ 5.763141] nvethernet 2490000.ethernet: eth0 (HW ver: 50) created with 1 DMA channels
[ 22.427850] net eth0: failed to poll MAC Software reset

I rebooted again, and this time it came up:

tonyvr@ubuntu:~$ sudo dmesg | grep eth0
[sudo] password for tonyvr:
[ 5.702178] nvethernet 2490000.ethernet: eth0 (HW ver: 50) created with 1 DMA channels
[ 13.526799] nvethernet 2490000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 13.526861] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

So, there is definitely something wrong with eth0 initialization on my Xavier NX,
and it is not some incorrect setting.

On an SD card model it makes sense that default boot device search changes if no SD card is present. Much of this seems to simply be a matter of a configurable boot order. However, I think you are right about something being wrong when you see:

[ 22.427850] net eth0: failed to poll MAC Software reset

I’m not positive, but I think this likely results from a ROM not reading. I do not know what the cause of this would be, especially since it sometimes works.

I’m having this same problem.

Four Xavier NX dev kits: dev board model P3518, nx module model P3668; all flashed to the newest jetpack 5.0.2, all running from the sd card not off of nvme. Have tried multiple different flashes from the SDK Manager including flashing to a running system, flashing to the force recovery on the NX, and flashing to a new, blank sd card. Originally I had been running them with the WiFi card removed, so I tried plugging one in then flashing but that also made no difference. Also tried deleting and recreating the image on the host. The error still occurs without any steps required. They usually boot even with an ethernet cable plugged in, but randomly on reboots eth0 doesn’t start automatically. On an even less likely occurrence they do not boot at all, getting stuck somewhere with a black screen seemingly after the UEFI and before the system terminal showing the startup progress, but that only happened once or twice out of hundreds of reboots.

$ sudo dmesg | grep eth0
nvethernet 2490000.ethernet eth0 (HW ver: 50) created with 1 DMA channels
net eth0: failed to poll MAC Software reset

Another dmesg error immediately proceeding the failed to poll message:

[eqos_poll_for_swr][598][type:0x4][loga-0x0] poll_for_swr: timeout
net eth0: failed to poll MAC Software reset

Which might be related to:

But I’m not sure how or why a problem like would be relevant.

I tried running:

$ sudo ifconfig eth0 up

Sometimes it works and eth0 comes up. When it works dmesg gets:

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

When it doesn’t work it errors with:

SIOCSIFFLAGS: Operation not permitted

and dmesg prints the same thing:

[eqos_poll_for_swr][598][type:0x4][loga-0x0] poll_for_swr: timeout
net eth0: failed to poll MAC Software reset

To make it even more weird, trying the same command a second time after the error will sometimes work.

This sounds like the same issue as in this thread, but I can’t guarantee it. I’m not quite sure what to test for failure to poll eth0’s MAC. I’m hoping someone from NVIDIA can comment on whether there is a ROM being queried to find the MAC address, and what might cause this to fail (either “always” or “sometimes”).

I’d like to add that I’m having the exact same issue as @nbd
My eth0 adapter never comes up. I’m on jetpack 5.0.1 and have the OS installed on the SD card.

Someone from NVIDIA will have to comment on how the MAC address is retrieved, and what might fail to cause this to not be retrieved. In many cases though you’d need to list your L4T release (e.g., “head -n 1 /etc/nv_tegra_release”) and the specific model you are using (e.g., dev kit with SD card, versus third party carrier board). Also, if a dev kit, you’d need to state if you’ve flashed the module itself, or just the SD card.

Hi,

Is this issue an intermittent one on devkit? According to comments here, sound like eth0 can only work intermittently.

If so, can someone give a estimation of the reproduce rate? For example, boot up 10 times, how many times would you get eth0 working?

And is ifconfig up/down can bring the interface back to life in such situation? Also intermittently working?

Will there be a case that it firstly works fine but goes failure after few ifconfig up/down?