Raspberry Pi builtin WiFi keeps crashing

[srinathava]

Hi,

I am trying to use my Raspberry Pi 3 as a basic MJPEG server and whenever I connect to it from a mobile device, it makes the Raspberry Pi's Wifi driver crash. The Raspberry Pi itself is still functional, but now without any WiFi. Rebooting it seems to be the only way to "fix" the problem. Using a laptop and navigating to the exact same address however seems to be very stable (weeks on end without a crash). I am very confused about what difference it makes to the Pi where I connect from I don't know if somehow my mobile device's radio is overwhelming the Raspberry Pi's internal radio somehow (does this even make sense?)

After the crash, I get the following logs in dmesg related to the driver:

Code: Select all

 pi@piexp:~ $ dmesg | grep brcmfmac
[    5.823266] usbcore: registered new interface driver brcmfmac
[    6.041935] brcmfmac: Firmware version = wl0: Aug  7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[    8.739245] brcmfmac: power management disabled
[74107.154818] brcmfmac: power management disabled
[75892.252230] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[75934.892363] brcmfmac: brcmf_do_escan: error (-110)
[75934.892375] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[75994.892536] brcmfmac: brcmf_do_escan: error (-110)
[75994.892548] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[76054.892744] brcmfmac: brcmf_do_escan: error (-110)
<10 more similar lines snipped>

Code: Select all

pi@piexp:~ $ uname -a
Linux piexp 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l GNU/Linux

The reproduction steps are unfortunately a bit complicated since it involves using the software I have been working on and a half-built mobile app to go with it. I have seen other place on the web which mention this error message and I've tried a few of those, but nothing seems to work. I'd be happy to try to run some diagnostics etc. if it helps.

Regards,
Srinath

[alex.surdubob]

I also have the EXACT same problem. Please help me!

Thanks in advance,
Alex

[mnemonic]

The broadcom module (brcmfmac) is highly bugged in raspberry, i kicked it out.

I am using an USB wifi adapter with atheros chipset (ath9k_htc) right now, what solved all problems i was heaving with broadcom.

[srinathava]

I am doing the same. I used this one:

https://smile.amazon.com/gp/product/B00 ... UTF8&psc=1

and it seems to work well without any crashes. To help the next person who reads this, you can also disable the builtin WiFi by following the procedure here:

https://raspberrypi.stackexchange.com/q ... n0-on-pi-3

The broadcom module (brcmfmac) is highly bugged in raspberry, i kicked it out.

I am using an USB wifi adapter with atheros chipset (ath9k_htc) right now, what solved all problems i was heaving with broadcom.

[jamesh]

