netdev - 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: <YmbFblFCrGFND+h/@lunn.ch>
Date:   Mon, 25 Apr 2022 17:59:42 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Marcel Ziswiler <marcel.ziswiler@...adex.com>
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

> 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 

So maybe we actually want ethtool to report -EINVAL when asked to do
something which is not supported! Humm:

https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy.c#L783


	/* We make sure that we don't pass unsupported values in to the PHY */
	linkmode_and(advertising, advertising, phydev->supported);

So maybe the unsupported mode got removed, and the PHY was asked to
advertise nothing!

Anyway, this is roughly there the check should go.

> ...
> 
> 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).

So the answers are on the wire, just not received? 

> 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 would use mii-tool to check the status of the PHY. Make sure it
really has negotiated 10/Half mode. After that, it is very likely to
be a MAC problem, and i don't think i can help you.

> 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).

You seem to need it for some reason!

Anyway, it is just code. You have all the needed information in the
adjust_link callback, so you could implement it.

	    Andrew