On Fri, Jun 27, 2025 at 01:53:00PM +0200, Stefan Sperling wrote:
>
> On Thu, Jun 26, 2025 at 10:57:41PM +0300, Dmitry Bogdan wrote:
> > Hi Stephan and tech@
> > I have such a great NIC as AMD Lance FastEthernet (and another one, much
> > more ancient 10mbit with RJ-45 and AUI interface).
> >
> > > pcn0 at pci4 dev 6 function 0 "AMD 79c970 PCnet-PCI" rev 0x25, Am79c971,
> > rev 5: apic 24 int 21, address 00:60:b0:eb:73:c5
> > > lxtphy0 at pcn0 phy 1: LXT970, rev. 0
> > > ukphy0 at pcn0 phy 31: Generic IEEE 802.3u media interface, rev. 1: OUI
> > 0x00001a, model 0x0001
> >
> > I can not manage the interface to get stuck forever. Yes, when I run a
> > thing such as
> >
> > > iperf -u -l0 -t0 -c ${serveraddr}
> >
> > I see a tons of qdrops in kstat:
> >
> > >pcn0:0:txq:0
> > >         packets: 36982186 packets
> > >           bytes: 1675836505 bytes
> > >          qdrops: 48256453 packets
> > >          errors: 0 packets
> > >            qlen: 0 packets
> > >         maxqlen: 511 packets
> > >         oactive: false
> > >        oactives: 4607637
> >
> > and oactivee is set to true.
> > Also I can see ping drops (no buffer space avail) and delays.
> >
> > But when I stop the iperf client everything is going just fine. oactive in
> > kstat becomes false again. Pings are ok, browser works fine.
> >
> > Tested with 7.7 syspatch from 04 may AND with -current kernel + old 7.7
> > user space + you modifications with done variable in pcn_txintr func.
> > Behavior is the same in both cases.
>
> Thanks for testing! So it seems no fix is needed for pcn(4) after all.

Hi Stefan,

I finally got a bnx(4) and tested the results.

bnx0 at pci3 dev 0 function 0 "Broadcom BCM5709" rev 0x20: apic 2 int 16
bnx1 at pci3 dev 0 function 1 "Broadcom BCM5709" rev 0x20: apic 2 int 17
bnx0: address 00:0e:1e:xx:xx:xx
brgphy0 at bnx0 phy 1: BCM5709, rev. 8
bnx1: address 00:0e:1e:xx:xx:xx
brgphy1 at bnx1 phy 1: BCM5709, rev. 8

After testing bnx(4), its behavior is similar to pcn(4).
When running iperf -u -l0 -t0 -c 192.168.8.22, although OACTIVE is set and
packet loss occurs when running ping, it doesn't stay stuck for long nor
does it require resetting the interface with ifconfig.

the readings are presented as kstats:
bnx0:0:rxq:0
         packets: 4851823 packets
           bytes: 7330220164 bytes
          fdrops: 2 packets
          qdrops: 0 packets
          errors: 0 packets
            qlen: 0 packets
        enqueues: 820874
        dequeues: 820869
bnx0:0:txq:0
         packets: 907494120 packets
           bytes: 38192951883 bytes
          qdrops: 682554909 packets
          errors: 0 packets
            qlen: 509 packets
         maxqlen: 509 packets
         oactive: true
        oactives: 45370997