netdev - Re: Ethernet issue on imx6

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] [day] [month] [year] [list]

Message-ID: <20231117160928.04ba5359@xps-13>
Date: Fri, 17 Nov 2023 16:09:28 +0100
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

Hello,

> 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

For future reference, the thread mentioned above unfortunately did not
lead to any discussion (I admit it's not a common topic though) and
further investigation pointed at the DDR configuration. I had a hard
time making a link between the reset pad of the DDR controller being
misconfigured and the Ethernet drop rate, I still fail to do, but in
practice this very little change apparently had a significant impact and
totally solved our issue:
https://lore.kernel.org/u-boot/20231117150044.1792080-1-miquel.raynal@bootlin.com/

Thanks to all of you for your help and feedback,
Miquèl