netdev - Re: bug: net: dsa: mv88e6xxx: unable to tx or rx with Clearfog GT 8K (with git bisect)

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: <20200711192255.GO1551@shell.armlinux.org.uk>
Date:   Sat, 11 Jul 2020 20:22:55 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Martin Rowe <martin.p.rowe@...il.com>, netdev@...r.kernel.org,
        davem@...emloft.net, vivien.didelot@...il.com
Subject: Re: bug: net: dsa: mv88e6xxx: unable to tx or rx with Clearfog GT 8K
 (with git bisect)

On Sat, Jul 11, 2020 at 06:23:49PM +0200, Andrew Lunn wrote:
> So i'm guessing it is the connection between the CPU and the switch.
> Could you confirm this? Create a bridge, add two ports of the switch
> to the bridge, and then see if packets can pass between switch ports.
> 
> If it is the connection between the CPU and the switch, i would then
> be thinking about the comphy and the firmware. We have seen issues
> where the firmware is too old. That is not something i've debugged
> myself, so i don't know where the version information is, or what
> version is required.

However, in the report, Martin said that reverting the problem commit
from April 14th on a kernel from July 6th caused everything to work
again.  That is quite conclusive that 34b5e6a33c1a is the cause of
the breakage.

The question is how - I don't get it.  None of the GT8k DSA ports are
fixed-links, not even the CPU port (which no longer even uses phylink.)
However, the MVPP2 is using a fixed-link on the port that faces the
DSA switch, which doesn't sound like a good idea to me to have
dis-similar configurations at either end.  So the addition of
"|| mode == MLO_AN_FIXED" shouldn't make any difference.

I think some debug printks would be needed to work out what's going on.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!