iwlwifi does associate and transfer data, but regularly crashes when traffic happens. It does reproducible crash when doing "ifconfig down" and then "ifconfig up". Details: [25] Intel(R) Wireless WiFi based driver for FreeBSD [25] iwlwifi0: <iwlwifi> mem 0x6002138000-0x600213bfff at device 20.3 on pci0 [25] iwlwifi0: could not load firmware image 'iwlwifi-QuZ-a0-hr-b0-70.ucode' [25] iwlwifi0: File size way too small! [25] iwlwifi0: could not load firmware image 'iwlwifi-QuZ-a0-hr-b0-69.ucode' [25] iwlwifi0: File size way too small! [25] iwlwifi0: successfully loaded firmware image 'iwlwifi-QuZ-a0-hr-b0-68.ucode' [25] iwlwifi0: api flags index 2 larger than supported by driver [25] iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37 [25] iwlwifi0: loaded firmware version 68.01d30b0c.0 QuZ-a0-hr-b0-68.ucode op_mode iwlmvm [25] iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x351 [25] iwlwifi0: Detected RF HR B3, rfid=0x10a100 [25] iwlwifi0: base HW address: ****************** It does also crash when entering certain channels, i.e. when doing something like: # for i in 1 2 3 4 5 6 7 8 9 10 11 12 13; do > ifconfig wlan0 channel $i > sleep 1 > ifconfig wlan0 up > sleep 1 > ifconfig wlan0 scan > sleep 1 > done So, it seems to have a problem with specific APs, and mine appear to belong to these. They are - SMC barricade router - USB rum device What they have in common is they are old and do only 802.11g.
Created attachment 237138 [details] printout from iwlwifi crash
(In reply to Peter Much from comment #1) Just for confirmation; this is 13.1-RELEASE as indicated in the bug report and hinted by the firmware version used not stable/13?
(In reply to Bjoern A. Zeeb from comment #2) Yes, Bjorn, this is/was 13.1-RELEASE-p2, up to here. I have now deployed 13.1-STABLE as of 38fe63afdc9d, and the behaviour is practically the same. Only there is now a kernel crash immediately.
Created attachment 237146 [details] crash messages from 13.1-STABLE (38fe63afdc9d)
Comment on attachment 237146 [details] crash messages from 13.1-STABLE (38fe63afdc9d) Thanks for this; I'll have a look.
Update: The issue is apparently not related to 802.11g only. I recently stayed at another place with some newer "Fritzbox" (that should provide at least 802.11n), and experienced the same crashes. Sadly, hadn't any time to investigate further details there.
Update: After upgrading to 13.2-RC2 there are no serious problems anymore. It is not 100% solid, but no more crashes, and when it stalls, I get it back via suspend/resume (so this works also). I am calling "service netif stop" from acpi suspend, and "sleep 3; service netif start" from acpi resume. I am happy now, and this can probably be closed. Thanks a lot, Bjorn !!
(In reply to Peter Much from comment #6) The thanks for that go to cpercival who fixed the panic with an extra check (on a condition that should not happen once I figured out how to not best),
if you can try main: please update to/past the revision mentioned in: https://lists.freebsd.org/archives/freebsd-wireless/2023-September/001441.html
(In reply to Bjoern A. Zeeb from comment #9) Hm, my piece didn't really crash in the past half year (certainyl not in a way to be attributed to iwlwifi), running 13.2-RELEASE. I don't really see what could be proven by tearing down the installation (which would be a bit of an effort)
Does that mean we can close this with "overcome by events"?
I'd say yes. As I mentioned in #7, it looked good with Your patches going into final 13.2 - and it stayed so. Just did a bunch of "service netif start/stop", and apparently no issue. I certainly agree that LinuxKPI still has room fo improvement, but it doesn't seem to hit my usecase currently. ;)