WARNING: CPU: 2 PID: 1922 at net/wireless/sme.c:752 __cfg80211_connect_result+0x3c0/0x410 [cfg80211] #3318
Comments
|
Please give us the usual information:
|
|
I have got a pile of these, seem to start with
|
|
Please provide more information about your Wifi configuration (AP, STA, Adhoc, ...). |
|
When the message happened, the device was running in STA mode, via something like this: |
|
I am also getting regular "0x3c0/0x410 [cfg80211]" erros after my pi4 has been running for a while - i.e. i am not doing anything when it stops working, it is in dead of night. messages.log shows multiple, usually causing the pi to dissapear - my APs think that the pi is continuing to attempts to connect (i can see the attempts in a event UI) Pi4 |
|
FYI all my AP equipment is ubiquiti unifi APs of various types fwiw I note that the Exception stack is identical for both of us with the 0x13 code in the 17th byte) |
|
I have tried different APs and i tried turning off unscheduled power delivery and the feature that encourages devices to connect on 5ghz, that didn't help. -edit- Turns out uspd was still on, trying again to disable it and disable all other new features. Is there a way to force the pi4 to only connect on 2.4ghz? |
|
Same result here. |
|
I have moved my pie onto a separate 2.4ghz SSID operating in 802.11b legacy mode. I only have two settings left to test:
I have a 100ft outdoor rate cable coming this week so i can attach in situ and trying doing the trace on the wifi. |
|
@doganmurat what AP WiFi equipment are you using? |
|
I am using a custom built Linux. I don’t think it is AP related. It is same as for different APs. Except that it functions normally. |
|
Interestingly, I've just seen this on 5.4-rc7 on a Pi 4, but so far only once. There were no other obvious symptoms, just an unexpected warning. |
|
Thanks for info, for me when this happens all traffic stops flowing to the pi - whats interesting is it is still associating, i can see it move between APs. I have a long outdoor rated Ethernet cable coming i will use to attach to the device and see if i can get a trace of the issue. |
|
@pelwell ok, ethernet cable attached and i set (unfortunately while plugging in the cable i knocked out the power so will need to wait 24 to 48 hours for the repro to happen) |
|
Ok, seems the last few failures have always had this as last entry in the messages (could my unit just be plain old faulty?) Also seem when my unit disappears from the network it applies to bot the WLAN and the LAN. I have put the same SD into a pi0 and installed that in the same location to see if that makes the issue go away or not. |
|
issue did not resolve with pi zero |
|
The last warning is unrelated and advises you to use the new hwmon interface for under voltage detection. |
|
@lategoodbye thanks Stefan, thats good to know. I think this means my unit is silently dying in some way. It cannot service any IPv4 traffic but it does maintain wifi connection (which is very strange) and its DHCP address. I guess i need to open a different issue for this.... ? i am stumped. For example i can look at the LEDs on the serial board and see them flashing - this is indicative that the process on the unit using the serial port (python code) is still running just fine. Also looking in other logs (syslog) instread of messages i can see there is bunch of activity and no errors. I really don't know where to go next on this. —edit— |
|
I just have one of these again, and this was more preceded by As you can see, I seem to have 3 minutes where wlan0 was struggling to get DHCP, and right after the oops, it seems to be successful! Strange. |
|
@HinTak what DHCP server are you using? |
|
@HinTak what DHCP server are you using?
It is a small commercial firewall box, running some form of embedded linux, I think.
|
|
Just noticed that I have a bunch of them again. Strangely enough, they appear every 1/2 hour or so in the last 24 hours, but not for about two weeks. The machine has been up since Dec 2. There is nothing between Dec 3 and Dec 15. |
|
btw, #3671 looks similar (I see both __cfg80211_connect_result warnings and error -52's) |
|
The same is happening to me. RPi4, connects to wifi but is not getting DHCP. I have another one and it works fine. I even swapped SD cards and still failing on this one. FTR: This RPi4 was working fine, I installed ubuntu 64 bits and then my problems started.. ubuntu wasn't able to use wifi, I thought it was something on ubuntu so I came back to raspbian 32 bits, and now I'm having these issues. Maybe ubuntu changed something on the firmware and/or eeprom? Update: I've updated to the latest |
|
Hi, just adding a bit more context to this thread in case it helps, I build a RPi4 image using Yocto. Using only the onboard WiFi interface it boots and get IP addresses without the kernel error But I also added to the image an external WiFi driver for a D-Link adapter (DWA-181). Device is recognized correctly without errors, my next step was using Then I proceed to request a IP address with and it finished without errors and the interface works after that. The only issue is that I can only enable one interface at a time, if I enable both at boot, only the first one that gets configured will work, the other not, no matter if is the onboard device or the external one. |
|
Hi xyklex The same thing happens when I tried with "TPLink USB dongle" which is based on Realtek 8192eu controller. Not sure why "bss" pointer keep pointing NULL, even after the driver runs through successful association. This is very nervous patch just simply to hide this error in net/wireless/sme.c . 755 ** However in my case, it was not related to overlapped initialization of two WiFi devices at the same time... |
|
I'm facing the same problem. Simple Access point on other end is actually another RPi with hostapd setup. Per earlier comments I just added |
|
Hmm I just remember something - back in the days I worked on a wifi device driver (a long time ago, though the kernel tree still lists me as one of the maintainers - nothing needs changing for some years) - this looks a lot like one of those issues with driver' s states getting corrupted. Some of the states are being updated due to user actions like the user issuing an explicit network scan. Some are due to external events like traffic arriving. And the Internet states of the driver needs to be protected by mutexes if more than one such things are in transit (multiple CPUs doing different things simultaneously to the driver states). Anyway, the person who wrote the driver code should look at it... |
|
I don't see anything more interesting in dmesg after adding wpa supplicant logs: |
|
In the middle of wpa supplicant logs, workaround kicks in, when ifdown/ifup wlan0 is triggered. |
|
I'm also getting this problem (or a similar one) on my pi zero W running as a PiHole. I'm going to try a more formal Power Supply rather than a phone charging block and see if it fixes it as per this reddit post. |
|
I am seeing this same issue. After further investigation I think that wpa_supplicant is causing the driver to crash sometimes and then caused it to associate with This may or may not be related to the number of SSIDs in my office environment, which is what I assume is related to Rasperry Pi 4B |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This seems to need looking at, from dmesg:
The text was updated successfully, but these errors were encountered: