lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231027225836.11594bd5@xps-13>
Date: Fri, 27 Oct 2023 22:58:36 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Stephen Hemminger <stephen@...workplumber.org>, Wei Fang
 <wei.fang@....com>, Shenwei Wang <shenwei.wang@....com>, Clark Wang
 <xiaoning.wang@....com>, Russell King <linux@...linux.org.uk>,
 davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, linux-imx@....com, netdev@...r.kernel.org, Thomas
 Petazzoni <thomas.petazzoni@...tlin.com>, Alexandre Belloni
 <alexandre.belloni@...tlin.com>, Maxime Chevallier
 <maxime.chevallier@...tlin.com>
Subject: Re: Ethernet issue on imx6

Hi Andrew,

andrew@...n.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