Open starsareintherose opened 8 months ago
I don't understand why you mention the brcmfmac message and not the rather more worrying:
[ 313.413817] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
[ 313.422179] nvme nvme0: Does your device have a faulty power saving mode enabled?
[ 313.429908] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug
[ 313.469937] nvme0n1: I/O Cmd(0x2) @ LBA 1310068272, 32 blocks, I/O Error (sct 0x3 / sc 0x71)
[ 313.478730] I/O error, dev nvme0n1, sector 1310068272 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 2
[ 313.517822] nvme 0000:01:00.0: enabling device (0000 -> 0002)
[ 313.531362] nvme nvme0: 4/0/0 default/read/poll queues
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:
[ 1417.230236] usb 3-2: new high-speed USB device number 2 using xhci-hcd
[ 1417.384491] usb 3-2: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice= 6.55
[ 1417.392709] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1417.399876] usb 3-2: Product: USB2.1 Hub
[ 1417.403813] usb 3-2: Manufacturer: GenesysLogic
[ 1417.450861] hub 3-2:1.0: USB hub found
[ 1417.454902] hub 3-2:1.0: 4 ports detected
[ 1417.770238] usb 3-2.4: new high-speed USB device number 3 using xhci-hcd
[ 1417.898768] usb 3-2.4: New USB device found, idVendor=0bda, idProduct=8152, bcdDevice=20.00
[ 1417.907160] usb 3-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1417.914502] usb 3-2.4: Product: USB 10/100 LAN
[ 1417.918963] usb 3-2.4: Manufacturer: Realtek
[ 1417.923249] usb 3-2.4: SerialNumber: 00E04C680B3A
[ 1418.186729] r8152-cfgselector 3-2.4: reset high-speed USB device number 3 using xhci-hcd
[ 1418.374962] r8152 3-2.4:1.0: skip request firmware
[ 1418.406751] r8152 3-2.4:1.0 eth0: v1.12.13
[ 1418.420777] usbcore: registered new interface driver cdc_ether
[ 1418.425104] r8152 3-2.4:1.0 enu2u4: renamed from eth0
Effect:
[ 1418.851124] brcmfmac: brcmf_set_channel: set chanspec 0xd022 fail, reason -52
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
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 dmesg
or logs relating to networking.
The machine is left running and has no hardware (or other) changes made to it.
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
dmesg
or logs relating to networking.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?
Could I know which country wifi/internet you used? It seems that it's relevant to country?
Could you also give the dmesg log?
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:
Please let me know if I can provide anything else
net_ratelimit: 1 callbacks suppressed
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 I can also reproduce the appearance of the set chanspec messages on RaspiOS Bookworm lite on a Pi 5 powered by the official 5A power supply. Specifically:
nmcli dev wifi connect SSID password PASSWORD
(substitute SSID and PASSWORD for the test AP's)nmcli conn down SSID
(substitute SSID again)set chanspec 0xXXXX fail, reason -52
appears several times in dmesg's outputnmcli conn up SSID
(substitute SSID again)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 set chanspec
messages only appear when the regdom is unset. To clarify, if I fire up several terminals side-by-side:
watch iw reg get
(show the current regdom setting)sudo dmesg -w
(tail the kernel's log)nmcli conn down SSID
set chanspec
messages start spamming dmesg's outputnmcli conn up SSID
set chanspec
messages continue for a while, as the interface authenticates, but...set chanspec
messages stopIs 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.
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).
To confirm - I'm using plain wpa_supplicant
+ dhcpcd
, no nm etc.
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.
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
[ 7.446309] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 7.463889] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 7.466002] usbcore: registered new interface driver brcmfmac
[ 7.749121] brcmfmac_wcc: brcmf_wcc_attach: executing
[ 7.761983] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[ 7.762883] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2
[ 8.975553] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 105.537981] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 109.644677] brcmfmac: brcmf_set_channel: set chanspec 0xd022 fail, reason -52
[ 109.756626] brcmfmac: brcmf_set_channel: set chanspec 0xd026 fail, reason -52
[ 109.864470] brcmfmac: brcmf_set_channel: set chanspec 0xd02a fail, reason -52
[ 109.972425] brcmfmac: brcmf_set_channel: set chanspec 0xd02e fail, reason -52
[ 111.700435] brcmfmac: brcmf_set_channel: set chanspec 0xd090 fail, reason -52
[ 111.700845] brcmfmac: brcmf_set_channel: set chanspec 0xd095 fail, reason -52
[ 111.701231] brcmfmac: brcmf_set_channel: set chanspec 0xd099 fail, reason -52
[ 111.701618] brcmfmac: brcmf_set_channel: set chanspec 0xd09d fail, reason -52
[ 111.702006] brcmfmac: brcmf_set_channel: set chanspec 0xd0a1 fail, reason -52
[ 111.702394] brcmfmac: brcmf_set_channel: set chanspec 0xd0a5 fail, reason -52
[ 113.175791] brcmfmac: brcmf_set_channel: set chanspec 0xd022 fail, reason -52
[ 113.283801] brcmfmac: brcmf_set_channel: set chanspec 0xd026 fail, reason -52
[ 113.387945] brcmfmac: brcmf_set_channel: set chanspec 0xd02a fail, reason -52
[ 113.491819] brcmfmac: brcmf_set_channel: set chanspec 0xd02e fail, reason -52
[ 115.155892] brcmfmac: brcmf_set_channel: set chanspec 0xd090 fail, reason -52
[ 115.156181] brcmfmac: brcmf_set_channel: set chanspec 0xd095 fail, reason -52
[ 115.156466] brcmfmac: brcmf_set_channel: set chanspec 0xd099 fail, reason -52
[ 115.156751] brcmfmac: brcmf_set_channel: set chanspec 0xd09d fail, reason -52
[ 115.157035] brcmfmac: brcmf_set_channel: set chanspec 0xd0a1 fail, reason -52
[ 115.157320] brcmfmac: brcmf_set_channel: set chanspec 0xd0a5 fail, reason -52
[ 146.689762] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 150.659839] brcmfmac: brcmf_set_channel: set chanspec 0xd022 fail, reason -52
[ 150.767804] brcmfmac: brcmf_set_channel: set chanspec 0xd026 fail, reason -52
[ 150.872473] brcmfmac: brcmf_set_channel: set chanspec 0xd02a fail, reason -52
[ 150.980417] brcmfmac: brcmf_set_channel: set chanspec 0xd02e fail, reason -52
[ 152.708504] brcmfmac: brcmf_set_channel: set chanspec 0xd090 fail, reason -52
[ 152.708941] brcmfmac: brcmf_set_channel: set chanspec 0xd095 fail, reason -52
[ 152.709367] brcmfmac: brcmf_set_channel: set chanspec 0xd099 fail, reason -52
[ 152.709791] brcmfmac: brcmf_set_channel: set chanspec 0xd09d fail, reason -52
[ 152.710213] brcmfmac: brcmf_set_channel: set chanspec 0xd0a1 fail, reason -52
[ 152.710638] brcmfmac: brcmf_set_channel: set chanspec 0xd0a5 fail, reason -52
If anyone knows a fix, an older kernel etc let me know.
Same issue here on RPI3A+ with HASSIO.. Never seen it in the past... It started with the latest OS update
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 netplan
config
steps to reproduce:
Add custom config to /etc/netplan/01-iphone-ap.yaml
run netplan generate
run netplan apply
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
- shows periodic scans. Whenever there is a scan more brcmf errors show up in dmesgwpa_cli reconfigure
to reconnect to the saved WIFI network - get a FAILED error status. (This has worked in the past to reconnect to wifi, before this error started occuring.)nmcli d connect wlan0
- dmesg shows a scan that now includes my wifi network, followed by a connection message, followed by a message noting regulatory domain change, followed by another scan including my wifi network.Still not sure of the actual issue, but thought I would share.
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:
- RPI not connected. In terminal 1: dmesg showing many brcmf errors
- Terminal 2: Running
iw event
- shows periodic scans. Whenever there is a scan more brcmf errors show up in dmesg- Terminal 1: Run
wpa_cli reconfigure
to reconnect to the saved WIFI network - get a FAILED error status. (This has worked in the past to reconnect to wifi, before this error started occuring.)- Terminal 1: Run
nmcli d connect wlan0
- dmesg shows a scan that now includes my wifi network, followed by a connection message, followed by a message noting regulatory domain change, followed by another scan including my wifi network.- Device successfully connects to the network. Subsequent scans don't include my wifi network, but also don't throw any errors.
iw event output Still 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. My Pi is has a Wi-Fi dongle connected trough USB3 port.TP-Link antenna (Archer T3U Plus) , it uses a Realtek chip.
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 https://github.com/NixOS/nixpkgs/issues/82462 work, I won't have access to my machine for a while but that's my next step.
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:
1. RPI not connected. In terminal 1: dmesg showing many brcmf errors 2. Terminal 2: Running `iw event` - shows periodic scans. Whenever there is a scan more brcmf errors show up in dmesg 3. Terminal 1: Run `wpa_cli reconfigure` to reconnect to the saved WIFI network - get a FAILED error status. (This has worked in the past to reconnect to wifi, before this error started occuring.) 4. Terminal 1: Run `nmcli d connect wlan0` - dmesg shows a scan that now includes my wifi network, followed by a connection message, followed by a message noting regulatory domain change, followed by another scan including my wifi network. 5. Device successfully connects to the network. Subsequent scans don't include my wifi network, but also don't throw any errors.
iw event output
Still not sure of the actual issue, but thought I would share.
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)
options brcmfmac debug=0xCC3C
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 brcmfmac
kernel module. You can see a 4-second time gap in the logs which happened at the same time I stopped receiving ICMP echo replies from my Pi. For these tests I'm using ping -4 -n
, as I'm running an IPv4/IPv6 dual stack and don't want other factors to interfere. Power management is also enabled for my Pi's WiFi device.
May 31 16:20:12 totara kernel: brcmfmac: brcmf_rx_frame Enter: mmc1:0001:1: rxp=00000000e5ba4b84
May 31 16:20:12 totara kernel: brcmfmac: brcmf_netif_rx rx proto=0x800
May 31 16:20:12 totara kernel: brcmfmac: brcmf_netdev_start_xmit Enter, bsscfgidx=0
May 31 16:20:12 totara kernel: brcmfmac: brcmf_sdio_readframes processed 1 frames
May 31 16:20:12 totara kernel: brcmfmac: brcmf_sdio_bus_watchdog Enter
May 31 16:20:12 totara kernel: brcmfmac: brcmf_sdio_bus_watchdog Enter
May 31 16:20:12 totara kernel: brcmfmac: brcmf_rx_frame Enter: mmc1:0001:1: rxp=000000007f52f785
May 31 16:20:12 totara kernel: brcmfmac: brcmf_netif_rx rx proto=0x86DD
May 31 16:20:12 totara kernel: brcmfmac: brcmf_netdev_start_xmit Enter, bsscfgidx=0
May 31 16:20:12 totara kernel: brcmfmac: brcmf_sdio_readframes processed 1 frames
May 31 16:20:12 totara kernel: brcmfmac: brcmf_sdio_bus_watchdog Enter
May 31 16:20:12 totara kernel: brcmfmac: brcmf_sdio_bus_watchdog Enter
May 31 16:20:16 totara kernel: brcmfmac: brcmf_rx_frame Enter: mmc1:0001:1: rxp=00000000e5ba4b84
May 31 16:20:16 totara kernel: brcmfmac: brcmf_netif_rx rx proto=0x800
May 31 16:20:16 totara kernel: brcmfmac: brcmf_netdev_start_xmit Enter, bsscfgidx=0
May 31 16:20:16 totara kernel: brcmfmac: brcmf_sdio_readframes processed 1 frames
May 31 16:20:16 totara kernel: brcmfmac: brcmf_sdio_bus_watchdog Enter
May 31 16:20:16 totara kernel: brcmfmac: brcmf_sdio_bus_watchdog Enter
The CRDA regulatory domain (ES) had been defined both for wpa_supplicant
and as a kernel module parameter at boot with the following command line options:
console=serial0,115200 console=tty1 root=PARTUUID=3b0260ae-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=ES video=HDMI-A-1:1280x720@60
I initially thought this to be an SSH server issue, as I was receiving the following message when running ssh with increased verbosity:
debug2: channel 0: request window-change confirm 0
debug3: send packet: type 98
Observed the same issue with a CM4 based device and 6.6 kernel, but they went away after the installation of the wireless-regdb
package. Could you please check if this package is present on your setup?
I had wireless-regdb on my system but I didn't have the country code uncommented in the conf file . I have done this and then rebooted. I am waiting to see if I have an issue.
I am still seeing the issue. I was trying to clone chromium and I lost my internet in the middle. I couldn't just reboot as I had to kill the power. I have Kodi running and set to run in systemd so since I lose ssh and I can't drop to a shell I can't investigate the issue. I may just start kodi manually and break out the keyboard when I lose internet.
Is it possible that this has something to do with SSH? I run a Pi 5, which was freshly populated with lots of data via SFTP. I experienced several times that the Pi lost its network connection, data transfer was interrupted and SSH sessions were killed. Vice versa: after populating the Pi with data and after setting up backup based on Restic (again via SFTP), backup jobs failed from time to time. I have now switched to Restic with the Restic REST server as backup target, meaning that data transfers now run via HTTP instead of SFTP and et voilà - everything seems to work smoothly ...
I wouldn't go that far to blame SSH/SFTP, but at least my observations point into that direction.
i have the same issue with rpi4 running hassio
I removed NetworkManager and installed systemd-networkd/dhcpcd and then set this up to use wpa_supplicant. I went 4 days without an issue. I had to reboot due to a kernel upgrade. I will keep testing.
I am also experiencing this issue. I have an RPI 5 with an M.2 HAT from Pimoroni. This problem occurs only on Ubuntu 24.04 LTS with NetworkManager. When I boot into Raspberry Pi OS with the M.2 HAT still connected, it works without any issues.
Update 16.7: After a while the issue started on a clean installation of the Rasoberry Pi Os minimal too.
It lasted a half day and then I lost my wifi. I can't do a reboot as I have to unplug the RpI5 and then bootup in order for it to work. I had ssh session open but I wasn't doing anything as the system was idle. I'll have to start kodi manually and then use a keyboard to see what the issue is but I don't know how long it will be.
Still no fix? It's over a month that many Raspberry users have this problem with HAOS.. that cause a lot of instability
having same issue.. everything was working smoothly even after updating the system. This issue occurred after I reboot my system. Specs: Rasp4 with arch arm
now cannot connect to internet. Any alternative anyone ?
as a workaround I downgraded hassio to last working version 12.2 using: ha os update --version 12.2
as a workaround I downgraded hassio to last working version 12.2 using:
ha os update --version 12.2
How recent was this workaround applied? I sometimes see the driver remain stable for a few weeks before the issue occurs.
It started to fail for me after upgrade to 12.3 Tried 12.4 as well, doesn't work neither
Last working version is 12.2
On Wed, Jun 19, 2024, 19:34 Rob Pilling @.***> wrote:
as a workaround I downgraded hassio to last working version 12.2 using: ha os update --version 12.2
How recent was this workaround applied? I sometimes see the driver remain stable for a few weeks before the issue occurs.
— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6049#issuecomment-2179221529, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7VR5WGK7FSCQ3TZSBNFSLZIG6LHAVCNFSM6AAAAABE2KSIU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZZGIZDCNJSHE . You are receiving this because you commented.Message ID: @.***>
I had the same problem with Raspberry Pi OS and Ubuntu Server 24.04. After setting regulatory-domain to my country, it works ok. My country is Poland (PL).
/etc/netplan/98_wifi.yaml
network:
version: 2
renderer: networkd
wifis:
wlan0:
regulatory-domain: "PL"
dhcp4: yes
optional: true
access-points:
"my-wifi":
password: "my-wifi-password"
I upgraded to kernel 6.6.34-1 and it made it even worse.
as a workaround I downgraded hassio to last working version 12.2 using: ha os update --version 12.2
I confirm 100%.. downgraded to 12.2 and system is now stable again without that recurring error (that was also causing a costant SD activity)
I had the same error on Rasp4 64 bit:
Linux bookworm 6.6.31+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux
brcmfmac: brcmf_set_channel: set chanspec 0xd02e fail, reason -52
In my case, the message disappears after unloading and reloading the brcmfmac_wcc kernel module or activate the connection (even if it is unused)
I am also facing the same problem. Raspberry Pi 5 running Raspberry Pi OS (Debian 12.5 Bookworm) with WiFi country set to IT.
In my case I can successfully connect to 5.2GHz wifi only when I manually set the channel on the router to one between 36 (5180 Mhz) and 52 (5260 Mhz). When I set it to a channel > 52 or leave it at auto on the router, I get the brcmfmac: brcmf_set_channel: set chanspec 0xd09d fail, reason -52 error and no connection.
I'm using 80MHz as channel width.
Same problem here on a Pi 5 with: Linux jjrasp01 6.6.31+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux
A temporary workaround for me is to manually change the kernel links in "/" back to 6.6.28:
$ ls -l / |grep 6.6.28 lrwxrwxrwx 1 root root 33 Jul 7 23:15 initrd.img -> boot/initrd.img-6.6.28+rpt-rpi-v8 lrwxrwxrwx 1 root root 35 Jul 7 23:16 initrd.img.old -> boot/initrd.img-6.6.28+rpt-rpi-2712 lrwxrwxrwx 1 root root 30 Jul 7 23:16 vmlinuz -> boot/vmlinuz-6.6.28+rpt-rpi-v8 lrwxrwxrwx 1 root root 32 Jul 7 23:16 vmlinuz.old -> boot/vmlinuz-6.6.28+rpt-rpi-2712
Seems to be a problem with 6.6.31 to me.
As an update to my previous post, I happened to switch routers (from tp-link to ubiquiti) and to my surprise the problem completely disappeared. So there's a chance it could be router dependent.
Did going back to 6.6.28 fix the problem with the tp-link router?
Seems everyone on here that has the problem has a tp-link router as this is the router I have as well. Not sure if it is the tp-link hw or sw as I'm not using openwrt.
I switched routers a little while ago before that was suggested so I did not get the chance to try it.
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
kms
in/etc/mkinitcpio.conf
so, 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 line of /etc/wpa_supplicant/wpa_supplicant.conf
iw reg set
, add country=The issue is still