linux-kernel - Re: net: stmmac: dwmac-imx: half duplex crash

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: <5e51e11bbbf6ecd0ee23b4fd2edec98e6e7fbaa8.camel@toradex.com>
Date:   Mon, 25 Apr 2022 15:06:15 +0000
From:   Marcel Ziswiler <marcel.ziswiler@...adex.com>
To:     "andrew@...n.ch" <andrew@...n.ch>
CC:     "linux-imx@....com" <linux-imx@....com>,
        "peppe.cavallaro@...com" <peppe.cavallaro@...com>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "joabreu@...opsys.com" <joabreu@...opsys.com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "alexandre.torgue@...s.st.com" <alexandre.torgue@...s.st.com>,
        "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "festevam@...il.com" <festevam@...il.com>
Subject: Re: net: stmmac: dwmac-imx: half duplex crash

Hi Andrew

Thanks for your help!

On Mon, 2022-04-25 at 00:01 +0200, Andrew Lunn wrote:
> On Sat, Apr 23, 2022 at 10:58:07PM +0000, Marcel Ziswiler wrote:
> > Hi there
> > 
> > We lately tried operating the IMX8MPEVK ENET_QOS imx-dwmac driver in half-duplex modes which crashes as
> > follows:
> 
> How many transmit queues do you have in operation:

Looks like NXP defaults to 5 RX and TX queues each being setup via device tree [1]. Unfortunately, upon boot
the driver only reports the RX side of things:

[    7.239604] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0

>        /* Half-Duplex can only work with single queue */
>         if (priv->plat->tx_queues_to_use > 1)
>                 priv->phylink_config.mac_capabilities &=
>                         ~(MAC_10HD | MAC_100HD | MAC_1000HD);
> 
> What does ethtool show before you force it? Does it actually list the
> HALF modes?

Good point. I was blinded by NXP downstream which, while listing all incl. 10baseT/Half and 100baseT/Half as
supported link modes, also does not work. However, upstream indeed shows only full-duplex modes as supported:

root@...din-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Full 
                                100baseT/Full 
                                1000baseT/Full 
...

Once I remove them queues being setup via device tree it shows all modes as supported again:

root@...din-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
...

However, 10baseT/Half, while no longer just crashing, still does not seem to work right. Looking at wireshark
traces it does send packets but seems not to ever get neither ARP nor DHCP answers (as well as any other packet
for that matter). Looks like the same actually applies to 10baseT/Full as well. While 100baseT/Half and
100baseT/Full work fine now.

Any idea what else could still be going wrong with them 10baseT modes?

I do know that eth0 which is FEC based instead, works just fine with any and all those modes so my network
setup otherwise seems sound.

Also the question remains, why ethtool allows such illegal configuration and even worse why the kernel
subsequently just crashes. Not sure how exactly this could be prevented though.

On a side note, besides modifying the device tree for such single-queue setup being half-duplex capable, is
there any easier way? Much nicer would, of course, be if it justworkedTM (e.g. advertise all modes but once a
half-duplex mode is chosen revert to such single-queue operation). Then, on the other hand, who still uses
half-duplex communication in this day and age (;-p).

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mp-evk.dts?h=v5.18-rc4#n110

>      Andrew

Cheers

Marcel