On Tue, Dec 27, 2022 at 06:50:55PM +0000, Jeremy Potter wrote: > One clue that I do have is that every time I restarted my Wi-Fi, the kernel > log > printed something along the lines of: > > iwx0: unhandled firmware response 0x5f4/0x2000000c
Response 0x5f4 is a "monitor notification" sent by firmware. This seems to be related to 40MHz-intolerance detection. The Linux driver forces a switch to 20MHz channel width when this event occurs, if I understand their code correctly. When 40MHz wide channels were added with the 802.11n standard, a provision was included which allows any device to prevent use of 40MHz channels in its vicinity. This is done by setting the "40MHz intolerant" flag in advertised 802.11n capabilities. Conforming devices are supposed to stop using 40MHz channels if a frame is received which contains this flag. Intel firmware seems to be keen on enforcing this by refusing to work if the driver does not comply. The OpenBSD driver does not handle this notification yet. I was hoping that relying on the AP to switch 40MHz channels off would be good enough, but apparently it is not. To make our driver handle this situation gracefully we would have to disable our use of 40MHz (and 80MHz) channels if firmware reports this event, and somehow decide to turn wide channels back on later (or stay stuck on 20MHz width until the next reboot, which is a huge performance hit). Given the information above, are you able to reproduce this problem? Is there a device under your control which is causing it? I do not have a test setup for this issue, though I could probably set something up by setting the 40MHz-intolerant bit artificially in one of my APs. But if you were able to easily verify a patch which attempts to address this, that would save me some time.
