brcmfmac: brcmf_set_channel: set chanspec fail, reason -52 #6049
Comments
|
I don't understand why you mention the brcmfmac message and not the rather more worrying: which happened 4 seconds earlier. How are you powering this Pi 5? Spontaneous errors like this that affect multiple subsystems are classic symptoms of insufficient power. |
|
Previously I boot rpi os via tf card without hat using official rpi power… wifi is also influenced and hardly to be connected, I supposed that this is the same issue, I will check later. Currently I use official adaptors to power rpi5, 5v3a power for hat, 3a is okay for the hat. Before I make power_save off, usually the nvme + power_save dmesg presents before brcmfmac instead of only nvme before brcmfmac |
|
|
Nice. Cause: Effect: It was going OK until you plugged in an external HUB with a number of devices attached. Is that hub, or any of the devices, powered? |
|
This is a USB Hub (actually no power), however, I found I can't access it via ssh then I use USB to find what happened, I will try to see if this is true. It takes me time to test it, so wait and I will comment here |
|
Without nvme or usb issue, this network issue is still <\details> |
|
I now use powerful pcie bridge and samsung 980 SSD |
|
I can reproduce this. Freshly flashed RPI OS bookworm arm64 image, booted using microSD card, no peripherals attached except a keyboard. I'm using wpa_supplicant + systemd-networkd instead of NetworkManager. The syptoms are: high latency spikes (~1400ms), many packets dropped (too many). Seems to only appear on linux 6.6. If I disable wifi and use a wired connection, everything returns to normal. I reproduced this on two RPI Zero 2W, two RPI 4B, two RPI 5. (am I hoarding too many PIs...) |
|
I see these messages on a raspberry pi 4 running nixos - oddly the messages appear two days before the symptoms and I seem to need quite a bit of uptime before the issue occurs. The symptoms are the same though - the above message, high latency and packet drops. I can pinpoint exactly when the symptoms start and there's no logs around that time, apart from a service which is suddenly seeing the symptoms. Nothing else in The machine is left running and has no hardware (or other) changes made to it. |
Could I know which country wifi/internet you used? It seems that it's relevant to country? Could you also give the dmesg log? |
Sure, it's Great Britain (which matches where I am). Although perhaps the below output means it's unset for phy#0?
Of course, I've attached a few others and I've annotated with some thoughts as well (issue happens at 2024-04-18 09:30:25). Let me know if this isn't enough and you want it from boot: dmesgjournalctlfix (restarting `wpa_supplicant`)restarting wpa_supplicant sorted it: Please let me know if I can provide anything else Possibly Related
|
This is actually network related… |
|
Yeah fair paint, interesting that I see no issues until ~36 hours later - I wonder if there's some bug in the firmware, like the kernel UAF (which would explain why some people see success in simple fixes, while others need a reboot). |
|
We're seeing a similar issue on Ubuntu (LP: #2063365), but
On Ubuntu we see the same messages, but they also spam the console there as our printk defaults are a little different (level 4 instead of 3 on RaspiOS) |
|
It's not clear where they are coming from, but I'm pretty sure that the chanspecs that are being complained about are indeed invalid, i.e. illegal frequencies or widths. |
|
It doesn't appear to be network-manager specific; I can reproduce the same messages with networkd in control of the interface, but it's notable in both cases wpa_supplicant is handling the interface (I haven't tried iwd yet). One other thing I did note, which may or may not be relevant, is that my interface happily sets its own regulatory domain implicitly these days (presumably the AP's setting the right "regdom = GB" bits in its beacon), but the
Is it possible that the interface is trying channels that are permitted under regdom GB, but aren't under 00, because it "remembers" that the connection it's trying had regdom GB, but the interface isn't currently configured for that? It's wild speculation on my part, but might tie in with why the messages don't appear on initial boot -- the interface wasn't regdom GB before then -- but appear later when the interface is re-configured. |
|
Aha! This thread looks particularly relevant. Unfortunately it doesn't have a definite resolution (at the time of writing), but from a skim through I think it's describing this exact issue and the root cause. |
To confirm - I'm using plain
Nice find, referencing this mail for anyone following - seems to be the basis of a fix. Am I reading it right though, the thread seems to have gone quiet as of Feb (2024)? |
|
I am having the same issue on cm4 with WiFi on an official cm4 IO board using the latest bullseye 64bit lite image. I'm just entering the CM4 world so this stumped me for a while WiFi county set to GB If anyone knows a fix, an older kernel etc let me know. |
|
Same issue here on RPI3A+ with HASSIO.. |
|
I checked my WiFi country and my tp link router was constantly setting the country to DE if I like with is reg get. Even if I set it back it changed back on a restart. I got a new router and it seems to be fixed. |
|
device : RPi5, powered by POE Hat; USB 2.0 keyboard connected issue appeared after setting up steps to reproduce:
Details
|
|
Same issue here |
|
Also having this issue on a RPI 5 running Raspberry Pi OS (Debian 12.5 Bookworm). Used to run a webserver. Started occurring sometime in the last month or so. Also have a TP-Link router, but I wasn't able to get it to broadcast any beacons containing country code (I might not be doing it correctly though). Anyways I noticed something that seemed odd to me:
iw event outputStill not sure of the actual issue, but thought I would share. |
I have some sort of same issue where I can't find my network after a while. I couldn't exactly pinpoint it though. |
|
I am seeing the same issue. I have tried both NetworkManager and wpa_supplicant with systemd and both of them eventually drop my wifi and I have to reboot. Sometimes its everyday or every 3 days. I have set my country code but I still get disconnects. I am running Arch Linux on a Rpi5 and I have a TP-Link router. I am like 6 feet from the router so it is close enough with no walls in between. I wish I could figure this out. |
|
There may be some value in investigating if firmware changes such as those mentioned in NixOS/nixpkgs#82462 work, I won't have access to my machine for a while but that's my next step. |
I'm experiencing the same issue on my Raspberry Pi 4B running Raspbian Bookworm with kernel 6.6.28+rpt-rpi-v8. My Pi is connected to my WiFi home router using the 5.24 GHz band. Coincidentally I have several 2.4-GHz devices in my home network which use services running on the Pi. Not sure if that could be related to this particular issue, but never experienced it before. I've enabled some debug options for the brcmfmac module, but honestly, I'm rather clueless about what to look for or which flags I should enable. Maybe someone with a better understanding of the module source code can point out which bits are worth enabling to better diagnose this behaviour (options taken from FMAC Debugging) It also might be worth noting that I tested both with WiFi power management enabled and disabled. I'd say that with power management enabled the percentage of lost packets is lower. It's very common for users to disable power management because it's common to find that recommendation when searching for solutions to WiFi connectivity issues. The following are kernel logs from the The CRDA regulatory domain (ES) had been defined both for I initially thought this to be an SSH server issue, as I was receiving the following message when running ssh with increased verbosity: |
|
Observed the same issue with a CM4 based device and 6.6 kernel, but they went away after the installation of the |
|
|
@rionshin Did you stop wpa_supplicant@###.service first? |
Ok - I don't have that sysfs file, explains why the change doesn't fix the issue for me. Thanks for clarifying |
|
For me it's still not working. I've checked and the I did the following steps:
I received After this I tried adding I'm now on kernel 6.6.45-v8+ on my Raspberry Pi 4 Model B Rev 1.1 I've also noticed the following warning in the kernel logs: Is anyone else getting this warning as well? |
|
@WhySoBad
If that doesn't work for you then create a file /etc/modprobe.d/brcmfmac.conf with the following content:
both of these work for me. I don't see your warning in dmesg - but I do get this:
most likely because I'm not using Debian... |
Thanks a lot for your reply. I did also notice the typos in the original post suggesting adding the text to cmdline.txt and adjusted it accordingly. However, I found out WiFi is working for me but spinning up a hotspot causes the errors which are described in this issue. I just realized the original author had an issue with connecting to WiFi. Could someone for which the |
|
One thing I've notice, if every Sunday morning, at 4am I reboot my
wireless network. When this happens, I get this message *brcmfmac:
brcmf_set_channel: set chanspec 0xd090 fail, reason -52* multiple times
and then not again unless the wireless goes down.
Mike
…On Fri, Aug 23, 2024 at 6:52 AM WhySoBad ***@***.***> wrote:
@WhySoBad <https://github.com/WhySoBad> I noticed some typos in the
earlier post about adding the disable to cmdline.txt. I'm using a Pi3+
running Linux 6.6.45-2-rpi #1
<#1> SMP PREEMPT Thu Aug 15
17:23:01 MDT 2024 aarch64 GNU/Linux. I've appended the following text to
cmdline.txt:
brcmfmac.feature_disable=0x82000
If that doesn't work for you then create a file
/etc/modprobe.d/brcmfmac.conf with the following content:
options brcmfmac feature_disable=0x82000
both of these work for me. I don't see your warning in dmesg - but I do
get this:
warning: iwgetid uses wireless extensions which will stop working for
Wi-Fi 7 hardware; use nl80211
most likely because I'm not using Debian...
Thanks a lot for your reply. I did also notice the typos in the original
post suggesting adding the text to cmdline.txt and adjusted it accordingly.
Also creating the file at /etc/modprobe.d/brcmfmac.conf did not work for
me either.
However, I found out WiFi is working for me but spinning up a hotspot
causes the errors which are described in this issue. I just realized the
original author had an issue with connecting to WiFi.
Could someone for which the brcmfmac.feature_disable=0x82000 fix worked
try to set up a hotspot and check whether any messages related to the
hotspot are printed to the kernel logs? Thanks!
—
Reply to this email directly, view it on GitHub
<#6049 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOH3HVFWFA4EI46QBNNDZWLZS45CPAVCNFSM6AAAAABE2KSIU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXGE2DKNJYGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I'm, also suffering from this problem on my 8GB Pi5. None of the remedies/workarounds proposed so far have any effect, but in my case the error is strongly correlated with the HDMI being active at the same time. Without a display connected the error has not yet shown itself. With a display connected during boot it is almost certain to show up. If a display is plugged in after boot with a WiFi connection already established it severely interferes with the WiFi bandwidth throttling the throughput to less than 4MBit. On the other hand the interference immediately stops when unplugging the display again. |
What HDMI cable are you using? Sounds like its a very noisy one. Can you try an alternative? |
Really nothing special, it's this one: https://www.delock.com/produkt/65391/merkmale.html |
|
If you can get hold of one, the official micro-HDMI to HDMI cable is well shielded and known good. I suspect the Dlock adapter you are using is introducing a EMC issue, probably at the point where it connects to the full size HDMI. Removing as many connections as possible from the link would help. |
|
I'm building a Yocto image for a Raspberry Pi CM4. The error started to occur when I've switched from kirkstone to scarthgap, so in my case it is not hardware related. |
What resolution is the display? |
Good spot! But the display in question is running at 1080p60 resulting in a TMDS clock of just 1.5GHz. Also the 2.4GHz side of the WiFi network in question is not running on channel 1. I've ordered an alternative Miro-D -> HDMI adapter as well as a complete 2 meter Micro-D -> HDMI cable to see whether those make a difference. |
|
I have now been able to give the replacement adapter a try and it immediately resolved the issue, so I didn't even have to try out the adapterless solution with the cable. Thanks for the nudge in the right direction! |
|
The original issue, Enabled Features pi@raspberrypi:~$ cat /sys/kernel/debug/ieee80211/phy0/features
Features: 00640896
MCHAN
PNO
P2P
SCAN_RANDOM_MAC
MFP
DOT11H
DUMP_OBSS # <-- here it is enabled
SAE_EXTTo disable it use modprobe parameter like above comment but with different hex value. options brcmfmac feature_disable=0x200000After Disabled pi@raspberrypi:~$ cat /sys/kernel/debug/ieee80211/phy0/features
Features: 00440896
MCHAN
PNO
P2P
SCAN_RANDOM_MAC
MFP
DOT11H
SAE_EXT... and no more error messages \o/. How to get hex value 0x200000? See the answerLook at the kernel source.
|
|
Hi, I recently encountered this exact same problem while preparing Raspberry Pi support for our distro, and I would like to share something here, and I hope this helps a little. TL;DR With wpa_supplicant 2.11, a commit1 in the hostap repository should be reverted to solve the connection problem (though it does not present the If your distro still uses wpa_supplicant 2.10, then this message is not helpful. I did several things to confirm it is a bug in wpa_supplicant: Using iwdOur distro uses NetworkManager to manage networks. So it must be using wpa_supplicant to manage and connect to WiFi networks. First I disabled NetworkManager entirely, and then started iwd and used Then I enabled the iwd backend for NetworkManager, and NetworkManager is able to connect to my WiFi network, pretty smooth. Downgrading to wpa_supplicant 2.10I reconfigured NetworkManager to use wpa_supplicant, and downgraded it to 2.10, and I was able to connect to the WiFi network, despite the "set chanspec fail" messages spamming. What happened to wpa_supplicant 2.11After reading through the mailing list, I discovered someone has reported1 this exact issue, prompting a revert can fix this. I tried reverting the mentioned commit, and yes, it worked. I don't know why using iwd does not make brcmfmac spam the kernel log with Footnotes |
sairon
added a commit
to home-assistant/buildroot
that referenced
this issue
Dec 5, 2024
Bump version to the latest synced version from RPi OS that adds firmware for new chipsets and updates BCM43455 SDIO firmware. The old firmware has some features missing which can result in the driver returning errors like: brcmf_set_channel: set chanspec 0xd099 fail, reason -52 This was tracked down [1] to usage of DUMP_OBSS feature, and while disabling this feature is a potential workaround, updating the firmware is actually the correct solution to the problem. Buildroot is using downstream kernel 6.6 already since 51b4421, so the firmware should be bumped to what RPi OS uses at this point too. [1] raspberrypi/linux#6049 (comment) Signed-off-by: Jan Čermák <[email protected]>
sairon
added a commit
to home-assistant/operating-system
that referenced
this issue
Dec 5, 2024
* buildroot c65b0306bb...b2077df873 (1): > package/brcmfmac_sdio-firmware-rpi: bump version to 4c1789e Raspberry Pi kernel 6.6 driver for BCM43455 (used in RPi 3B+/4B) calls new API which uses the DUMP_OBSS feature for channel selection. If it's not preset, it results in drivers reporting errors, e.g.: brcmf_set_channel: set chanspec 0xd099 fail, reason -52 The RPi OS firmware was updated but the package we use for this firmware contains an old version that lacks this support. Update to latest version synced from RPi upstream to fix the issues. The root cause is explained in [1] by @ragezenta. Both disabling the DUMP_OBSS and updating the firmware makes the errors go away. [1] raspberrypi/linux#6049 (comment) Fixes #3367
sairon
added a commit
to home-assistant/operating-system
that referenced
this issue
Dec 5, 2024
* buildroot c65b0306bb...b2077df873 (1): > package/brcmfmac_sdio-firmware-rpi: bump version to 4c1789e Raspberry Pi kernel 6.6 driver for BCM43455 (used in RPi 3B+/4B) calls new API which uses the DUMP_OBSS feature for channel selection. If it's not preset, it results in drivers reporting errors, e.g.: brcmf_set_channel: set chanspec 0xd099 fail, reason -52 The RPi OS firmware was updated but the package we use for this firmware contains an old version that lacks this support. Update to latest version synced from RPi upstream to fix the issues. The root cause is explained in [1] by @ragazenta. Both disabling the DUMP_OBSS and updating the firmware makes the errors go away. [1] raspberrypi/linux#6049 (comment) Fixes #3367
sairon
added a commit
to home-assistant/operating-system
that referenced
this issue
Dec 5, 2024
* buildroot c65b0306bb...b2077df873 (1): > package/brcmfmac_sdio-firmware-rpi: bump version to 4c1789e Raspberry Pi kernel 6.6 driver for BCM43455 (used in RPi 3B+/4B) calls new API which uses the DUMP_OBSS feature for channel selection. If it's not preset, it results in drivers reporting errors, e.g.: brcmf_set_channel: set chanspec 0xd099 fail, reason -52 The RPi OS firmware was updated but the package we use for this firmware contains an old version that lacks this support. Update to latest version synced from RPi upstream to fix the issues. The root cause is explained in [1] by @ragazenta. Both disabling the DUMP_OBSS and updating the firmware makes the errors go away. [1] raspberrypi/linux#6049 (comment) Fixes #3367
sairon
added a commit
to home-assistant/operating-system
that referenced
this issue
Dec 5, 2024
* buildroot c65b0306bb...b2077df873 (1): > package/brcmfmac_sdio-firmware-rpi: bump version to 4c1789e Raspberry Pi kernel 6.6 driver for BCM43455 (used in RPi 3B+/4B) calls new API which uses the DUMP_OBSS feature for channel selection. If it's not preset, it results in drivers reporting errors, e.g.: brcmf_set_channel: set chanspec 0xd099 fail, reason -52 The RPi OS firmware was updated but the package we use for this firmware contains an old version that lacks this support. Update to latest version synced from RPi upstream to fix the issues. The root cause is explained in [1] by @ragazenta. Both disabling the DUMP_OBSS and updating the firmware makes the errors go away. [1] raspberrypi/linux#6049 (comment) Fixes #3367
|
In case of HAOS, @ragazenta's message put me on the right track - the firmware we used was old and was probably lacking the DUMP_OBSS feature (or the API for it has changed, but that doesn't matter much). Apparently only RPi models using BCM43455 SDIO firmware were affected, from After the update of the Buildroot package that's fetching the firmware from a 3rd party repo, it's now: I'll suggest checking what FW version is used on other distros and installs that are exhibiting this issue. |
|
some update : I have My kernel: Linux 6.12.6-1-rpi However, I started to use the systemd-network + iwd now It temporaily works well. |
|
Same issue, also have ops nvme errors thrown when trying to enable wifi oddly |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Describe the bug
I used the rpi5 with Mcuzone MPS2280P hat for SSD, I booted the archlinux arm from nvme SSD with linux-rpi.
RPi 5 still suddenly disconnects the internet and SSH and reports
brcmfmac: brcmf_set_channel: set chanspec fail, reason -52, especially when RPi 5 has file IO and msg output, for example, updating system, journalctl, downloading/uploading sth from/to internetAfter extra settings (see Additional context), strangely, when I initially trigger to connect the internet this issue won't present, when the internet was reconnected, it would present, so this is quite similar to the issue reported to the linux kernel, see
this mail list discussion, however, I'm still not sure, because after re-connecting the internet, it can't use internet like what additional note1 mentioned.
Without netctl/iwd/networkmanager starts, it's impossible to report
Steps to reproduce the behaviour
When I start the NetworkManger on Arch Linux ARM, I got the debug msg
Device (s)
Raspberry Pi 5
System
Logs
dmesg
systemd
Additional context
Try1
I also disable the power_save via adding file named /etc/NetworkManager/conf.d/powersave.conf
Before I did so, it won't use internet.
Try2
Before installing rpi5-eeprom, the internet can be connected, however, when I tried to use the internet for any ways or ssh to the rpi5, it suddenly disconnected.
After installing rpi5-eeprom, it can be connected, however, usually, it still suddenly disconnects the internet and SSH.
Additional note1
I remove the
kmsin/etc/mkinitcpio.confso, the final hooks are
Without doing so, I'll get the report
Additional note2
I found some posts suggested that this issue is a regulatory domain issue, then, I try to follow archwiki https://wiki.archlinux.org/title/Networ ... ory_domain
set like this
iw reg set <my_country>, add country= <my_country> line of /etc/wpa_supplicant/wpa_supplicant.confThe issue is still
The text was updated successfully, but these errors were encountered: