Created attachment 236774 [details] Stacktrace On a HP Spectre x360 16-f1013dx with an Intel AX211 Wi-Fi adapter, when I connect to an AP (Netgear Orbi Wi-Fi 6 in my case), I get a kernel panic. Other APs, such as a Google Pixel 6 hotspot also give me a similar issue. A HP Spectre x360 14-ea0023dx with an Intel AX201 also had a similar issue with CURRENT, but not to the same extent on 13.1. <118>Starting wpa_supplicant. <6>wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost <4>Invalid TXQ id panic: lkpi_sta_auth_to_scan: lsta 0xfffff80001b65800 state not NONE: 0, nstate 1 arg 1 cpuid = 15 time = 1663959560 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe011b80ec60 vpanic() at vpanic+0x151/frame 0xfffffe011b80ecb0 panic() at panic+0x43/frame 0xfffffe011b80ed10 lkpi_sta_auth_to_scan() at lkpi_sta_auth_to_scan+0x253/frame 0xfffffe011b80ed80 lkpi_iv_newstate() at lkpi_iv_newstate+0x1b3/frame 0xfffffe011b80edf0 ieee80211_newstate_cb() at ieee80211_newstate_cb+0x1f5/frame 0xfffffe011b80ee40 taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfffffe011b80eec0 taskqueue_thread_loop() at taskqueue_thread_loop+0xc2/frame 0xfffffe011b80eef0 fork_exit() at fork_exit+0x80/frame 0xfffffe011b80ef30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe011b80ef30 --- trap 0x68ed68ed, rip = 0x9ec89ec89ec89ec8, rsp = 0x5db25db25db25db2, rbp = 0x3ed33ed33ed33ed3 --- Full core dump attached. I can share more if needed.
So net80211 complains about a state transition not finished and then LinuxKPI 802.11 complains that states don't match and hits the assertion. It seems the original net80211 logging is more than a decade old; maybe I should go and hunt that down first; Also it seems you are still seeing an "Invalid TXQ" after all this but I am not surprised if we didn't actually set things up properly. I doubt this is special to the AP or to the very specific chipset.
I have the same behavior with an AX201 and am happy to help in any way that I can.
Intel Wi-Fi 6 AX201 =================== (In reply to Zoë Knox from comment #2) Which version of FreeBSD, exactly? uname -aKU For me in March 2023, connections were free from kernel panics. Whilst <https://bsd-hardware.info/?probe=9ac4738956&d=FreeBSD#pci:8086-a0f0-8086-0074> shows 'detected', connections did work. uname output at <https://bsd-hardware.info/?probe=9ac4738956&log=uname>
(In reply to Graham Perrin from comment #3) Hey Graham :) Here's the info. Bear in mind this is my ravynOS kernel so it won't correspond 1:1 to the upstream source commits. This particular kernel is based on freebsd/main commit 2b4b3789f877918e9e89a217d3b25d854d1a2267. We don't touch the device driver code. FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #10 main-n767-fce4063d4a30: Sat Mar 18 14:47:34 EDT 2023 zoe@:/usr/obj/usr/src/amd64.amd64/sys/RAVYN amd64 1400083 1400081 iwlwifi0@pci0:0:20:3: class=0x028000 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0f0 subvendor=0x8086 subdevice=0x0074 vendor = 'Intel Corporation' device = 'Wi-Fi 6 AX201' class = network I'll try again with the latest upstream changes as soon as I patch up some libmach build issues.
(In reply to Zoë Knox from comment #4) That means you should have: commit 3689f8aeab82150da6789be87b6c2f9385810c23 Author: Colin Percival <cperciva@FreeBSD.org> Date: Sun Mar 5 12:10:57 2023 -0800 If you do I'd wait a few days with updating.
(In reply to Bjoern A. Zeeb from comment #5) Indeed I do... what am I waiting on? :)
With the latest changes (commit 743516d51fa7c7f35b2156b1985f100ddb64abc2) merged, I am no longer seeing panics from iwlwifi. ^_^ However it is still pretty spotty to get connected and the "error -5" stuff persists.
if you can try main: please update to/past the revision mentioned in: https://lists.freebsd.org/archives/freebsd-wireless/2023-September/001441.html
Did you have any chance to try the given revision or any recent 14 or 15?
It does not crash anymore, the last time I tried CURRENT on a HP Spectre x360 2 months ago. As a note, I gave up on FreeBSD outside of my OPNsense box. I now run Fedora as a desktop/laptop and Rocky as a server. In turn, access to FreeBSD will be much harder for me going forward.