Wifi: Firmware crashing regularly on RPi 0W2 #1768
Comments
|
There's a ticket open with Synaptics for this issue. I'll report back with any questions or findings. |
|
I had the same issue with a Raspberry Zero 2 W and Dietpi OS. With like every day unrecoverable brcmf_fw_crash. Example for the crash: |
|
Can you do what @porst17 did and add |
|
I also want to add that my setup uses the same SSID for the main router and the repeater. This is the default setup of the wifi mesh system (AVM Fritz!Box) I have been using for years without problems on the many WiFi devices I own. It's just the RPi 0W2 that doesn't seem to like it. 🤷♂️ |
|
I have also been experiencing this on my 0W2 for two weeks, ever since I moved the pi from a wall socket to a power strip, so it might have something to do with voltage. I use the "official" adapter. |
|
Logs from a recent crash: |
|
Thanks for that, @WLBQE. I've passed it on. |
|
I have the same issue with firmware from next branch. |
|
I've received two test firmwares from Synaptics, numbered 1 and 2. There was no accompanying information, so I don't know if they might be a fixes or whether they are just to gather more information. Firmware 1: https://drive.google.com/file/d/1UghnB9zZ7ydpVlYaTbp8F1M0rqEX_DZK/view?usp=share_link To back up the original firmware: To install (change To revert to the original firmware: |
|
Unfortunately it would be pointless to test those test firmwares for me I think, because I still couldnt reproduce the issuse for some reason. |
|
I am running the |
|
Unfortunately, the Wifi firmware ( |
|
Thanks - I'll feed back your findings. Did you try Did anybody else try the new firmwares? |
|
I was running |
|
Thanks again. Until we are able to reproduce the issue we are relying on people like you. |
|
In my case test1 crashes just as often, additionally bluetooth loses connections. test2 works fine so far. |
|
Interesting. Do you have an example log from a test1 crash? |
I've been running |
|
Indeed - it is strange. @mati75 It would be helpful if you could find the time to capture and post a crash log from the test1 firmware. |
|
Maybe there are more different issues in the firmware that needs different solutions. |
|
@pelwell I will try catch crash at the weekend. I only caught that the crash occurs when dhcpv6 loses connection, but I wasn't able to save dmesg. |
connections down, in the same network pi0w, rpi4 working fine |
|
All: I'm also seeing this problem, I think. My Pi Z2W is living in a Ubiquiti wireless environment. Four UAP-AC-LR access points, all advertising three different SSIDs, on SSID reserved for IoT devices and not broadcasting it's ID. The Z2W is on the IoT WiFi SSID. It can really only see two of the access points. I used Unifi controller to lock the Z2W to a single AP. This reduced spontaneous reboots from a couple of times a day to about once or twice a week, but still has not fixed the problem. Running box stock Raspian 64 bit. Here is a syslog snippet from the latest reboot. You can see the usual FIPS logging nonsense, some trouble with the WiFi connection, then BOOM! |
|
[ Stop editing the log - I've fixed it up once already ] |
|
Sorry, Phil, but I had no way of knowing you and I were editing in parallel. Your last edit truncated the log. It appears fine now. I could not get it to show properly in code tags for some reason. |
|
The WiFi firmware crashing (if that's what's happening to you - you don't appear to have added brcmfmac.debug=0x100000 to /boot/cmdline.txt as requested above) shouldn't cause your Pi to reboot. How are you powering the Pi and its peripherals? |
|
I made the change and rebooted as requested. Now we need to wait for a spontaneous reboot. Where should I look for the relevant log entries? The Z2W is powered by a large, commercial, 5VDC power supply that can provide 5A. The only peripheral the Z2W is powering is a single RS232-TTL level translator IC on the 3.3VDC bus which consumes well under 10ma. The Z2W never reports undervoltage or throttling. The SD card has been replaced once as a possible source of the problem. |
|
The additional log entries will go into the kernel log, which should appear in the main system log as above. |
|
BTW: I am running @Krautmaster 's workaround since April 19 without a single crash. I am hesitating to switch to any of the test firmwares again (didn't try test4 or test5) ... |
|
Thanks for the hint. The Firmware from Krautmaster's workaround crashed when I turned off WLAN on my router. So the best choice for me at the moment is the firmware test5, as long as there is no better solution. Jul 25 09:24:04 pi-ager kernel: [45887.142121] brcmfmac: CONSOLE: wl0: link up (wl0) |
|
After crashing every night, I now installed firmware test5 on my RPi 0W2 (with piSCSI-Board) and no crashes since then (for two days). |
|
Can anyone provide information on the following problem: My RPi 0W2 is equipped with the Broadcom chip BCM43430/2 with the signature 0x1542a9a6. As described in my earlier postings, there are occasional crahes with the original firmware of the Pi OS Bullseye for this chip. Now I have seen in the syslog of a user that another Broadcom chip BCM43430/1 with the signature 0x1541a9a6 is installed in his RPi 0W2. The system loads a different firmware brcmfmac43436s-sdio accordingly. I would be interested in the following: Information on this topic is very welcome. |
|
Hi everyone, sorry for jumping on this stale thread but I've just started having some issues with my RPi 0W2. Just a brief history of what happened before having any issue. I recently changed the ISP and with that, the modem, and everything worked fine for the first week, but I was having signal issues around my house so they installed a mesh repeater to strengthen the signal and all the problems started. Since then I've started losing connection every 24h-ish. Stock firmware is: Firmware details
|
|
I am also suffering from the firmware crashes (though without the reboot). However, one peculiarity from my side is that I don't run a WiFi Mesh. Some informations:
I'll try running test5 version of the firmware first, and afterwards the workaround suggested here. Let me know if there is anything I can do to help in further debugging the root-cause. Logs of a crash (I had a cron checking and restarting the wifi interface running as a first attempt before I identified this issue here): iw phy |
Please also add |
|
@pelwell here a log of a crash with debug information for the version Should it help: My Access Point is a FritzBox 6490 running FritzOS 7.57 (it sits behind a FritzBox 5530, but I don't run a mesh and the 5530 has wifi disabled alltogether). I'll now try with the firmware posted by Krautmaster suggested here Edit: As of 2024-01-14, I have not observed any more crashes with the firmware posted/suggested by Krautmaster |
|
Report: Edit: Also works when changing parameters on the same SSID on the AP such as switching to WPA3 and enabling MFP then switching back to WPA2 w/o MFP and the Pi reconnects without crashing. |
|
Having the same issues with octopi when viewing pi cams - I am adding:
to cmdline.txt and I am trying the work-around:
|
|
Had a failure :( Here is the logs: |
|
Problem is still existing. Trying now the solution from Krautmaster #1768 (comment) Current orignal firmware is from So the firmware that seems to work is ~1 year before official release of RPI 2 W... |
|
Hello, Edit: Uptime now 81 Days |
|
Same issue here:
|
|
+1 on this. installed firmware was 9.88.4.77 |
|
Have the same issue. Raspi was not reachable and after about 15min I came back, to only find this in the log, which also happend once at midnight: |
|
Hello, I still need to use the Krautmaster fix. If this is the way to go, maybe we shoud push this to the repo till the chip manufacture has resolved the issue? |
|
Tested the fix and it doesn't work on raspberry pi OS (64 bit) Lite on a Raspberry Pi Zero 2 W. Basically if the pi downloads a lot of data (in my case around 10 minutes of downloading) and heats up, it suddenly shuts off the wifi and I can't ssh into it anymore. Only fix is to unplug it, wait for it to cool down (around 2 minutes) and plug it back in. If it doesn't cool down it will refuse to connect to the wifi. I don't have a heatsink or a fan attached to it. For reference the CPU reached around 55C right before it crashed. I have tried most of the fixes on the internet with no luck (like |
|
To be honest: this sounds more like a hardware issue to me, than driver / firmware problems people mentioned above. |
Small update, the problem was insufficient memory. I increased the swap to 1GB and haven't had any major problems since then. |
|
Is there any permanent fix for this one? :) |
|
I get the wifi interface completely locking up as well on a Zero W2 running Raspbian Bullseye. After around 10-20 minutes of operation, it locks up and is no longer responding to pings or anything. The OS itself is still alive though. The WLAN AP is an AVM FritzBox 7530 AX, no mesh, 2.4+5 GHz, WPA2+WPA3 PSK. Device/OS info: dmesg log of everything related to wifi: |
|
That's the SDIO interface malfunctioning, probably due to undervoltage. |
|
Strange. The RTL-SDR is supposed to draw around 300 mA and that's the only thing attached to the Pi - the power supply is rated for 3 amps. That should be more than enough, although I'll see if I can get myself a voltage graph. Is the SDIO interface running off of the 3V3 or 5V rail, or is it on some lower-voltage rail of an onboard LDO regulator? |
That's not the problem - it's the onboard SMPS, the way power is routed, and the way the system can respond to rapid changes in demand. The SMPS is driven from 5V, and almost everything else comes from its 3V3 output. How is the RTL-SDR dongle attached? Is it possible to route power to it in some other way? |
|
It's attached via a bog standard micro-USB OTG cable, so in theory (correct me if I'm wrong) the power for the RTL-SDR should come directly off of the micro-USB port where the PSU is attached. I tried disabling the GPU (gpu_mem=16, removed dtoverlay=vc4-kms-v3d), disabled BT (dtoverlay=disable-bt), disabled audio (dtparam=audio=off), CSI/DSI (camera_auto_detect=0, display_auto_detect=0), and now it seems the system is stable. Too bad given I had intended using the HDMI port to run a display with a map of the ADS-B plane records, but meh. Is this a known limitation of the onboard SMPS? IMHO, it should be spec'd large enough to run the CPU at full load with all features enabled... |
|
I'm not a hardware engineer, but this is my understanding. It's true that the 5V for the USB socket is wired directly to the 5V on the PWR socket, but that means that the 5V input to the SMPS can receive a varying input voltage depending on how the current draw of the peripheral varies and how quickly the external power supply adjusts. Secondly, the varying demands of the SoC and onboard peripherals means that under load it can be hard to maintain sufficient voltage at all parts of the system. You could try adding "over_voltage=2" (or 4) to config.txt to give the system a bit more headroom, but if the particular SoC on your Z2W is one that needs just a bit more voltage to keep it happy then you may already be at the limit. |
|
Do we still need to change the config.txt even if we are using the official power supply of raspberry pi zero 2w? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Describe the bug
The firmware of the onboard WiFi on my RPi 0W2 crashes almost every day:
It seems I can only get it back online by restarting the RPi. I am tracking this issue for the past months and already tried running with
over_voltage=2as suggested elsewhere, but no luck.Expected behaviour
WiFi firmware does not crash.
Actual behaviour
WiFi firmware crashes.
System & Logs
See the attached raspinfo.txt.
Additional context
I can't confirm it 100% yet, but the crash seems to happen whenever the connection is handed over from my WiFi router to my WiFi repeater or vice versa.
The text was updated successfully, but these errors were encountered: