We have an older TX2 NX, where the ethernet port from the module is eth0 and the I210 controller we have on our board is eth1. Now we saw with new ordered TX2 NX modules, that the two interfaces are switched, the I210 is eth0 and the the ethernet port from the module is eth1. Was there anything changed between revisions of the module? Another thing we noticed, is that the Xavier NX is working with passive HDMI-to-DVI Adapters, whereas the TX2 NX is not. Is that expected behavior?
You can check if I210 is getting enumerated first so it becomes eth0.
We don’t guarantee any display adapters on any jetson platforms. Thus, if you want a comment here, then I would say it is expected. You can share the dmesg for us to check. Please also remember that NX and TX2 NX are just different SoCs. Thus, actually TX2 NX performance and capability may not be better than NX.
Enumeration order changes which is eth0 versus eth1, and this in turn depends on how fast your router responds. It is true that Linux installs over time might in some way change if a PCIe or integrated device first requests an address over DHCP, but in the case where both go out in the same order as before, the router might still change the order.
People who want some specific method of identifying an interface might consider using udev to create a custom device numbering. An example of this is that my Ubuntu 18.04 desktop PC has two NICs, and none have an “eth#” format…they show as “enp179s0f0” and “enp179s0f1”. That naming mechanism provides an actual physical slot (the f0 and f1 are two NICs of a single network chip). The eth# format is just an enumeration order without any mention of where the NIC is physically plugged in. You could in theory use udev to switch to the physical slot naming version instead; if for some reason you were to forcibly delay the “traditional” eth1 by one second, then likely this would also revert sort order of eth0 and eth1 back to what you wanted, but unlike udev mechanisms, this would not be a guarantee.
Note that udev can also be used to identify a specific MAC address, and rename based on that. This would be something you couldn’t use on another computer without editing for the specific MAC address on the other computer.
About DVI: There is both digital and analog versions. The digital version has a wire known as the “DDC” wire, and this is used to pass what is known as “EDID” information. This information is responsible for the plug-n-play setup of a monitor. Without this the Jetson won’t be able to configure. If your adapter passes through EDID, then the adapter shouldn’t be a problem in most cases. In the case of not passing EDID, then you might find the system is using a default setting of some sort. That default setting might differ among various versions of software that is currently installed, and thus if this is reverting to a default, then even if you use the same monitor on two different units (or the same unit flashed with a different release), whether or not the monitor works would mostly be a case of “luck”.
Thank you for your answers.
We see that the I210 is enumerated first, but we wonder why. We have two systems with the same carrier board, one newer TX2 NX and one older TX2 NX. The PCIe Bus on the newer system gets enumerated before the eqos device, in the older system it is the opposite (same software installed). We have not connected anything to the ethernet interfaces.
The answer is not necessarily something within the Jetson. It might just be the router responds faster on some MAC addresses when compared to others. It might also be (and I am really reaching here) that some sort of order of installing and setting up network cards results in one query starting in the opposite order as the query on a different Jetson. This is not considered a bug, and one must either use the correct device or set it up with software to correctly determine the correct device (if and only if you don’t allow the operating system to pick which device is used).
The most common example of how a network interface is picked is simply if the subnet directly exists for talking to a requested IP address. The name eth0 or eth1 would not matter in that case. Then, if there is no direct subnet access, the default route would be used. Still, no requirement would exist for using eth0 or eth1. As soon as you have two default routes (see the command output of route), then things might get a lot trickier depending on any overlap of subnets. It is possible for two default route servers to have different answers to the same out-of-subnet request, but even in this case the routing would not care if the name of an interface is eth0 or eth1.
A question in need of answering before continuing is this: What is your use-case which requires a specific name of eth0 or eth1? Do you have software which cares about which interface such that the built in routing and subnet behavior won’t do the job? I also suggest comparing your “route” command output if you want to pursue this (both for preferred behavior case and unpreferred case).