Re: Ethernet issue on imx6

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Andrew,

andrew@lunn.ch wrote on Fri, 13 Oct 2023 17:51:20 +0200:

> > # ethtool -S eth0
> > NIC statistics:
> >      tx_dropped: 0
> >      tx_packets: 10118
> >      tx_broadcast: 0
> >      tx_multicast: 13
> >      tx_crc_errors: 0
> >      tx_undersize: 0
> >      tx_oversize: 0
> >      tx_fragment: 0
> >      tx_jabber: 0
> >      tx_collision: 0
> >      tx_64byte: 130
> >      tx_65to127byte: 61031
> >      tx_128to255byte: 19
> >      tx_256to511byte: 10
> >      tx_512to1023byte: 5
> >      tx_1024to2047byte: 14459
> >      tx_GTE2048byte: 0
> >      tx_octets: 26219280  
> 
> These values come from the hardware. They should reflect what actually
> made it onto the wire.
> 
> Do the values match what the link peer actually received?
> 
> Also, can you compare them to what iperf says it transmitted.
> 
> From this, we can rule out the industrial cable, and should also be
> able to rule out the receiver is the problem, not the transmitter.

I've investigated this further and found a strange relationship with
the display subsystem. It seems like there is some congestion happening
at the interconnect level. I wanted to point out that your hints helped
as I observed that the above counters were incrementing as expected,
but the packets were just not sent out. My interpretation is some
kind of uDMA timeout caused by some hardware locking on the NIC by
the IPU which cannot be diagnosed at the ENET level (the interrupt
handler is firing but the skb's are not sent out, but we have no
error status for that).

Here is the link of the thread I've just started with DRM people in
order to really tackle this issue:
https://lists.freedesktop.org/archives/dri-devel/2023-October/428251.html

Thanks,
Miquèl