I was just trying to sort out the issues with my wifi card intermittently dropping out under high CPU load, and while I have seen the recommendations to disable the a and x protocols by setting ‘disable_11ax=Y’ in /etc/modprobe.d/iwlwifi.conf, I wasn’t satisfied with that as a solution. Looking further into the module parameters for iwlwifi, I found this bit:
amsdu_size:amsdu size 0: 12K for multi Rx queue devices, 2K for AX210 devices, 4K for other devices 1:4K 2:8K 3:12K (16K buffers) 4: 2K (default 0) (int)
Since the parameter specifically references AX210 devices, I tried setting ‘amsdu_size=4’ instead of ‘disable_11ax=Y’, and thus far there have been no drop-outs. I would suggest anyone else running into this problem to give this setting a try!
I use Slackware 15.0 with a custom 6.5.7 kernel, but it looks like the amsdu_size parameter is also available in the default 5.15.117 kernel, so anything after that should probably have it as an option too:
$ modinfo -p iwlwifi -k 5.15.117 |grep amsdu
amsdu_size:amsdu size 0: 12K for multi Rx queue devices, 2K for AX210 devices, 4K for other devices 1:4K 2:8K 3:12K (16K buffers) 4: 2K (default 0) (int)
Going to mark this as a guide as it resolves and issue with the card as tested on Slackware - happy to give Slack some representation with its first guide here.
The access point (whose logs I have access to) shows no sign that the AX210 client is disconnecting when this happens. It’s just that IP and ARP packets at some point refuse to flow (not sure which direction or if in both).
Forcing a re-connect from the regular UI in Fedora succeeds immediately.
@dimitris I am also on an 11 gen, so it may be related. When I first installed back in 2021, I read through several different guides here, since none were specific to Slackware, and I think one of them had recommended setting ‘disable_11ax=Y’ to deal with an issue with the wifi card failing to start on resume from suspend. This year I was looking at the archwiki page for the Framework to see if I could get any new info, and the errata in one section seemed to indicate that this might not need to be set any more with a recent kernel and firmware bundle.
I tried unsetting it to test, and it seemed to work fine when resuming, but then my connection completely dropped out while I was compiling libreoffice ('cuz Slackware), and I couldn’t get it to reconnect without reloading the iwlwifi and iwlmvm modules. After that, I took a look at the module parameters, tried explicitly setting the amsdu_size according to the recommendations, and it seems to be working fine thus far (I have done a couple recompiles of both libreoffice and Firefox since then).
That’s what I recall, although I admit I am fuzzy on the details regarding my initial setup. I should probably make a better effort of taking notes on what I have set and when
@Derek_Otto otto thanks for circling back. The symptoms you describe sound very different to my very sporadic ones. Among other things, there is nothing in either the AP or the client’s logs (dmesg, journalctl). Also doesn’t seem to correlate to suspend/resume.
Setting this parameter fixed the issue with my card as well (Framework Laptop 13 Intel 12th Gen running Arch Linux). However, I used amsdu_size=3, as described in the Linux Wireless wiki, otherwise iwlmvm was complaining about an unsupported amsdu_size.
I don’t have this wifi card, but I think this is a plausible work-around because …
Back in 2010/2011 I worked for an enterprise wifi vendor, and one of the many strange bugs we dealt with was with a series of dell laptops with intel wifi cards. With other vendors APs it would work indefinitely, with ours it would drop-out after 15 minutes. After much debugging and testing, it turned out that having our AP wifi driver limit the AMSDU / AMPDU (just for the MAC address range used by this line of dell/intel wifi cards) fixed the issue. We speculated that if the wifi traffic to these cards was “too fast” it would … overheat some bit inside? cause some firmware internal index to wrap-around too soon?
Forgive my inexperience with modprobe.d files, but am I right that the full contents of /etc/modprobe.d/iwlwifi.conf would need to be options iwlwifi amsdu_size=4 in order to try this workaround?
(I think this is correct, because when I did that I saw iwlmvm: Unsupported amsdu_size: 4 in dmesg, so I changed it to 3 as suggested in the post above)
I’m not sure that this is entirely the correct place to drop this but here goes. I was having similar AX210 wifi issues…
This started soon after the latest OpenSuse Tumbleweed update. About April 1 2024. WiFi would drop (die) occasionally and sometimes (often) after a resume (not exactly the same as above) but. Here’s the thing. I had a hint from one of the entries in the syslog. Along the lines of maybe software or hardware related. Now I’ve had my Framework 13 (Intel) for 6 months at this point and electrically it has been 100%. (Mechanical failure with keyboard and Mechanical issue with track-pad aside).
I decided to re-seat the WiFi card.
Issue now gone. It would seem (at this early juncture) that an assembly issue was in the mix. I do not know if the card was not ‘properly’ inserted (It worked fine for six months) or if there is/was dirt in the contacts? But it has at least for a reasonably long time at this point (normally longer than it takes for the issue to be re-raised (normally within 24 hrs)) resolved the issue.
I place it before the court for consideration.
So I initially blamed the sw update, but after trying various options in /etc/modprobe.d and trying different firmware versions and even booting to a previous snapshot and then dropping OpenSuse and changing to Ubuntu 22.04.4 having the same issue. And then removing the later firmware variants and still having the same issue and adding all sorts of properties to /etc/modprobe.d/. And then changing to Debian 12 and still having the same issue (it has significantly older WiFi firmware). And eventually doing a BIOS config reset as well…
Hi. I would BET it is problem with overheating. My Intel Ubuntu is shutting down at some specific cases. It looks very much like CPU overheat problem. Sudden shutdown, no logs. But when I have CPU-intensive programs that do not use WiFi, it works. The shutdown only happens when there is heavy WiFi transfer with AX210.
So I started to look if buffer overruns in AX210 can shutdown whole computer and I found this thread. I suspect that buffer problems cause the chip to overheat and it sends some signal to chipset or CPU to shutdown immediately.
