Comment 1 Bjoern A. Zeeb 2024-06-14 20:25:30 UTC

Thanks for the dedicated PR and the extra information.
I'll try to repro it and see what I can find out.

For (personal) reference in 2022 we put the extra debug information into the driver in e674ddec0b4138274539587fe9336b577ff1242a .  While we just fixed the Ivalid TXQ issue, people have been silent since mostly about the "Stuck Queue" part.

Comment 2 Bjoern A. Zeeb 2026-03-25 23:16:48 UTC

More information (and another report in this part of the thread):
https://lists.freebsd.org/archives/freebsd-wireless/2026-March/004142.html

I have a similar issue with an AX200 though, I don't know if the following output helps:

/var/log/messages:
kernel: iwlwifi0: Queue 2 is stuck 10 12
kernel: iwlwifi0: Microcode SW error detected. Restarting 0x0.
kernel: iwlwifi0: Start IWL Error Log Dump:
kernel: iwlwifi0: Transport status: 0x0000004A, valid: 6
kernel: iwlwifi0: Loaded firmware version: 77.30b1cbd8.0 cc-a0-77.ucode
kernel: iwlwifi0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
kernel: iwlwifi0: 0x0080A213 | trm_hw_status0
kernel: iwlwifi0: 0x00000000 | trm_hw_status1
kernel: iwlwifi0: 0x004F8F22 | branchlink2
kernel: iwlwifi0: 0x00007FC0 | interruptlink1
kernel: iwlwifi0: 0x00007FC0 | interruptlink2
kernel: iwlwifi0: 0x00015050 | data1
kernel: iwlwifi0: 0x01000000 | data2
kernel: iwlwifi0: 0x00000000 | data3
kernel: iwlwifi0: 0x9B8071F0 | beacon time
kernel: iwlwifi0: 0x0DDEFE1D | tsf low
kernel: iwlwifi0: 0x00000002 | tsf hi
kernel: iwlwifi0: 0x0000006F | time gp1
kernel: iwlwifi0: 0x0403C100 | time gp2
kernel: iwlwifi0: 0x00000001 | uCode revision type
kernel: iwlwifi0: 0x0000004D | uCode version major
kernel: iwlwifi0: 0x30B1CBD8 | uCode version minor
kernel: iwlwifi0: 0x00000340 | hw version
kernel: iwlwifi0: 0x00C89000 | board version
kernel: iwlwifi0: 0x046D001C | hcmd
kernel: iwlwifi0: 0x66F23000 | isr0
kernel: iwlwifi0: 0x00440000 | isr1
kernel: iwlwifi0: 0x08F00112 | isr2
kernel: iwlwifi0: 0x04C741DF | isr3
kernel: iwlwifi0: 0x00000000 | isr4
kernel: iwlwifi0: 0x0484001C | last cmd Id
kernel: iwlwifi0: 0x00015050 | wait_event
kernel: iwlwifi0: 0x000000C4 | l2p_control
kernel: iwlwifi0: 0x00018034 | l2p_duration
kernel: iwlwifi0: 0x00000007 | l2p_mhvalid
kernel: iwlwifi0: 0x00000000 | l2p_addr_match
kernel: iwlwifi0: 0x00000009 | lmpm_pmg_sel
kernel: iwlwifi0: 0x00000000 | timestamp
kernel: iwlwifi0: 0x000040AC | flow_handler
kernel: iwlwifi0: Start IWL Error Log Dump:
kernel: iwlwifi0: Transport status: 0x0000004A, valid: 7
kernel: iwlwifi0: 0x20000066 | NMI_INTERRUPT_HOST
kernel: iwlwifi0: 0x00000000 | umac branchlink1
kernel: iwlwifi0: 0x80455D7A | umac branchlink2
kernel: iwlwifi0: 0x80472FF2 | umac interruptlink1
kernel: iwlwifi0: 0x80472FF2 | umac interruptlink2
kernel: iwlwifi0: 0x01000000 | umac data1
kernel: iwlwifi0: 0x80472FF2 | umac data2
kernel: iwlwifi0: 0x00000000 | umac data3
kernel: iwlwifi0: 0x0000004D | umac major
kernel: iwlwifi0: 0x30B1CBD8 | umac minor
kernel: iwlwifi0: 0x0403C0FE | frame pointer
kernel: iwlwifi0: 0xC0886260 | stack pointer
kernel: iwlwifi0: 0x00B1010C | last host cmd
kernel: iwlwifi0: 0x00000000 | isr status reg
kernel: iwlwifi0: IML/ROM dump:
kernel: iwlwifi0: 0x00000003 | IML/ROM error/state
kernel: iwlwifi0: 0x000064FB | IML/ROM data1
kernel: iwlwifi0: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
kernel: iwlwifi0: Fseq Registers:
kernel: iwlwifi0: 0x60000000 | FSEQ_ERROR_CODE
kernel: iwlwifi0: 0x80290021 | FSEQ_TOP_INIT_VERSION
kernel: iwlwifi0: 0x00050008 | FSEQ_CNVIO_INIT_VERSION
kernel: iwlwifi0: 0x0000A503 | FSEQ_OTP_VERSION
kernel: iwlwifi0: 0x80000003 | FSEQ_TOP_CONTENT_VERSION
kernel: iwlwifi0: 0x4552414E | FSEQ_ALIVE_TOKEN
kernel: iwlwifi0: 0x00100530 | FSEQ_CNVI_ID
kernel: iwlwifi0: 0x00000532 | FSEQ_CNVR_ID
kernel: iwlwifi0: 0x00100530 | CNVI_AUX_MISC_CHIP
kernel: iwlwifi0: 0x00000532 | CNVR_AUX_MISC_CHIP
kernel: iwlwifi0: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
kernel: iwlwifi0: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
kernel: iwlwifi0: 0x00050008 | FSEQ_PREV_CNVIO_INIT_VERSION
kernel: iwlwifi0: 0x00290021 | FSEQ_WIFI_FSEQ_VERSION
kernel: iwlwifi0: 0x4FFCFDF0 | FSEQ_BT_FSEQ_VERSION
kernel: iwlwifi0: 0x000000F0 | FSEQ_CLASS_TP_VERSION
kernel: iwlwifi0: UMAC CURRENT PC: 0x80472b00
kernel: iwlwifi0: LMAC1 CURRENT PC: 0xd0
kernel: iwlwifi0: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
kernel: iwlwifi0: Device error - SW reset

~ pciconf -lv | grep -A4 iwlwifi
iwlwifi0@pci0:1:0:0:	class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2723 subvendor=0x8086 subdevice=0x0084
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6 AX200'
    class      = network
nvme0@pci0:2:0:0:	class=0x010802 rev=0x01 hdr=0x00 vendor=0x15b7 device=0x5030 subvendor=0x15b7 subdevice=0x5030

~ uname -a
FreeBSD 15.0-RELEASE-p7 FreeBSD 15.0-RELEASE-p7 GENERIC amd64

Happens quite reliably with an AVM FritzBox 7582 AP (I have the impression it doesn't happen or happens less with other APs) after max a few hours of high network load or a few days of average browsing network load.

Trying to restart the network stack netif restart in most cases locks up the whole system.

P.S.

~ ifconfig -a
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
	options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
	inet 127.0.0.1 netmask 0xff000000
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	groups: lo
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=0
	ether c8:e2:65:5c:7a:3d
	inet 192.168.178.156 netmask 0xffffff00 broadcast 192.168.178.255
	inet6 fe80::cae2:65ff:fe5c:7a3d%wlan0 prefixlen 64 scopeid 0x2
	inet6 2004:a62:35e2:2c01:bae2:63fc:fb5c:7c1d prefixlen 64 autoconf pltime 3600 vltime 7200
	inet6 fd00::cae2:65ff:fe5c:7a3d prefixlen 64 autoconf pltime 3600 vltime 7200
	groups: wlan
	ssid WLANSSID channel 52 (5260 MHz 11a vht/80+) bssid 44:4e:6d:40:e8:b7
	regdomain ETSI country DE authmode WPA2/802.11i privacy ON
	deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit
	AES-CCM ucast:128-bit txpower 20 bmiss 7 mcastrate 6 mgmtrate 6
	scanvalid 60 ampdulimit 64k ampdudensity 4 -amsdutx amsdurx shortgi
	-ldpctx ldpcrx -uapsd vht vht40 vht80 vht160 -vht80p80 wme
	roaming MANUAL
	parent interface: iwlwifi0
	media: IEEE 802.11 Wireless Ethernet VHT mode 11ac
	status: associated
	nd6 options=1<PERFORMNUD>

Comment 5 Bjoern A. Zeeb 2026-05-01 15:26:33 UTC

I was able to reproduce this a few weeks ago during testing fairly reliably.

The FW backtrace in this case is not helpful. It's usually a scan cmd (or statistics cmd) which the driver sends periodically (the periodic scan cmd is actually not needed and may be removed as such in future versions of the Intel driver).  One of them is just the next command which goes to firmware after the firmware goes out for lunch and that is what the backtrace reported.

I got a memory dump out of my card and sent it in the direction of Intel but I haven't heard back.

It seems to be regularly reported on Linux as well amongst various distributions over the course of many kernel releases.  I really hope this can be fixed for good but we'll see; depends on if/when I get feedback.

(In reply to Bjoern A. Zeeb from comment #5)

Thanks a lot!

Is it possible to fix the issue that restarting the driver (with netif restart) locks up FreeBSD or is that something that is not happening in your case?

Comment 7 Bjoern A. Zeeb 2026-05-01 19:58:26 UTC

In my case iwlwifi was inside a development VM with serial console.
I did not get panics most likely given I debugged the state as it was and then rebooted and didn't try to restart.

That said: are you sure it "locks up"?  I assume it panics?
If we knew where it paniced I could have a look.
Problem with that is you'd need debugging in the kernel and then blindly acquire a crashdump until drm-kmod one day will be able to restore a console again.
Does it possibly say anything about a panic upon next boot?

If you are willing to go that way I'll help you how to do all that.


My last one, where I thought that I managed to panic the laptop using wireless turned out to be an IPv6 neighbor discovery panic and not WiFi upon netif restart.

(In reply to Bjoern A. Zeeb from comment #7)

Yes, indeed I was sloppy, it panics:

Below is what it prints before it writes the dump (please note below is iOS picture text recognition which I tried to manually correct, but if something doesn't make any sense it might be my mistake).

I also have a crash dump in /var/crash which I could provide to you.

<<<
Fatal trap 12: page fault while in kernel mode

cpuid = 12; apic id = 0c

fault virtual address = 0x10
fault code = supervisor read data, page not present

instruction pointer = 0x20:0xffffffff80d8e305

stack pointer = 0x28:0xfffffe0250efda10

frame pointer = 0x28:0xfffffe0250efda40

code segment = base Øxø, limit Oxfffff, type @x1b
             = DPL 0, pres 1, long 1, def32 0, gran 1

processor eflags = interrupt enabled, resume, IOPL = 0

current process = 4804 (pool-2387)

rdi: fffff80017747000 rsi: 000000000000001c rdx: fffff80b45542278
rcx: fffff80017747000 r8: fffffe0250efd9c0 r9: 0000000000000018
rax: 0000000000000000 rbx: 0000000000000000 rbp: fffffe0250efda40
r10: 0000001000000000 r11: fffff8027d498260 r12: fffff8011869fc94
r13: fffff8011869fc00 r14: fffffe0250efda1c r15: fffff80666969380
trap number = 12
panic: page fault
cpuid = 12
time = 1777799864
KDB: stack backtrace:
#0 Uxffffffff80bbelad at kdb_backtrace+0x5d
#1 0xffffffff80b71536 at vpanic+0x136
#2 0xffffffff80b713f3 at panic+0x43
#3 0xffffffff81079fa9 at trap_pfault+0x3c9
#4 0xffffffff81050028 at calltrap+0x8
#5 0xffffffff80dabd1a at udp6_send+0x69a
#6 0xffffffff80c18bcc at sosend_dgram+0x2fc
#7 0xffffffff80c19b7f at sousrsend+0x5f
#8 0xffffffff80c21b70 at kern_sendit+0x1c0
#9 0xffffffff80c21e98 at sendit+0x1a8
#10 0xffffffff80c21cdd at sys_sendto+0x4d
#11 0xffffffff8107a8e6 at amd64_syscal1+0x126
#12 0xffffffff8105091b at fast_syscall_common+0xf8
>>>

Comment 9 Bjoern A. Zeeb 2026-05-03 16:30:04 UTC

(In reply to Stephan Lichtenauer from comment #8)

so that's another IPv6 panic (UDP) when the underlying interface goes away.  Hooray.
You should report that on net (ignoring the fact of iwlwifi getting stuck as it is just a result of the interface going because you do netif restart IF).

(In reply to Bjoern A. Zeeb from comment #9)

Thank you very much for your analysis, I have created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294984

I reproduced this problem on an Intel AX211. Under sustained traffic, the firmware reported a stuck queue and NMI, attempted
  recovery, and left the wireless interface unusable.

  The attached patch fixes the recovery path rather than the underlying firmware crash. FreeBSD still leaves
  linuxkpi_ieee80211_restart_hw() unimplemented, while iwlwifi can request recovery operations that FreeBSD's LinuxKPI does not
  support. The patch implements asynchronous hardware restart and state restoration and maps unsupported reset escalation to
  supported reset modes.

  With test instrumentation, five forced firmware NMIs all recovered successfully. Large SFTP transfers completed in both
  directions with matching file hashes, and two-minute iperf3 tests found no material throughput regression.

  The patch has been rebased onto the latest FreeBSD source commit, applies cleanly with git apply, and both affected kernel
  modules build successfully with -Werror. Its recovery logic is identical to the version tested on the AX211.

Created attachment 273114 [details]
I have no idea if this patch contains bugs.

Comment 13 Bjoern A. Zeeb 2026-08-05 15:35:09 UTC

(In reply to Oleg from comment #12)

Independent of what is (not)correct, how did that patch come together?

(In reply to Bjoern A. Zeeb from comment #13)
The artificial intelligence model gpt 5.6 wrote it for me.