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  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

Powered by blists - more mailing lists