netdev - Re: (pch_gbe): transmit queue 0 timed out

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] [day] [month] [year] [list]

Date:   Fri, 18 Sep 2020 16:00:19 +0200
From:   Marc Leeman <marc.leeman@...il.com>
To:     netdev@...r.kernel.org
Subject: Re: (pch_gbe): transmit queue 0 timed out

> we started reproducing the problem by flooding the NIC with multicast
> packets in a directly connected setup (no switch, just device and test
> device with a single cable). At some point, the driver stops receiving
> packets; but we've noticed that the link level leds are dead too.

After some more testing the problem seems to occur more often when
subscribing and unsubscribing from multicast addresses (I don't know
if the number of userspace listeners have a real impact at the
moment). We do not seem to have the issue when running the GNU/Debian
stretch kernel (4.9.228) while we do see it when running a GNU/Debian
buster kernel (4.19.132). Having a look at the relevant changes; I'm
wondering if the patches of Paul Burton could have something to do
with this, from a quick glance, these are the ones that state that
changes have been made in the multicast behaviour.

> Reloading the driver does not re-establish the link (no-carrier), only
> a reboot when the CPU comes out of reset does.

I have not yet checked if this is related with the previous: in normal
circumstances there is little need to unload/load the normal kernel
module and this is not a normal operational situation.

g. Marc