Thank you so much for your response Mr. Sperling. As an update, I have been both restarting and power cycling my computer repeatedly today and my Wi-Fi has been fluctuating between working and not working, sometimes while I am using it (i.e. without rebooting). And every time it dies, it consistently prints "unhandled firmware response 0x5f4/0x2000000c".
> 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. Does the "40MHz intolerant" flag apply to 5GHz networks? My router has both 2.4GHz and 5GHz networks, and I am connected to the 5GHz one (although some devices in my house are connected to the 2.4GHz network). Thanks again, Jeremy ------- Original Message ------- On Tuesday, December 27th, 2022 at 12:57 PM, Stefan Sperling <[email protected]> wrote: > 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.
