Hello Adrian! I'm using iwx driver on my AX201 for some months and I saw it as stable on my laptop. (switching to iwlwifi, I saw that connection rate becomes degradated after some hours, and some crashes too)
I'm using main 20250920-e043af9ca596 . Today I upgraded to 20250920-31ec8b6407fd and iperf3 tests to my router failed: - after failed iperf3, I need to restart servive netif to get internet back. - nothing in messages, dmesg, no crash iperf3 -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 [ 5] local 192.168.1.188 port 41996 connected to 192.168.1.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.06 sec 3.75 MBytes 29.6 Mbits/sec 110 214 KBytes [ 5] 1.06-2.06 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 5] 2.06-3.06 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 5] 3.06-4.03 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 5] 4.03-5.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 5.06-6.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 6.06-7.02 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 5] 7.02-8.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 8.06-9.02 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes - rolled back to latest BE: iperf3 -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 [ 5] local 192.168.1.188 port 49619 connected to 192.168.1.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.06 sec 2.88 MBytes 22.7 Mbits/sec 274 1.41 KBytes [ 5] 1.06-2.00 sec 25.1 MBytes 224 Mbits/sec 79 280 KBytes [ 5] 2.00-3.03 sec 31.6 MBytes 259 Mbits/sec 23 249 KBytes [ 5] 3.03-4.06 sec 36.2 MBytes 295 Mbits/sec 2 263 KBytes [ 5] 4.06-5.04 sec 35.2 MBytes 301 Mbits/sec 6 266 KBytes [ 5] 5.04-6.03 sec 30.5 MBytes 259 Mbits/sec 3 236 KBytes [ 5] 6.03-7.06 sec 31.6 MBytes 257 Mbits/sec 14 214 KBytes [ 5] 7.06-8.06 sec 30.8 MBytes 259 Mbits/sec 0 368 KBytes [ 5] 8.06-9.05 sec 30.6 MBytes 259 Mbits/sec 4 339 KBytes [ 5] 9.05-10.01 sec 29.8 MBytes 260 Mbits/sec 2 330 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.01 sec 284 MBytes 238 Mbits/sec 407 sender [ 5] 0.00-10.02 sec 284 MBytes 237 Mbits/sec receiver Thanks, Adrian Chadd <[email protected]> escreveu (sábado, 20/09/2025 à(s) 01:55): > hi! > > I've been sitting on this for a while and noodling on the devices I have > here. > If you're using -HEAD, please update and let me know if wifi is OK or not > OK after today's commits. > > > First up is enabling sequence number offloading in almost everything. I > think the only thing left to do is the linuxkpi layer and then > thoroughly test the heck out of it. The TL;DR is that now the sequence > number assignment is done by a call from the driver - at the same time it's > doing encryption and other setup - rather than net80211. This removes the > need for the "TX lock" in the net80211 transmit path. > > I added this way back in 2011/2012 timeframe because I noticed that after > the vap work, sometimes i'd get dropped packets / hung data streams. What > was happening was the sequence numbers were assigned by net80211, but the > encryption - and the encryption sequence IVs - were being done in the > driver. This can happen concurrently across multiple CPUs, or even > preempted on a single CPU. It wasn't a problem on earlier single CPU setups > because preemption wasn't as aggressive, and pre-VAP the encapsulation / > encryption was actually done by the driver calling into net80211. > > I cheaped out and added that lock. It fixed it for everything, with the > cost of concurrency performance and some LORs. > > So, my goal is to finally get rid of the lock entirely during -16. > > Secondly, the NULL data frame handling. This is something that has plagued > things like iwn(4) forever, where the TX sequence number would get out of > whack with the TX DMA ring (oh no I'm going into the weeds.) Anyway, it > would cause the firmware to crash. A lot of NICs with firmware MACs > actually generate their own NULL data frames so there's no need for us to > do it. I've turned it off for a handful of NICs so we can test it out. > > Thanks! More to come once this settles. > > > > -adrian > > -- Nuno Teixeira FreeBSD UNIX: <[email protected]> Web: https://FreeBSD.org
