On Sat, 20 Sept 2025 at 12:04, Nuno Teixeira <[email protected]> wrote:
> 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 > Hm. Yeah I saw some oddness like this, even before my work. Can you try reverting the iwx diffs until it works? Not the net80211 ones; as they're only enabled if you enable the iwx ones. here's the list to try reverting one at a time. They're one or two line diffs, you can totally do it locally without checking out a new tree, and reload the iwx module. :-) commit 5bf3c5586b5e8256af0c1a6916fb5fdc6c70b3c9 Author: Adrian Chadd <[email protected]> Date: Wed Jun 4 20:50:33 2025 -0700 iwx: enable seqno offload Author: Adrian Chadd <[email protected]> Date: Fri Aug 29 22:10:22 2025 -0700 [iwx] tell net80211 not to originate NULL data frames Lemme know what you see! Thanks! -adrian > 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 >
