brcmfmac: brcmf_set_channel: set chanspec 0x100c fail, reason -52

[Paul Larson]

On the noble server release candidate image testing, I noticed that the automated wifi tests we run for certification were passing, but they logged some errors from dmesg related to brcmfmac. The log is filled with lots of these errors:

kern :err : [Wed Apr 24 11:19:12 2024] brcmfmac: brcmf_set_channel: set chanspec 0x100c fail, reason -52
kern :err : [Wed Apr 24 11:19:12 2024] brcmfmac: brcmf_set_channel: set chanspec 0x100d fail, reason -52
kern :err : [Wed Apr 24 11:19:12 2024] brcmfmac: brcmf_set_channel: set chanspec 0x100e fail, reason -52
...

To be clear, it was able to get a wifi connection, but something seems off with this.
I've noticed this on rpi4 and rpi5 so far, not sure about others yet

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/2063365

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Philip Meulengracht (the-meulengracht)]

This happens too with Ubuntu Core 24 during console-conf WiFi configuration, and provides a less-than-nice experience.

[Dave Jones (waveform)]

I can reproduce this fairly reliably on the Ubuntu 24.04 Server for Pi image. Strangely, it doesn't seem to occur on the initial use of the wifi on boot, but running "netplan apply" (causing the interface to re-connect to the AP), reliably causes several "set chanspec" messages to appear in dmesg.

The issue occurs whether or not ethernet is also in use, and setting the regulatory domain (a common suggestion in various other reports of this issue found online) does not appear to make a difference either.

Speaking of other reports, https://github.com/raspberrypi/linux/issues/6049 is an open issue on the upstream kernel that appears to be identical to this one.

[Dave Jones (waveform)]

Aha! I can reproduce this on RaspiOS bookworm too, but while the messages appear in dmesg, they *don't* appear on the console, but that's just due to different printk default (level 3 instead of 4 on Ubuntu). So, this is an upstream issue.

[Dave Jones (waveform)]

I've added some notes to the upstream bug, including an observation about the regulatory-domain. My thoughts earlier that it doesn't affect anything may be partially wrong (the issue still occurs, but *potentially* only when the interface has no regdom prior to authentication? We'll see what upstream say about it -- I may be barking up the wrong tree there).

[Juerg Haefliger (juergh)]

https://<email address hidden>/