This issue is not resolved yet.
Jetson Linux 32.7.3 (Jetpack 4.6.3)
I confirmed it with an NVIDIA development board.
Ethernet goes down intermittently.
Mar 17 06:22:07 ubuntu kernel: [138798.936898] eqos 2490000.ether_qos eth0: Link is Down
Mar 17 06:22:09 ubuntu kernel: [138801.613498] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Do you know the cause of this problem?
The same issue has occurred in the past.
I will attach the syslog.
syslog.zip (18.8 KB)
Hi,
Please share the steps to reproduce this issue and how frequent would it happen.
Thank you for the reply.
TX2 is receiving video streaming from IP camera.
[composition]
IP camera ↔ LAN HUB(NETGEAR) ↔ TX2
[procedure]
After starting TX2, the following commands are executed.
gst-launch-1.0 rtspsrc location=rtsp://admin:crew@192.168.99.20:554/mediainput/h264/stream_1 ! ‘application/x-rtp,media=video’ ! decodebin ! nvvideoconvert ! ‘video/x-raw , format=(string)I420’ !nvvidconv ! ‘video/x-raw(memory:NVMM), format=(string)I420’ !nvegltransform !nveglglessink
After receiving the video streaming, let it continue working.
[frequent]
Happens several times a day.
[investigation]
This issue occurs only when LAN HUB is NETGEAR.
It does not occur on other LAN HUBs.
Other network devices work fine with NETGEAR HUB.
Only TX2 ethernet goes down.
Regarding NETGEAR, there is a similar comment here.
So is disabling auto-neg able to bypass this error?
yes.
Disabling auto-neg avoids this error.
but,With auto-neg disabled, I am receiving video streaming (1Mbps) but the frame rate drops.
It should be running at 100Mbps, but it feels slower.
Sorry for the late response, is this still an issue to support? Thanks
Hi,
It would be helpful if you could tell me how to deal with this issue as L4T.
We have to explain to our customers.
If L4T doesn’t fix this issue in a future version upgrade, we have to tell our customers.
If this issue is L4T specific, we accept it.
Issue related with specific LAN hub, we’re not able to do further investigation.
One thing I will suggest is that link layer negotiation is a transaction between both host and the network switch. Either end can cause lower link speeds. You would probably need a network analyzer to find out what is going on whereby it actually drops to a lower link speed. Manually setting speed of course won’t care about auto negotiation.
Another possibility is that even if both switch and host are running perfectly, it is possible that too long of a cable, or a lossy cable, could produce the need to lower speed. An unshielded lower quality cable is also a problem if in a noisy environment.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.