wlan freezes in raspberry pi 3/PiZeroW (Not 3B+) #1342
Comments
|
EDIMAX EW-7811UN.... That's using rtl8188cus chipset, IIRC. If you haven't already got one, create /etc/modprobe.d/8192cu.conf, with content.... Disable power managementoptions 8192cu rtw_power_mgnt=0 rtw_enusbss=0 |
|
The rpi3 actually uses the brcmfmac driver for the inbuilt wifi I think the newer raspian kernels have patched this already to disable power saving by default but I don't think it's in this 4.5 branch yet What I'm doing at the moment (gentoo install) is the following at bootup to disable the power saving on the wifi card iw wlan0 set power_save off |
Yes, I know. Oh I see. He's not using the EDIMAX EW-7811UN dongle anymore. He used to use it with RPi2. |
|
yes I don't use the usb wifi any longer, how do I set up the cmd line to turn off the power management? |
|
Not sure for raspian, since I'm using gentoo it'll be different |
|
Seems to work since I have turned the powermanagement off I haven't had another wlan crash. |
|
Just to mentioned it, to restart the wlan automatically after a crash, this here helps: |
|
BTW, latest apt-get upgrade kernel has power management disabled by default. |
|
it's still crashing after the latest upgrade, now i get this error in syslog: |
|
When you say it's crashing, are there symptoms other than the error message? |
|
no, just the one I have posted here but it is in the log many times the wlan stops working, i can still work with it but to get the wlan back working I have to reboot it |
|
Thanks - I think "wlan stops working" counts as a symptom. |
|
I've tried a few things, but wlan still breaks down to answer the question above when I take back the configuration I tried that with kernel 4.1.19 and now also with kernel 4.1.20 ... no change when the wlan crashed and i try to turn it back on with ifdown and ifup wlan0 I get this: I also got a few more error in syslog: dhcpcd[532]: wlan0: xxx: expired option 25 Mar 21 17:29:35 raspberrypi kernel: [ 6627.337503] brcmfmac: _brcmf_set_multicast_list: Setting mcast_list failed, -52 Mar 21 17:29:43 raspberrypi kernel: [ 6635.337616] brcmfmac: _brcmf_set_multicast_list: Setting mcast_list failed, -52 Mar 21 17:29:45 raspberrypi kernel: [ 6637.337588] brcmfmac: brcmf_do_escan: error (-52) Mar 21 17:29:47 raspberrypi kernel: [ 6639.337596] brcmfmac: _brcmf_set_multicast_list: Setting allmulti failed, -52 is there anything else I could try? |
|
also these: Mar 21 21:26:55 raspberrypi dhcpcd[526]: wlan0: xxx: expired option 25 |
|
I'm not surprised that iwconfig thinks the device has power-saving enabled - I blocked it within the driver itself, and either the state is saved in the higher layers or there is another change required in order to report it correctly. Either way, the evidence is strong that we have avoided the power-saving bugs, but some other problems still remain. Do you have any rough figures for the time-to-failure and roughly how much data might have been transferred (from ifconfig)? |
|
yes I do, when I have just the webserver running with not much traffic (less than 100 MB) it lasts a day or two, when i transfer large data files like 1 GB wlan crashes within 1 hour |
|
anything I can provide to help to find the bug? here are some error from syslog: Mar 29 14:20:56 raspberrypi dhcpcd[535]: wlan0: xxx: expired option 25 |
|
Thanks for the offer, but this is in the hands of Broadcom now. |
|
Any update from Broadcom if this is a bug which will be fixed? I now have a cron job setup to bring down and up wlan0 when it fails to ping. |
|
quick update from my side, i could get the problem fixed seems to be driver related, i installed Ubuntu MATE 16.04 with kernel 4.4.8 and haven't had any problems with wifi since i mean they advertise is: "Ubuntu MATE 16.04 also has fully working Bluetooth and Wifi on the Raspberry Pi 3" which seems true maybe it also works with a new Debian release, which i can not tell |
|
@juched78 Are you running a 4.4 kernel? If not, please run The Broadcom drivers have changed significantly since 4.1, and our 4.4 tree includes back-ports of some fixes that went into 4.5. I'm not aware of any outstanding bugs apart from the failure to wake from sleep (power management is still disabled) - channels 12 & 13 are usable where permitted, and Ad Hoc mode doesn't crash - but there may still be lurking issues. |
|
Oh, there is one reported bug still in 4.4.8 - apparently heavy use of hostapd can lead to a kernel warning (see #1375). |
|
I am running: Apr 27 2016 11:06:18 With my Netgear R7000 running Shibby Tomato, around 2 days in the wifi drops, and in the sys logs I see: Then it seems to never reconnect... Using sudo ifdown wlan0 followed by sudo ifup wlan0 brings back my connection. |
|
Just upgraded to: Not sure what is all different from the 22nd to the 30th. I will monitor the connection. |
|
My RPi 3 also hit that problem. I got few different kernel messages. Mainly one of those below. Raspberry is powered from original power adapter for version 3. I'm running latest OSMC: |
|
Still monitoring. I had openhab go offline after running 3 days but for some reason I could still ssh into the Pi which I usually couldn't. The top of the hour and the wifi script ran to bring down and bring up the connection and then it reconnected to my openhab org. Odd. Will keep watching. |
|
I am also experiencing the same issue - dmesg trace as follows: Usage: rp3 is being used as a router/access point Connectivity length seems random - I've had as high as two weeks, and as bad as a few minutes. Lately it's been going out every 20 minutes or so. Bringing wlan0 down and back up does not resolve the issue - a full reboot is required. Problem seems to be exacerbated while streaming Netflix from my AppleTV. Though this was not the case when I had the two weeks of uptime. I'm on 4.4.10-v7+ |
|
I switched the channel from 13 to 6 to check if that could be the problem (there were some defects about the high channels) and since then I haven't had a WiFi freez. But that could be a coincidence... |
|
Changing access point channels didn't help. WiFi still breaks. Last few times I had to restart few times in a row to get it working. |
|
Anyone experiencing firmware traps, timeouts (-110) etc. - please enable some firmware debugging so we can gather some data. Add Then just carry on as normal. When the brcmfmac firmware dies, capture the output of Since the failure triggers other kernel messages, there is a danger that the useful output is lost before you have chance to capture it. A way to avoid this is to leave a shell constantly saving the kernel messages to a file: |
|
Seeing the same issue here. Will try the debug mentioned above. Running hostapd in AP mode, wireguard, and frr. Also using Sixfab cellular hat. |
|
I am also able to recreate this on the 5.4 branch. FWIW, I can always manually trigger this bug by SCPing a large file (>400MB) to my Pi Zero W. If it helps, my kernel version is as of this commit - 3c860a6 Crash Log with Debugging: During the above crash I ran an ifdown and ifup which didn't restore wifi. Only solution is to either reboot the pi, or rmmod & modprobe brcmfmac. It's worth noting this happens with power management turned off, since I have this in my interfaces file: |
|
That isn't the most recent firmware for the 43438 - we're now on: Try updating your firmware-brcm80211 package, or downloading the firmware from: https://github.com/RPi-Distro/firmware-nonfree/ If you still see errors, enable brcmfmac firmware logging by adding |
|
@pelwell Sorry about that, but I updated and can still recreate the issue using the method I mentioned. Note I enabled debugging as requested, but this is all I got: |
|
I was able to get more of a log by doing an ifdown & ifup on wlan0, hopefully this helps somewhat: |
|
I'm seeing the same issue with my Raspberry PI Zero W. |
|
I decided to do more debugging myself using Note this was on From the gist, you can see that wifi started failing around 330.527497 when This makes me think there may be an issue with the SDIO bus, but I am personally not skilled enough to dig much deeper than this. Could this maybe be a clock issue? @pelwell Would love your thoughts on this one 😅 |
|
I thought it worth mentioning, although this is not a long-term solution, but for anyone who is looking for a workaround: If you have already upgraded your WiFi firmware, try: If you haven't upgraded your firmware, but would like to continue with the latest OS updates:
Note you will see above the firmware version that would otherwise be installed, then: And check that it was successful: Now it is safe to perform a full upgrade leaving the WiFi function intact: If at anytime it is necessary to un-set the hold on the package to do more testing, etc: I can confirm through quite extensive testing that 20190114-1+rpt4 package version seems very stable with hostapd and other functions. For now it seems to be working fine with the latest kernel. |
|
Per @jeremyn54, this seems to have helped me. I've been running this for a few days now and so far no drops. I ended upgrading the firmware as well as the kernel. Hopefully this helps others. I'll post back if I get any lockups/drops. I'm running it in AP mode. |
|
Based on what was shared by @jeremyn54 and @robgil, I extracted the firmware blobs from both of the mentioned raspbian packages: And on my kernel, |
|
There is a promising feature "reset SDIO bus on a firmware crash" in the upcoming Linux 5.9. |
Sadly I cherry picked this and tested it, as well as a handful of other upcoming patches for 5.9 with no success. The issue doesn't seem to be a firmware crash, but something actually wrong with the SDIO bus from my testing. Really wish this issue would get more eyes from RaspberryPi. |
|
As an update to the issue, it seems the cause of the crash, at least in my case, is due to my Pi Zero being connected to a network that has 802.11r fast roaming enabled. If I reconnect to a non 802.11r network, I do not have connectivity issues. I have tested with |
|
I can confirm that disabling fast roaming in my AP worked around the problem. I haven't seen connectivity drop ever since. |
|
@jaroslawprzybylowicz I am trying to get more information on what may be causing the issue. Care if I ask what type of AP you are using, and what type of radios it has? I am personally using a few Ubiquiti Unifi NanoHDs, which use the MediaTek MT7603 for the B/G/N radio. |
|
was using a avm fritz!box 7412 with original firmware. for hw details of the device see openwrt page for the device. As mentioned earlier I had the impression it happens mostly when an android device (v4/5/6 maybe also newer ones) accessed a octoprint website on the pi. It also happened randomly over time.
Some more details in my original comment. It however is maybe end device or network traffic dependent but guess not ap or radio dependent.
09.09.2020 00:04:45 Chris Blake <[email protected]>:
… @jaroslawprzybylowicz[https://github.com/jaroslawprzybylowicz] I am trying to get more information on what may be causing the issue. Care if I ask what type of AP you are using, and what type of radios it has?
I am personally using a few Ubiquiti Unifi NanoHDs, which use the MediaTek MT7603 for the B/G/N radio.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub[#1342 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAZQPLVVYADHKXZBEPUM2GDSE2S7ZANCNFSM4B52SC4Q]. [https://github.com/notifications/beacon/AAZQPLRFN5PNTBNB5AMG6Z3SE2S7ZA5CNFSM4B52SC42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFEJ4GTI.gif]
|
|
@riptidewave93 My setup is single UniFi AP-AC-Pro with Qualcomm Atheros QCA9563 onboard. It has both 2.4 and 5GHz radios enabled under the same SSID. |
|
For what it's worth, I'm using a TP-Link AC-1750 which has 2.4ghz and 5ghz on different ssids. And I also have only observed the issue when connecting from an android device |
|
So on my pi 3B the wifi doesn't die after a while, it doesn't even start up anymore. Here is the output with the debug flag enabled: https://gist.github.com/pentlander/d37fa273f955ac988f71342c47109d28 |
Temporary solutionIt looks like there are multiple reasons for wifi network disturbances with Pi Zero / Pi3. In my case (Pi Zero) the problem is not related to heavy load - on the contrary, the problem occurs after a period of no load (which seems to indicate a power management issue indeed). Thus, I looked for a temporary bypass by preventing 'no load'. By the way, 802.11r fast roaming is not active on my router / AP (Openwrt 19.07.7 on Fritzbox 4040). Also, for the record, I am using IPv4 as well as IPv6 (most often IPv6). The Raspberry Pi ZeroW runs Debian Buster, last update was 30 April 2021. |
|
any news? I get this randomly, multiple times a day on a raspberry pi zero with arch linux. Cant reproduce with android, neither is fast roaming activated or on heavy load. Got a wifi router with 2,4 and 5ghz (openwrt) |
|
I have been experiencing this issue while using ssh over USB Gadget interface. Is anyone else also experiencing this issue outside of wifi? |
This is to workaround for a possible issue in the wireless chip firmware where some packets with higher priorities seem to go missing. See raspberrypi/linux#1342 for details. Signed-off-by: Seth Forshee <[email protected]>
and others
I put the same sd card (running debian 8 jessie, kernel 4.1.19) from the raspberry pi 2 with usb wifi (EDIMAX EW-7811UN Wireless USB Adapter, 150 Mbit/s, IEEE802.11b/g/n) into the new raspberry pi 3 using integrated wlan. Since then the wlan freezes after while (several hours) of usage couldn't find out if it's due to havy wifi usage or not, because I haven't change the software I guess it has to do with the new hardware. When the wlan freezes the pi can't be reached any longer, neither ifdown + ifup nor restart networking service helps in this case, I have to reboot the system to get it back to work, syslog doesn't say much only this:
dhcpcd[522]: wlan0: fe80::8af7:c7ff:fece:5912: expired option 25,
I've tried to change these settings so far, but without improvement:
sudo nano /etc/network/interfaces
wireless-power off
sudo nano /etc/sysctl.conf
at the end of the file add the following line
vm.min_free_kbytes = 16384
sudo nano /boot/cmdline.txt
At the end of the line, add:
smsc95xx.turbo_mode=N
dwc_otg.dma_enable=1 dwc_otg.dma_burst_size=256
The text was updated successfully, but these errors were encountered: