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