TX1 does not boot with Intel i210 ethernet controller.

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

TX1 does not boot with Intel i210 ethernet controller.

I’d like to use an ethernet card E0X95AA (Intel i210 ethernet controller) with TX1, but TX1 does not boot.
I can use the E0X95AA with TX2 normally.

Carrior board is Jetson dev board.
JetPack is 3.1. (L4T R28.1)

I compared the igb driver source code in the kernel sources of TX1 and TX2, but there is no difference.

I tried JetPack3.3 with TX1, but TX1 does not boot.
I tried to build new igb driver (5.3.5.18) and replaced it, but TX1 does not boot.

TX2 works normally, but why does TX1 not work?
What should I do to use the Intel i210 with TX1?

Remark:
This card is VenderID=8086 and ProductID=1533. (E1000_DEV_ID_I210_COPPER)

2

Is this USB? PCIe? It sounds like USB…if so, is it USB2 or USB3? By “does not boot”, do you mean it won’t power up, or that it fails part way during boot? If part way during boot, can you provide a serial console boot log? If you need serial console information, see:
[url]https://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/[/url]
[url]https://elinux.org/Jetson/TX1_Serial_Console[/url]

3

It’s a PCIe. E0X95AA is HP’s PCIe card, which uses an Intel’s pcie-ethernet controller i210.

This error occurs during boot. I can provide some logs.

(1) TX1 JetPack3.1 ===> NG … see kernel log, line 709-712, 775
(2) TX2 JetPack3.1 ===> OK … see kernel log, line 543-544, 996, 999-1003, 1153
(3) TX1 JetPack3.3 ===> NG … see kernel log, line 737-740, 835
(4) TX1 JetPack3.3 + New IGB Driver ===> NG … see serial console log, line 1191-1194, 1419

(1) [NG]TX1_i210_JetPack31_kernel.log (219 KB)

(2) [OK]TX2_i210_JetPack31_kernel.log (123 KB)

(3) [NG]TX1_i210_JetPack33_kernel.log (188 KB)

(4) [NG]TX1_i210_JetPack33_Driver5.3.5.18_serialconsole.log (126 KB)

4

I can’t answer much which is specific. It does appear that this is an architecture-specific call (“SError”), and that there was some sort of [soft] IRQ starvation:

[   48.836295] rcu_preempt kthread starved for 5188 jiffies! g18446744073709551482 c18446744073709551481 f0x0 s3 ->state=0x1

Whether or not this is the IGB driver causing the issue, or simply the IGB driver which reported the issue, I do not know. It does seem obvious there is some sort of threading issue, but I couldn’t tell you what is blocking those threads…it could be another unrelated process/thread, or it could be something within the driver itself. One would think the driver has been reasonably well tested, but since it is calling an architecture-specific error reporting mechanism, perhaps it is just something not yet accounted for on arm64.

Considering this is occurring on boot, it seems more likely that it isn’t another application causing the stall. On the other hand, misconfigured networking may have an effect on this, e.g., a bridge setup with output and input in a loop. Was this ever booted up successfully, and then the NIC configured? Or was the NIC installed and has been doing this without configuration? If no configuration was ever added, then you might be able to eliminate configuration as an issue.

In the case that maybe it is during a DHCP call that this occurs, does anything change by booting with the ethernet connected, versus not connected? If connected, is it going to a router which sees a DHCP request (do you have a way to view the router’s log)?

5

linuxdev-san,
Thank you for your comment.
We are using a default network interface of TX1 or TX2, and we never add configuration for NIC (E0X95AA, which has i210).
And, because first I would like to confirm whether the NIC is recognized as a PCIe board by Linux for Tegra, we does not connect a LAN cable to the NIC yet

NVIDIA staff,
TX2 works well without any problem, but TX1 does not work.
Could you please give me a comment the reason why TX1 does not work and TX2 works?

6

Hi nanoto,

Below applies to both Jetson TK1 and TX1. FYI.

[url]https://devtalk.nvidia.com/default/topic/903957/jetson-tk1/tk1-intel-ethernet-controller-i210-it/post/4760503/#4760503[/url]