Jetson Xavier and LAN7800 problem

We are designing a device in which we use the LAN7800 USB Gigabit Ethernet bridge.
Currently testing these network cards on the AGX Xavier Devkits.
If we connect LAN7800 via USB 2.0, then the device works fine.
However, if we connect LAN7800 via USB 3.x cable, then LAN7800 is detected by the system, but does not work in any mode. The chip is very hot, probably there is endless communication with the system …
We connected LAN7800 to TX2 Devkit, Nano Devkit, the result is the same.
Via USB 3.x, the network card does not work.
Even installed debian linux on Jetson Nano.
This network chip works fine on PC (windows and linux), Raspberry Pi, so we believe that the problem is not in the drivers, but in the hardware of all Jetsons.
Could you tell us how to solve this problem?
USB 2.0 bandwidth is too small. = (


1 Like


We need the kernel log to debug your problem.

Please tell us your release version and share us the dmesg when this issue happens.


Jetson Xavier AGX devkit

Ubuntu 18.04.4 LTS

kernel 4.9.140-tegra

JetPack 4.4

L4T 32.4.3


On Connect
[ 436.582289] usb 2-4: new SuperSpeed USB device number 3 using tegra-xusb
[ 436.602940] usb 2-4: New USB device found, idVendor=0424, idProduct=7800
[ 436.602956] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 436.602962] usb 2-4: Product: LAN7800
[ 436.602968] usb 2-4: Manufacturer: Microchip
[ 436.602973] usb 2-4: SerialNumber: 00800F780000
[ 436.871000] libphy: lan78xx-mdiobus: probed
[ 436.949755] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 437.205577] lan78xx 2-4:1.0 eth1: kevent 4 may have been dropped
[ 437.206500] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready

On Disconnect
[ 468.486172] usb 2-4: USB disconnect, device number 3
[ 468.487292] lan78xx 2-4:1.0 eth1: Failed to read register index 0x00000120. ret = -19
[ 468.487532] lan78xx 2-4:1.0 eth1: Failed to read register index 0x00000120. ret = -19
[ 468.654315] usb usb2: usb_suspend_both: status 0

This error occurs when the Ethernet cable is connected and the link does not up:
[ 437.205577] lan78xx 2-4:1.0 eth1: kevent 4 may have been dropped


Just wanted to confirm that I have also seen this exact same issue with the LAN7800 on the Xavier, and I got the idea to pull the USB 3.0 caps to force it into USB 2.0 mode from an old forum post (so someone else has come across this as well).

In my case, USB 2.0 would have been fine, but in addition to USB 3.0 completely not working, running it at USB 2.0 speeds seems to cause a conflict with other USB ports on the Xavier. When the LAN7800 is idle, the other two USB ports work fine, but when using almost ANY bandwidth through the LAN7800, we start noticing greatly reduced bandwidth on one of the two other USB ports.

I suspect that it’s a buggy kernel driver, not a hardware issue. For some reason the Nvidia kernel has an ancient LAN78xx driver (IIRC 1.0.4 from 2016), even though there have been quite a few updates since then. We put a little bit of effort into rebuilding the kernel and rolling updates into this driver, but unfortunately there are quite a few necessary changes outside just the lan78xx driver file, which looked like a large undertaking to bring up to the current version (maybe this is why Nvidia is still using the old driver?).

As a test, I plugged in a USB Ethernet adapter with an Asix chipset, and it worked perfectly at USB 3.0 and without any USB bandwidth issues.

Just wanted to share my experience as well, and say that I’m also very interested in a fix if one is made available.

It may need the vendor’s help to share why their driver is not able to probe the device.

I just read the driver code and notice

    if (!schedule_delayed_work(&dev->wq, 0))
  		netdev_err(dev->net, "kevent %d may have been dropped\n", work);

But that function returns %false if the work was already on a queue. Thus, it looks not a fatal one.


The LAN7800 eval stick works on 64-bit x86 configurations
with Windows 10 and Ubuntu 20.04, 16.04, 16.10, 17.04.

The I used the same eprom binary for the onboard LAN7800 port.
If I connect the LAN7800 eval kit it a USB3 cable it doesnt work.
But with a USB2 cable it works.
Could that be related to the USB stack?

I would be happy if you share your thoughts?


Hi WayneWWW,

The driver can probe the device in both USB 2.0 and USB 3.0 cases successfully. It also works in USB 2.0 mode perfectly. The problem is that the link connection goes never up in USB 3.0 mode.

May be the problem is not related to LAN78xx driver. There is no seperation between USB 2.0 and USB 3.0 in the driver source code on Kernel 4.9.140. Besides, I also checked the LAN7800 eval stick with Ubuntu 16.04 (Kernen 4.4), 16.10 (Kernel 4.8), 17.04 (Kernel 4.10) on an Intel PC and couldnt see any problem.

Would it be possible to check this from the NVIDIA side?


It has been a while since the last update of this thread, thus I think you should share what you’ve found because it seems other people here cannot make the device work even if usb2.0 mode.

Could you share more detail about your software release and configurations?

Also, need the dmesg of usb3.0 NG case and USB2.0 case.

I apologize that we did not write immediately,
the priority of this task for us has shifted a little.
We contacted Microchip and this issue was addressed by the chip design engineers.
The problem is with the driver.
The engineers at Microchip have provided a solution to this problem.
In short, it all boils down to the following:

PHY_POLL patch to lan78xx driver

Linux 4.9.x went through many changes in PHY library.
Some of the changes cause the lan78xx driver’s PHY interrupt to be incompatible.

The workaround is to switch to PHY polling.
The modification is one line in the lan78xx.c in the below.

in lan78xx_phy_init(),



phydev->irq = PHY_POLL;

After editing the driver, the chip works fine.




I tested it and it works as expected know.


1 Like

Wow, this really solve our problem.