| 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: Fri, 10 Apr 2020 16:16:27 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Matteo Croce <mcroce@...hat.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Antoine Tenart <antoine.tenart@...tlin.com>,
"David S. Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Luka Perkov <luka.perkov@...tura.hr>
Subject: Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave
mode at probe
On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> <linux@...linux.org.uk> wrote:
> >
> > On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:
> > > On Fri, Apr 10, 2020 at 4:37 PM Russell King - ARM Linux admin
> > > <linux@...linux.org.uk> wrote:
> > > >
> > > > On Fri, Apr 10, 2020 at 03:19:14PM +0100, Russell King - ARM Linux admin wrote:
> > > > > On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> > > > > > On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@...linux.org.uk> wrote:
> > > > > > >
> > > > > > > Place the 88x3310 into powersaving mode when probing, which saves 600mW
> > > > > > > per PHY. For both PHYs on the Macchiatobin double-shot, this saves
> > > > > > > about 10% of the board idle power.
> > > > > > >
> > > > > > > Signed-off-by: Russell King <rmk+kernel@...linux.org.uk>
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have a Macchiatobin double shot, and my 10G ports stop working after
> > > > > > this change.
> > > > > > I reverted this commit on top of latest net-next and now the ports work again.
> > > > >
> > > > > Please describe the problem in more detail.
> > > > >
> > > > > Do you have the interface up? Does the PHY link with the partner?
> > > > > Is the problem just that traffic isn't passed?
> > > >
> > > > I've just retested on my Macchiatobin double shot, and it works fine.
> > > > What revision PHYs do you have? Unfortunately, you can't read the
> > > > PHY ID except using mii-diag:
> > > >
> > > > # mii-diag eth0 -p 32769
> > > >
> > > > or
> > > >
> > > > # mii-diag eth1 -p 33025
> > > >
> > > > Looking at word 3 and 4, it will be either:
> > > >
> > > > 002b 09aa
> > > > 002b 09ab
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > > > FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
> > > >
> > >
> > >
> > > Hi Russel,
> > >
> > > I have the interface up connected via a DAC Cable to an i40e card.
> > > When I set the link up I detect the carrier:
> > >
> > > mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver
> > > [mv88x3310] (irq=POLL)
> > > mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode
> > > mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off
> > >
> > > No traffic is received or can be sent.
> >
> > I've just tried with a DAC cable ("Molex Inc. 74752-9542")... works for
> > me:
> >
> > root@...in-ds:~# ip li set dev eth0 down
> > mvpp2 f2000000.ethernet eth0: Link is Down
> > root@...in-ds:~# ip li set dev eth0 up
> > mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
> > mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode
> > root@...in-ds:~# mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off
> > IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >
> > root@...in-ds:~# ping6 -I eth0 fe80::202:c9ff:fe54:d70a
> > ping6: Warning: source address might be selected on device other than eth0.
> > PING fe80::202:c9ff:fe54:d70a(fe80::202:c9ff:fe54:d70a) from :: eth0: 56 data bytes
> > 64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=1 ttl=64 time=0.344 ms
> > 64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=2 ttl=64 time=0.129 ms
> > 64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=3 ttl=64 time=0.118 ms
> > ^C
> > --- fe80::202:c9ff:fe54:d70a ping statistics ---
> > 3 packets transmitted, 3 received, 0% packet loss, time 54ms
> > rtt min/avg/max/mdev = 0.118/0.197/0.344/0.104 ms
> >
> > where fe80::202:c9ff:fe54:d70a is the IPv6 link local address on a
> > Mellanox card in a different machine at the other end of the DAC
> > cable.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
> >
>
> Hi Russel,
>
> that's it:
>
> # ./mii-diag eth0 -p 32769
> Using the specified MII PHY index 32769.
> Basic registers of MII PHY #32769: 2040 0082 002b 09ab 0071 009a c000 0009.
> Basic mode control register 0x2040: Auto-negotiation disabled, with
> Speed fixed at 100 mbps, half-duplex.
> Basic mode status register 0x0082 ... 0082.
> Link status: not established.
> *** Link Jabber! ***
> Your link partner is generating 100baseTx link beat (no autonegotiation).
> End of basic transceiver information.
>
> root@...chiatobin:~# ip link show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> mode DEFAULT group default qlen 2048
> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>
> But no traffic in any direction
So you have the same version PHY hardware as I do.
So, we need further diagnosis, which isn't possible without a more
advanced mii-diag tool - I'm sorting that out now, and will provide
a link to a git repo later this afternoon.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
Powered by blists - more mailing lists