Message-ID: <8f8cdcf584c13faf8bcdc2abfdb62b09950ea652.camel@toradex.com>
Date:   Tue, 26 Apr 2022 12:32:16 +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>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "festevam@...il.com" <festevam@...il.com>
Subject: Re: net: stmmac: dwmac-imx: half duplex crash

On Mon, 2022-04-25 at 17:59 +0200, Andrew Lunn wrote:
> > 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!

Yeah, that's also what I was suspecting.

And running ethtool again after the crash kinda supports this theory.

root@...din-imx8mp-07106916:~# ethtool -s eth1 advertise 0x01

=> crash

root@...din-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Full 
                                100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
                                ^^^^^^^^^^^^
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 7
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: ug
        Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
        Link detected: no

> Anyway, this is roughly there the check should go.

You mean it would need an additional check against advertising nothing?

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

Yes, judging from the wireshark trace that is exactly how it looks.

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

Yes, it looks like it.

root@...din-imx8mp-07106916:~# mii-tool
eth0: negotiated 10baseT-HD, link ok
eth1: negotiated 10baseT-HD, link ok

As a matter of fact, the exact same KSZ9131RNXI PHY albeit on FEC MAC eth0 works just fine with 10Mbps half-
duplex.

> After that, it is very likely to
> be a MAC problem, and i don't think i can help you.

Sure, anyway, thanks again for all your suggestions so far. I hope somebody more familiar with the DWMAC side
of things might chime in now...

> > 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!

Well, we are gearing up on our automated testing infrastructure and asking my humble opinion on what exactly to
test concerning the Ethernet subsystem I gave the brilliant suggestion to try each and every supported link
mode (;-p). Which actually works just fine on every other hardware of ours just not the i.MX 8M Plus with the
DWMAC IP (remember, even FEC MAC works). So for now this is not something a customer of ours has real trouble
with but it raised some questions concerning whether or not and what exactly we do support...

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

Yeah, I guess that might be a neat little side project trying to get more into the topic. So far much of the
interaction within the networking subsystem in Linux is still rather a miracle to me...

>             Andrew

Cheers

Marcel

Powered by blists - more mailing lists