Ok, after reverting 5bf3c55 how do I quick compile it to avoid compile entire kernel?
Adrian Chadd <[email protected]> escreveu (sábado, 20/09/2025 à(s) 20:13): > > > 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 >> > -- Nuno Teixeira FreeBSD UNIX: <[email protected]> Web: https://FreeBSD.org
