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: <CAOAjy5TBOhovCRDF7NC-DWemA2k5as93tqq3gOT1chO4O0jpiA@mail.gmail.com>
Date:   Sun, 12 Jul 2020 13:00:48 +0000
From:   Martin Rowe <martin.p.rowe@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>, 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, 11 Jul 2020 at 19:23, Russell King - ARM Linux admin
<linux@...linux.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.