Bug 153471

Summary: WARNING: CPU: 1 PID: 1167 at net/wireless/sme.c:981 cfg80211_connect+0x234/0x588 [cfg80211]()
Product: Drivers Reporter: Michael Vorburger (mike)
Component: network-wirelessAssignee: drivers_network-wireless (drivers_network-wireless)
Status: NEW ---    
Severity: normal CC: ingvarthorvald
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.4.18-v7+ Subsystem:
Regression: No Bisected commit-id:

Description Michael Vorburger 2016-08-20 17:27:41 UTC 
(This is the very first Kernel bug I'm filing; please guide me if this is not the right place, or more information is required etc.)

I'm seeing wlan0 going down and this in dmesg -T (on a Raspian on Raspberry Pi 3 where using hostapd for WiFi as AP instead of station), and guessing that the "[ cut here ]" message means that perhaps you'd like to know about this so something can be done to fix it?

[Sat Aug 20 18:15:08 2016] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[Sat Aug 20 18:15:08 2016] brcmfmac: brcmf_add_if: ignore IF event
[Sat Aug 20 18:15:09 2016] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[Sat Aug 20 18:15:10 2016] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[Sat Aug 20 18:15:10 2016] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[Sat Aug 20 18:15:10 2016] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[Sat Aug 20 18:15:11 2016] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[Sat Aug 20 18:15:12 2016] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[Sat Aug 20 18:15:18 2016] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[Sat Aug 20 18:15:18 2016] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[Sat Aug 20 18:15:19 2016] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[Sat Aug 20 18:15:19 2016] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[Sat Aug 20 18:15:20 2016] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[Sat Aug 20 18:15:22 2016] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[Sat Aug 20 18:15:22 2016] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[Sat Aug 20 18:15:22 2016] ------------[ cut here ]------------
[Sat Aug 20 18:15:22 2016] WARNING: CPU: 1 PID: 1167 at net/wireless/sme.c:981 cfg80211_connect+0x234/0x588 [cfg80211]()
[Sat Aug 20 18:15:22 2016] Modules linked in: bnep hci_uart btbcm bluetooth brcmfmac brcmutil cfg80211 rfkill evdev snd_bcm2835 snd_pcm snd_timer snd bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio ipv6
[Sat Aug 20 18:15:22 2016] CPU: 1 PID: 1167 Comm: iwconfig Not tainted 4.4.18-v7+ #905
[Sat Aug 20 18:15:22 2016] Hardware name: BCM2709
[Sat Aug 20 18:15:22 2016] [<80018784>] (unwind_backtrace) from [<80014058>] (show_stack+0x20/0x24)
[Sat Aug 20 18:15:22 2016] [<80014058>] (show_stack) from [<80320bc4>] (dump_stack+0xd4/0x118)
[Sat Aug 20 18:15:22 2016] [<80320bc4>] (dump_stack) from [<80025360>] (warn_slowpath_common+0x98/0xc8)
[Sat Aug 20 18:15:22 2016] [<80025360>] (warn_slowpath_common) from [<8002544c>] (warn_slowpath_null+0x2c/0x34)
[Sat Aug 20 18:15:22 2016] [<8002544c>] (warn_slowpath_null) from [<7f11cad4>] (cfg80211_connect+0x234/0x588 [cfg80211])
[Sat Aug 20 18:15:22 2016] [<7f11cad4>] (cfg80211_connect [cfg80211]) from [<7f135c5c>] (cfg80211_mgd_wext_connect+0x114/0x180 [cfg80211])
[Sat Aug 20 18:15:22 2016] [<7f135c5c>] (cfg80211_mgd_wext_connect [cfg80211]) from [<7f135d8c>] (cfg80211_mgd_wext_siwfreq+0xc4/0x194 [cfg80211])
[Sat Aug 20 18:15:22 2016] [<7f135d8c>] (cfg80211_mgd_wext_siwfreq [cfg80211]) from [<7f135adc>] (cfg80211_wext_siwfreq+0xc8/0x134 [cfg80211])
[Sat Aug 20 18:15:22 2016] [<7f135adc>] (cfg80211_wext_siwfreq [cfg80211]) from [<805ae300>] (ioctl_standard_call+0x6c/0x4b4)
[Sat Aug 20 18:15:22 2016] [<805ae300>] (ioctl_standard_call) from [<805aea40>] (wext_handle_ioctl+0x1b8/0x23c)
[Sat Aug 20 18:15:22 2016] [<805aea40>] (wext_handle_ioctl) from [<804ee504>] (dev_ioctl+0x53c/0x800)
[Sat Aug 20 18:15:22 2016] [<804ee504>] (dev_ioctl) from [<804b7638>] (sock_ioctl+0x12c/0x2b0)
[Sat Aug 20 18:15:22 2016] [<804b7638>] (sock_ioctl) from [<80169720>] (do_vfs_ioctl+0x424/0x614)
[Sat Aug 20 18:15:22 2016] [<80169720>] (do_vfs_ioctl) from [<80169954>] (SyS_ioctl+0x44/0x6c)
[Sat Aug 20 18:15:22 2016] [<80169954>] (SyS_ioctl) from [<8000fb40>] (ret_fast_syscall+0x0/0x1c)
[Sat Aug 20 18:15:22 2016] ---[ end trace dac61f84813e0313 ]---
[Sat Aug 20 18:15:22 2016] ------------[ cut here ]------------

Full dmesg from Kernel boot is shown on https://gist.github.com/vorburger/cf7bf01ca290bf73291131577b8dac3c.

PS: This somehow seems to be related, as strange as this may sound, to the HDMI cable being plugged into the RPi 3 ... another user has reported this on https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=143972&p=1021341, and I can confirm that I can reproduce above with the HDMI cable in and a 4k monitor connected, but am not seeing it with HDMI plugged out.  No idea what this could have to do with WiFi if anything, so just FYI.
Comment 1 Michael Vorburger 2016-08-20 22:58:06 UTC 
What's interesting is that this doesn't seem to happen when an Ethernet cable is plugged into the RPi 3 (and it's still on HDMI) - so seems to have something to do with... power and/or signal level?  The driver presumably still should never just crash like that and take the interface down?
Comment 2 [account disabled by the administrator] 2016-08-20 23:19:22 UTC 
That's a pretty old kernel. Can you try a newer mainline kernel if possible and see if it fixes your issue.
Comment 3 Michael Vorburger 2016-08-21 01:52:50 UTC 
ingvarthorvald tx; to upgrade from the 4.4.18 which FYI is the standard latest one distributed with raspbian as of now (as of 58567cb https://github.com/raspberrypi/firmware), I'll first have to  cross-compile my first an ARM Kernel for the RPi .. will do - another night! ;-)

Notes to self: I can see on https://github.com/raspberrypi/linux/branches that they currently have up to 4.8.y, and on https://www.raspberrypi.org/documentation/linux/kernel/building.md there are instructions that look feasible (on http://elinux.org/Raspberry_Pi_Kernel_Compilation it's more elaborate).

PS: Having tried more, I'm meanwhile increasingly convinced that this has more to do with what cables are plugged into the RPi, and perhaps less with using hostapd for WiFi as AP instead of station, as I just saw a similar issue in dmesg while using the interface as station instead of AP... FTR to anyone reading this: The RPi v3 has a tiny on-board WiFi antenna, and on my RPi that antenna is covered by some extension shield (full size, under a separate power source; it's http://www.pololu.com/product/2755 - for a motor).. I'll retry later on another "bare" board where that antenna isn't covered, to see if that makes any difference for this problem.
Comment 4 [account disabled by the administrator] 2016-08-22 20:15:16 UTC 
Covering signals for wifi is never a good idea, try on that over board without the cover. It probably won't help but always good to try and rule out hardware related issues first through :).
Comment 5 Michael Vorburger 2016-10-14 17:34:00 UTC 
Just for the record: This DID turn out to be somehow hardware related on the RPi v3 - that motor shield board linked to above somehow interfered with the onboard WiFi, and using an external USB WiFi dongle "solved" (worked around) this for me.

For me, feel free to close to this issue, although perhaps you'd like to harden the code anyway - leaving it open for a maintainer to decide what to do.