Ethernet Connectivity Issues

Anyone having issues with ethernet connectivity constantly dropping in and out on the Jetson development board?

A check of dmesg shows:

[ 47.985948] eqos 2490000.ether_qos eth0: Link is Down
[ 50.906916] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 53.474997] eqos 2490000.ether_qos eth0: Link is Down
[ 56.497121] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 61.365184] eqos 2490000.ether_qos eth0: Link is Down
[ 64.244650] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 69.677399] eqos 2490000.ether_qos eth0: Link is Down
[ 72.588468] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 78.141646] eqos 2490000.ether_qos eth0: Link is Down
[ 81.237775] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 84.501073] eqos 2490000.ether_qos eth0: Link is Down
[ 87.436208] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 94.029589] eqos 2490000.ether_qos eth0: Link is Down
[ 96.979439] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 102.603927] eqos 2490000.ether_qos eth0: Link is Down
[ 105.574952] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 109.398398] eqos 2490000.ether_qos eth0: Link is Down
[ 112.330349] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 116.177148] eqos 2490000.ether_qos eth0: Link is Down
[ 119.124924] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 122.211421] eqos 2490000.ether_qos eth0: Link is Down
[ 125.262992] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 129.333565] eqos 2490000.ether_qos eth0: Link is Down
[ 132.250269] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 135.472695] eqos 2490000.ether_qos eth0: Link is Down
[ 138.477387] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx

This is a from an install via ./flash.sh and not via jetpack. Though the files flashed onto the board are just builds of mine built directly from source and using the default sample rootfs.

Is there anything unusual about what is loading down the system at the time this happens, or is it all the time? Have you tried swapping cables and actual port plugged into (or completely changing a switch if present)?

Shouldn’t be. And when i plug in an X1 jetson board w/ an X1 module into the exact some port i dont have this issue.

I’m now flashing with the Jetpack3 kernel img and rootfs to see if it exhibits the same issue.

it shows the same issue. switching to 10/100mbps via ethtool doesn’t exhibit the issue.
Using that as a work around for now.

The reason I ask about load is related to someone else reporting low network throughput while observing a constant up/down of the interface. This happened during heavy load though with a PCIe 10Gbit card on a TX1…the driver itself was not for the integrated NIC. I’m assuming this does not apply because you are using the integrated NIC with unmodified drivers.

Assuming physical wiring works on the TX1 on the same carrier board I do not know why the TX2 would constantly go up and down.

I tried a different x2 module and didnt have this issue.
May be a manufacturing issue?

I’ve not heard of that, someone from NVIDIA would have to check. Are both TX2 flashed using the same L4T?

yeah i did a 1:1 comparison where same image is loaded on the both. So definitely something with module. really strange.

Hi x1tester62,

Do you connect any other devices when test these two TX2?

Hi x1tester62,

Have you clarified and found the cause?
Any further information can be shared?

Thanks

I used usb to ethernet on ubuntu and the same problem occurred.
There was no problem connecting to the router.
It would be better not to use usb to ethernet.

I am having the same issue with an out of the box unit.

I did the setup via the ./installer.sh in the home directory of the nvidia user
There is no load on the system, I can watch the link light cycle when not connected nor running any applications

The default L4T a TX2 arrives with is R27.0.1, which wasn’t all that reliable. R27.1 is a much better release, you might try first with that since it much more reliable.

Once flashed there should be a “jetson_clocks.sh” script in “~ubuntu” or “~nvidia” directory. Before testing I suggest running (from the directory with the script) “sudo ./jetson_clocks.sh” to maximize performance.

Also, are you using a USB ethernet adapter, or integrated wired ethernet? What is the nature of the system load during the test, e.g., is it just copying a file across the network?

I am also seeing this same issue on a TX2. I have just flashed using Jetpack 3.2 preview. Connected to a 1GB switch I see the network going down every 10-15 seconds. I noticed because my ssh console would pause every few seconds.

Looking at /var/log/kern.log:

Jan 26 04:53:55 tx2 kernel: [ 1426.230684] eqos 2490000.ether_qos eth0: Link is Down
Jan 26 04:53:58 tx2 kernel: [ 1428.849028] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx

Jan 26 04:54:10 tx2 kernel: [ 1441.323189] eqos 2490000.ether_qos eth0: Link is Down
Jan 26 04:54:13 tx2 kernel: [ 1443.947768] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx

As for x1tester62 when I manually set the ethernet adapter to 100Mbps (sudo ethtool -s eth0 speed 100 duplex full autoneg off) the issue goes away. This is using the onboard ethernet on the TX2 dev kit.

I have a same or similar issue. In a network of 36 TX2s, the ethernet on 3 of them went up and down, the other 33 were okay. Replacing the 3 fixed the problem, but now others are having issues.

I’ll try the ethtool solution above.

Please update to us if this issue is still.

I’ve kludged around it by setting up a background ping. Both pinging real IP addresses and bogus IP addresses work. Not sure why some TX2s required this kludge and others don’t since I installed them all the same way. It’s required whether I have the given TX2 plugged into the TX2 development kit motherboard or an Orbitty.

So it’s not “solved” but we can live with it for now.

One thing I would be tempted to do is to find out on each of the nodes what the MAC address is, and then compare to see if any are duplicates. There is a possibility if cloning (or some other reasons from using common flash software) is used that a MAC address could be duplicated (it isn’t likely, but it is worth checking).

Since you have so many nodes you could do this via ssh at a single node for those which are working:

ssh ubuntu@<ip address> "ifconfig eth0"

…then script it for IP Address in All Addresses.

You could get this nicely formatted:

ssh ubuntu@<ip address> "ifconfig eth0" | grep 'HWaddr' | cut -d' ' -f11

Use local login for a unit missing from the network. You might also be interested in collisions since duplicated MAC addresses would cause this if they send at the same time:

ssh ubuntu@<ip address> "ifconfig eth0" | grep 'collisions:' | cut -d' ' -f11

All of the MAC addresses are unique and so far there have been 0 collisions and still without the ping, I get lots of:

Feb 11 16:37:56 tegra-ubuntu kernel: [ 609.291310] eqos 2490000.ether_qos eth0: Link is Down
Feb 11 16:37:59 tegra-ubuntu kernel: [ 612.082987] eqos 2490000.ether_qos eth0: Link is Up - 100Mbps/Full - flow control rx/tx

The MAC thing doesn’t seem to be it, but that was a good idea and would’ve explained why it did it on some TX2s and not others. Anything else like that?

MAC addr is decided by EEPROM on TX2. However, if you accidentally modified it through i2cset and gave an invalid value, it would fallback to a hardcoded value after boot up.

1 Like