On Fri, Jun 20, 2025 at 11:58:37PM -0400, George Koehler wrote:
> 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.

Is the OACTIVE flag set when the bge device hangs?

The hang you are seeing here might be caused by a different bug.
Maybe a similar bug, but the situation is slightly different to vmx/ice.

bge devices provide the current ring index to consume, which the driver
reads via DMA before looping over buffers to free. It seems a situation
where bge_txeof() calls ifq_restart() without having consumed any buffers
cannot occur.

I'll drop the bge part of my diff for now.