Created attachment 670870 [details] The important part of /var/log/message Description of problem: scary warnings, and also requires modprobe -r/modprobe to make it work again, on suspend/resume. top of the log (attached in full): [ 2865.167558] [<ffffffff8105c8df>] warn_slowpath_common+0x7f/0xc0 [ 2865.167564] [<ffffffff8105c9d6>] warn_slowpath_fmt+0x46/0x50 [ 2865.167575] [<ffffffff8150b719>] ? __netdev_alloc_skb+0x99/0xe0 [ 2865.167620] [<ffffffffa04f4dd9>] ieee80211_send_deauth_disassoc+0x229/0x230 [mac80211] [ 2865.167663] [<ffffffffa04f584a>] ieee80211_set_disassoc+0x2fa/0x4c0 [mac80211] [ 2865.167708] [<ffffffffa04f9b44>] ieee80211_mgd_deauth+0x174/0x180 [mac80211] [ 2865.167746] [<ffffffffa04cf158>] ieee80211_deauth+0x18/0x20 [mac80211] [ 2865.167779] [<ffffffffa04824ad>] cfg80211_mlme_down+0x7d/0xd0 [cfg80211] Version-Release number of selected component (if applicable): 3.6.11-3.fc18.x86_64 How reproducible: done three times, three out of three. Steps to Reproduce: 1. close laptop lid to sleep 2. 3. Actual results: ugly warning, also needs modprobe -r rtl8187/modprobe to get wifi connection again. Expected results: Additional info: The last time it slept okay was with 3.6.9-2.fc17.x86_64. I am one of the maintainers of the rtl8187 driver, so this is filed mainly to share the log, before I file at kernel.org if relevant.
I have since rebooted to 3.6.9-2.fc17.x86_64, 3.6.10-2.fc17.x86_64 as well as 3.6.9-4.fc18.x86_64, 3.6.10-5.fc18.x86_64 and 3.6.11-3.fc18.x86_64; and all have the same problem. 3.6.9-2.fc17.x86_64 was the last kernel which I ran for over two weeks and had suspended a few times according to my /var/log/messages*. So this looks like a fedora-18 specific problems brought on by changes in userland between F17 and F18. (possibly the systemd integrated udevd). modprobe -r/modprobe isn't always required - sometimes the wifi connectivity re-establish on its own. I suppose this will go to John Linville and possibly get the systemd or some of the userland power-management-related people involved.
Hopefully Kay has some input?
I found some other posts about the "Failed check-sdata-in-driver check, flags:..." part of message, which happens to other wifi drivers when suspend/resume: https://lkml.org/lkml/2012/7/1/164 https://bugzilla.kernel.org/show_bug.cgi?id=48041 Perhaps the question is why I have not seen it until upgraded. The 2nd seems to suggest it depends on NetworkManager/wpa_supplicant, and also mentioned that the fix might crash 3.6 so it does not seem to be a definitive answer. OTOH, since both of those other wifi driver issues happened in the last 6 months, it is possible that those other driver users also have some newer networkmanager/wpa_supplicant/udevd which is just getting into F18.
Just for the record, also see it in 3.7.1-2.fc18.x86_64 .
*** Bug 868175 has been marked as a duplicate of this bug. ***
Created attachment 698998 [details] ieee80211_disconnect_on_suspend.patch Proposed fix for this bug (wireless-testing version).
Created attachment 699006 [details] ieee80211_disconnect_on_suspend_v3.7.patch Backport of above patch to 3.7 (compile tested only).
Hin-Tak, could you please test attached 3.7 patch. I tested only upstream version.
On my test, patch fixes the warning from comment 0, but I'm able to trigger another one, so this is only partial fix. [ 4276.213593] WARNING: at net/mac80211/driver-ops.h:12 ieee80211_do_stop+0x5e7/0x610 [mac80211]() [ 4276.213595] wlan0: Failed check-sdata-in-driver check, flags: 0x4 [ 4276.213665] Call Trace: [ 4276.213674] [<ffffffff8105e2cf>] warn_slowpath_common+0x7f/0xc0 [ 4276.213678] [<ffffffff8105e3c6>] warn_slowpath_fmt+0x46/0x50 [ 4276.213698] [<ffffffffa06560e4>] ? ieee80211_free_keys+0x84/0x90 [mac80211] [ 4276.213707] [<ffffffffa0642817>] ieee80211_do_stop+0x5e7/0x610 [mac80211] [ 4276.213710] [<ffffffff816449f5>] ? _raw_spin_unlock_bh+0x15/0x20 [ 4276.213713] [<ffffffff81559ab1>] ? dev_deactivate_many+0x1f1/0x240 [ 4276.213722] [<ffffffffa064285a>] ieee80211_stop+0x1a/0x20 [mac80211] Work in progress to fix this another bug too ...
(In reply to comment #9) > On my test, patch fixes the warning from comment 0, but I'm able to trigger > another one, so this is only partial fix. > > [ 4276.213593] WARNING: at net/mac80211/driver-ops.h:12 > ieee80211_do_stop+0x5e7/0x610 [mac80211]() > [ 4276.213595] wlan0: Failed check-sdata-in-driver check, flags: 0x4 > [ 4276.213665] Call Trace: > [ 4276.213674] [<ffffffff8105e2cf>] warn_slowpath_common+0x7f/0xc0 > [ 4276.213678] [<ffffffff8105e3c6>] warn_slowpath_fmt+0x46/0x50 > [ 4276.213698] [<ffffffffa06560e4>] ? ieee80211_free_keys+0x84/0x90 > [mac80211] > [ 4276.213707] [<ffffffffa0642817>] ieee80211_do_stop+0x5e7/0x610 [mac80211] > [ 4276.213710] [<ffffffff816449f5>] ? _raw_spin_unlock_bh+0x15/0x20 > [ 4276.213713] [<ffffffff81559ab1>] ? dev_deactivate_many+0x1f1/0x240 > [ 4276.213722] [<ffffffffa064285a>] ieee80211_stop+0x1a/0x20 [mac80211] > > Work in progress to fix this another bug too ... I can confirm this latter prob also; my trace is almost identical on suspend. I tried using a short-cut procedure: git archive --prefix=bits-to-test/ v3.7.7:net/mac80211/ | tar -xpvf - cd bits-to-test/ patch -p3 < thepatch make -C /lib/modules/`uname -r`/build/ M=`pwd` then as root: cp mac80211.ko /usr/lib/modules/`uname -r`/updates modprobe -r rtl8187 # this unloads mac80211 also, or lsmod/modprobe -r to be sure depmod modprobe -v rtl8187 # -v to watch it load from updates As long as the modified kernel module(s) doesn't die nor differ to much (hence the initial v3.7.7:), one can unload/reload to test small changes. This allows a quick test without building whole kernels & rebootings, at least for testing small changes.
(In reply to comment #9) > On my test, patch fixes the warning from comment 0, but I'm able to trigger > another one, so this is only partial fix. > > [ 4276.213593] WARNING: at net/mac80211/driver-ops.h:12 > ieee80211_do_stop+0x5e7/0x610 [mac80211]() > [ 4276.213595] wlan0: Failed check-sdata-in-driver check, flags: 0x4 > [ 4276.213665] Call Trace: > [ 4276.213674] [<ffffffff8105e2cf>] warn_slowpath_common+0x7f/0xc0 > [ 4276.213678] [<ffffffff8105e3c6>] warn_slowpath_fmt+0x46/0x50 > [ 4276.213698] [<ffffffffa06560e4>] ? ieee80211_free_keys+0x84/0x90 > [mac80211] > [ 4276.213707] [<ffffffffa0642817>] ieee80211_do_stop+0x5e7/0x610 [mac80211] > [ 4276.213710] [<ffffffff816449f5>] ? _raw_spin_unlock_bh+0x15/0x20 > [ 4276.213713] [<ffffffff81559ab1>] ? dev_deactivate_many+0x1f1/0x240 > [ 4276.213722] [<ffffffffa064285a>] ieee80211_stop+0x1a/0x20 [mac80211] > > Work in progress to fix this another bug too ... was the patch included in newer kernels? I just suspended under 3.7.8-202.fc18.x86_64 (just the stock fedora kernel, no user mod), and got this trace: ("..." removed for clarity) ---------------------- [20511.849132] WARNING: at net/mac80211/driver-ops.h:12 ieee80211_do_stop+0x66d/0x6a0 [mac80211]() [20511.849134] Hardware name: Satellite Pro A210 [20511.849138] wlan2: Failed check-sdata-in-driver check, flags: 0x4 [20511.849242] Modules linked in: ... [20511.849248] i2c_core video [last unloaded: usb_storage] [20511.849255] Pid: 26178, comm: kworker/u:1 Not tainted 3.7.8-202.fc18.x86_64 #1 [20511.849258] Call Trace: [20511.849276] [<ffffffff8105e6df>] warn_slowpath_common+0x7f/0xc0 [20511.849284] [<ffffffff8105e7d6>] warn_slowpath_fmt+0x46/0x50 [20511.849330] [<ffffffffa0441824>] ? ieee80211_free_keys+0x84/0x90 [mac80211] [20511.849365] [<ffffffffa042ef8d>] ieee80211_do_stop+0x66d/0x6a0 [mac80211] [20511.849375] [<ffffffff81637235>] ? _raw_spin_unlock_bh+0x15/0x20 [20511.849384] [<ffffffff81546081>] ? dev_deactivate_many+0x1f1/0x240 [20511.849420] [<ffffffffa042efda>] ieee80211_stop+0x1a/0x20 [mac80211] [20511.849427] [<ffffffff8152336d>] __dev_close_many+0x7d/0xc0 [20511.849433] [<ffffffff81524bd8>] dev_close_many+0x88/0x100 [20511.849439] [<ffffffff81524d00>] rollback_registered_many+0xb0/0x210 [20511.849444] [<ffffffff81524fa9>] unregister_netdevice_many+0x19/0x60 [20511.849479] [<ffffffffa04304f9>] ieee80211_remove_interfaces+0xd9/0x150 [mac80211] [20511.849511] [<ffffffffa041e133>] ieee80211_unregister_hw+0x53/0x110 [mac80211] .... If the patch wasn't included, it probably means the patch is unrelated and the problem has two ways of manifesting itself.
FWIW, I seems to have suspended/resumed with 3.8.1-201.fc18.x86_64 , 3.7.9-205.fc18.x86_64 , 3.7.9-201.fc18.x86_64 without any unsighty messages. The last unsighty message I had was with 3.7.9-201.fc18.x86_64 on 25th Feb (grep'ing through /var/log/messages); but I have suspended/resumed with 3.7.9-201.fc18.x86_64 on Feb 27. FWIW it looks like I upgraded systemd on 26th. $ rpm -qi systemd Name : systemd Version : 197 Release : 1.fc18.2 Architecture: x86_64 Install Date: Tue 26 Feb 2013 20:10:34 GMT ... Build Date : Mon 28 Jan 2013 19:05:29 GMT So it is possible that the problem has simply gone away.
If user-space disconnect before suspend the problem will not trigger. So this depends on user-space behavior, anyway kernel should resist whatever user-space do ...
I will use bug 856863 for tracking for problem from comment 0 and bug 892599 for tracking warning at ieee80211_do_stop
*** This bug has been marked as a duplicate of bug 856863 ***