Nvethernet 6800000.ethernet eno1: Link is Down - Failed to get PCS block lock

Hello,

I am reaching out regarding an issue with an NVIDIA Jetson AGX Orin Developer Kit running Ubuntu 22.04.5 LTS (R36 release, Revision 4.7, GCID: 42132812, BOARD: generic, EABI: aarch64).

We use this system to control a Boston Dynamics Spot robot. The connection drops at irregular intervals (anywhere from a few minutes to about half), and more recently it sometimes fails soon after boot up

When the issue occurs, the following messages appear in dmesg:

nvethernet 6800000.ethernet eno1: Link is Down
nvethernet 6800000.ethernet: [xpcs_lane_bring_up][477][type:0x4][loga-0x0] PCS block lock SUCCESS
nvethernet 6800000.ethernet: [xpcs_lane_bring_up][470][type:0x4][loga-0x0] Failed to get PCS block lock
nvethernet 6800000.ethernet: [xpcs_lane_bring_up][477][type:0x4][loga-0x0] PCS block lock SUCCESS

We have observed this issue on two different robots, and it occurs regardless of the Ethernet cables used. The problem also happens while the robot is stationary, so it does not appear to be related to movement or mechanical activity. We have tried using a USB-C to Ethernet adapter, which seems slightly more stable, but the issue still occurs eventually. In some cases, reconnecting the Ethernet cable temporarily restores the connection, though it only lasts for a few minutes before dropping again. However, when we control the robot using a laptop instead of the Jetson, the connection remains stable, which makes us think the issue is specific to the Jetson setup.

Here is the dmesg log
dmesg_log.txt (85.4 KB)

Could you please advise on possible causes or recommended troubleshooting steps?

Thank you for your support.

Sorry for the late response.
Is this still an issue to support? Any result can be shared?

Hi,
The issue is still present when we use the Ethernet port. Based on our observations, we believe it may be related to the auto-negotiation process.
The logs show repeated link flapping with intermittent “Failed to get PCS block lock” messages, suggesting instability in the PHY layer rather than a pure configuration issue.

We also tried forcing a fixed link configuration:
ethtool -s eno1 speed 1000 duplex full autoneg off
and disabling EEE:
ethtool --set-eee eno1 eee off
but neither change improved stability.

For now, we are using the USB-C to Ethernet adapter, which appears to be more stable.

There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks
~0520
If your connection entity is not the robot, will this issue happened?

I just want to clarify what is the scenario that coudl alwasy reproduce this.