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

From: Martin Rowe <martin.p.rowe@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
	netdev@vger.kernel.org, davem@davemloft.net,
	vivien.didelot@gmail.com
Subject: Re: bug: net: dsa: mv88e6xxx: unable to tx or rx with Clearfog GT 8K (with git bisect)
Date: Sun, 12 Jul 2020 13:00:48 +0000	[thread overview]
Message-ID: <CAOAjy5TBOhovCRDF7NC-DWemA2k5as93tqq3gOT1chO4O0jpiA@mail.gmail.com> (raw)
In-Reply-To: <20200711192255.GO1551@shell.armlinux.org.uk>

On Sat, 11 Jul 2020 at 19:23, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> 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.

I tried it anyway and couldn't get any traffic to flow between the
ports, but I could have configured it wrongly. I gave each port a
static IP, bridged them (with and without br0 having an IP assigned),
and tried pinging from one port to the other. I tried with the
assigned IPs in the same and different subnets, and made sure the
routes were updated between tests. Tx only, no responses, exactly like
pinging a remote host.

I'm now less confident about my git bisect, though, because it appears
my criteria for verifying if a commit was "good" was not sufficient. I
was just checking to see if the port could get assigned a DHCP address
and ping something else, but it appears that (at least on 5.8-rc4 with
the one revert) the interface "dies" after working for about 30-60
seconds. Basically the symptoms I described originally, just preceded
by 30-60 seconds of it working perfectly. I will re-run the bisect to
figure out what makes it go from "working perfectly" to "working
perfectly for less than a minute", which will take a few days.