On Fri, 20 Jun 2025 12:12:14 +0200
Stefan Sperling <stsp@stsp.name> wrote:

> I could trigger the same bug on ice(4) with iperf as follows:
>   for i in `seq 5`; do (iperf -l0 -t 0 -c 2001:db8::1 -u &) ; done
> This needs another machine which runs iperf -u -s (and -V if using IPv6).
> ...
> The same bug affects bge, bnx, iavf, igc, ix, ixl, ngbe, and pcn.

My powerpc64 has bge(4); I apply your diff and bge0 works as well
as before.  I find a problem where bge0 gets stuck when I run iperf,
but only if the other side is my macppc gem(4).  Your diff does not
fix my bug.  I might have a gem(4) problem; the old macppc might be
less than reliable.

The link is an Ethernet wire with no hub,

             gem0 -------- bge0
    172.27.0.1/24          172.27.0.3/24
                     or
              re0 -------- bge0
    172.27.0.1/24          172.27.0.3/24

To trigger the bug, it is enough for the bge0 side to run a single
iperf client,

$ iperf -u -l0 -t0 -c 172.27.0.1

If the link is gem to bge, now the link is stuck.  This happens even
if there is no iperf server on the gem side.  All connections on this
link stop working.  I also lose the powerpc64's serial over Ethernet
(a BMC service on 172.27.0.2 on the same Ethernet port), but I keep
serial with my null-modem cable on the DB9 port.

To fix the link, I can either run "ifconfig bge0 down" then "up", or
"ifconfig gem0 down" then "up".  If I run "up" too quickly, it might
not fix the link.

The problem does not happen when I run the iperf client on the gem
side (with -c 172.27.0.3), or if the other side is my amd64 re(4).
--gkoehler