This particular mailbox issue is being investigated by Cypress (the new owners of what used to be Broadcom's wireless business). However, they are quite busy with some security issues (the recent news of the vulnerabilities in the Wifi security), but hopefully we will get some news on this soon.

To the OP, which mobile are you using, a Samsung?

[fkbreitl]

Same problem here. I set up ownCloud and can transfer files from my laptop without any problem.
But as soon as I transfer files with my Samsung Galaxy S7 wifi breaks and

Code: Select all

raspberrypi kernel: [ 962.273390] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

appears.

My router is a FRITZ!Box 7490.

We should also mention the github issue for this problem which has been reported in March 2016 and is work in progress:

https://github.com/raspberrypi/linux/issues/1342

[srinathava]

To the OP, which mobile are you using, a Samsung?

Thanks for the reply. I am using a Samsung Galaxy S5. Android version: 6.0.1. The kernel version on the phone is 3.4.0.

It is interesting, but this issue mostly seems to affect folks with Samsung devices, not iPhones etc.

Srinath

[jamesh]

To the OP, which mobile are you using, a Samsung?

Thanks for the reply. I am using a Samsung Galaxy S5. Android version: 6.0.1. The kernel version on the phone is 3.4.0.

It is interesting, but this issue mostly seems to affect folks with Samsung devices, not iPhones etc.

Srinath

Indeed. I will pass that on to Cypress.

[daouzo]

Can confirm that the problem only appears when using a Samsung-Phone.

My Raspberry runs MPD, when I access it via iPhone or from a Desktop-PC it works like a charm. Once I use a Samunsung (tried A3 2017, A5 2016) the WIFI on the RPI breaks down and can only be restored by rebooting.
That also happens when I want to establish a SSH connection via Smartphone, it works for a few minutes, then breaks down.

Fun fact:
when accessing MPD via ympd (a lightweight web frontend) there are no issues with Samsung phones. WIFI stays stable.

[superbob666]

Hi,

I am also seeing this, though it is odd, if I connect sftp from my S7 and stream data, the wifi crashes. Does anyone know any possible work around apart from using Lan.


Thanks

[fkbreitl]

From https://github.com/raspberrypi/linux/issues/1342 we can see that a few days ago a possible workaround has been committed to broadcom driver in several kernel versions. So hopefully this fix will make it into our systems soon. I havn't had a chance to check it yet.

Another solution is to use a USB wifi dongle. You can find examples working with Raspbian from the internet.

[jamesh]

That fix is for another issue. We are still waiting for Cypress to come up with a fix for the mailbox issue which is the last remaining big one. Unfortunately they are busy with the recent Krack vulnerability, although I do keep prompting them.

It is very telling it seem to be most visible when connecting Samsung phones.

[wildfire]

It is very telling it seem to be most visible when connecting Samsung phones.

Which suggests it could be more of a Samsung issue rather than Broadcom/Cypress;;;

Either way it is concerning for me as I often tether my PI3b with my Galaxy Ace (yeah I know) for internet access.

[fkbreitl]

@jamesh I didn't know that. By the way is this firmware issue affecting all Raspberry Pi 3 systems or just Raspbian?
Did it exist since the beginning or was it introduced later?

Its a very serious issue and it seems like one network component is making the whole Raspberry Pi 3 unstable and prevents its usage as a server. How come there is not more concern form Cypress and the Raspberry Pi foundation?

[jamesh]

@jamesh I didn't know that. By the way is this firmware issue affecting all Raspberry Pi 3 systems or just Raspbian?
Did it exist since the beginning or was it introduced later?

Its a very serious issue and it seems like one network component is making the tripwhole Raspberry Pi 3 unstable and prevents its usage as a server. How come there is not more concern form Cypress and the Raspberry Pi foundation?

Plenty of concern from the Foundation , we are waiting for Cyprus as it's a firmware issue. We cannot do anything about it.

Samsung phones usually have cypress chip in.....

[fkbreitl]

I see. Then it is surprising that it takes Cypress months to fix this, after 5 million Raspberry Pi 3 have been sold and are affected.

Or are there any distributions which might not be affected?

[jamesh]

I see. Then it is surprising that it takes Cypress months to fix this, after 5 million Raspberry Pi 3 have been sold and are affected.

Or are there any distributions which might not be affected?

5M is a drop in the ocean for Wifi and BT chips. I remember a sales guy at Broadcom saying he had sold 1B BT chips....

However, 5m is still not to be sniffed at, and I keep pressuring Cypress to get this sorted. They are busy, but it has been some months now. We've provided multiple debug logs etc, so they should have enough data. Just not enough staff with the requisite skills set I suspect.

[fkbreitl]

Maybe its not a big number of chips sold for them, but this is not about some network card which the can be replaced if it doesn't work, but about a crucial component of a famous system which can ruin it all and hence result in a major loss of their reputation.
I could also imagine that the next wifi chips for the Rasperry Pi 4 might not come form Cypress again.
Anyway, these are just some thoughts. I didn't want to start a long discussion.

[superbob666]

big or small, they are the vendor, so they should support their product. Wifi is a very critical component, and this is very bad support. Is there an Url that I can check up, for an update from Cypress?

[JosAH]

Is there any progression yet, w.r.t. those Cypress/Broadcom drivers? I depend on a (more or less) reliable wifi, i.e. one of my pi/3s runs a mqtt broker so I can control some devices in my house (I'm disabled, I can't walk); as it is now, the entire configuration is completely unusable.

What surprises me is that those same Broadcom drivers don't cause any problems on Jessie; it's just that Stretch distribution that is a show stopper. Isn't it possible to push those old drivers to the latest distribution?

kind regards,

Jos

[jamesh]

Is there any progression yet, w.r.t. those Cypress/Broadcom drivers? I depend on a (more or less) reliable wifi, i.e. one of my pi/3s runs a mqtt broker so I can control some devices in my house (I'm disabled, I can't walk); as it is now, the entire configuration is completely unusable.

What surprises me is that those same Broadcom drivers don't cause any problems on Jessie; it's just that Stretch distribution that is a show stopper. Isn't it possible to push those old drivers to the latest distribution?

kind regards,

Jos

I believe the issues is also on Jessie, perhaps not as frequent - the reports go back some time, perhaps even before Jessie! The drivers are pretty much the same between the distro's as is the firmware. Only bug fixes have gone in, so in fact going to back will mean more failures.

My pressuring Cypress has resulting in some feedback from them, so will be updating the issue with them today, how soon we get a fix is anyone's guess. It's a difficult bug to find, but at least they are now looking at it.

[jamesh]

If anyone can actually replicate this at will, we are looking for some more help.

You will need to use custom firmware, installed in a specific way, and when the issue happens, do a dmesg, and post the results here or on our github issue tracking this fault.

Github : https://github.com/raspberrypi/linux/issues/1342

Firmware install instructions : PM me and I will send you the custom firmware. This is not production code, so do not install unless you are specifically looking for this issue.

Copy the firmware to the firmware folder, /lib/brcm/... You may wish to backup the original first....

Reinstall the firmware

sudo rmmod brcmfmac
sudo insmod brcmfmac debug=0x100000

Make it go wrong! Save the output of dmesg similar to following

dmesg > dmesgdump.txt

Post output here.

Note: This setup does not survive a reboot. You'll need to do something like this for it to start in debug mode on startup.

sudo sh -c "echo options brcmfmac debug=0x100000 > /etc/modprobe.d/brcmfmac.conf"

[JosAH]

It is very easy to make it go wrong; have an mqtt broker running and subscribe to a topic, where another client periodically publishes the currrent time (that's how I do it). Between a couple of minutes and a few days, the wifi drivers crash ...

kind regards,

Jos

[jamesh]

It is very easy to make it go wrong; have an mqtt broker running and subscribe to a topic, where another client periodically publishes the currrent time (that's how I do it). Between a couple of minutes and a few days, the wifi drivers crash ...

kind regards,

Jos

Problem is a few days is too long, we really need a mechanism that shows the issue much faster and more reliably. Case in point, I have only ever seen the mailbox issue once or twice in the last year, whereas others see it all the time. Makes it fantastically difficult to track down. hence my request above.

That, and I have no idea what a mqtt broker is so would have no idea how to set it up.

[JosAH]

It is very easy to make it go wrong; have an mqtt broker running and subscribe to a topic, where another client periodically publishes the currrent time (that's how I do it). Between a couple of minutes and a few days, the wifi drivers crash ...

kind regards,

Jos

Problem is a few days is too long, we really need a mechanism that shows the issue much faster and more reliably. Case in point, I have only ever seen the mailbox issue once or twice in the last year, whereas others see it all the time. Makes it fantastically difficult to track down. hence my request above.

That, and I have no idea what a mqtt broker is so would have no idea how to set it up.

And I don''t know what the 'mailbox issue' is, so we're even I'm afraid I have to let this pass to a more knowledgeable person; still: I never had any problems at all with Jessie on a pi3 ... I guess I was just lucky ...

kind regards,

Jos