From: Kevin Lo Subject: Re: bge/bnx/iavf/igc/ix/ixl/ngbe/pcn: ifq_restart() fix To: tech@openbsd.org Date: Mon, 7 Jul 2025 12:52:11 +0800 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