This bug was already present under 2.6.36. Before going to suspend or hibernate mode, my network card works fine. After I resume from either mode, the card doesn't go back online and is not available. Dmesg keeps showing the following: r8712u: in r8711_wx_set_scan: bDriverStopped=1 r8712u: in r8711_wx_set_scan: bDriverStopped=1 r8712u: in r8711_wx_set_scan: bDriverStopped=1 r8712u: in r8711_wx_set_scan: bDriverStopped=1 r8712u: in r8711_wx_set_scan: bDriverStopped=1 r8712u: in r8711_wx_set_scan: bDriverStopped=1 r8712u: in r8711_wx_set_scan: bDriverStopped=1 r8712u: in r8711_wx_set_scan: bDriverStopped=1 Then, I unplugged and replugged the USB device and... usb 5-4: USB disconnect, address 4 usb 5-4: new high speed USB device using ehci_hcd and address 6 usb 5-4: New USB device found, idVendor=0bda, idProduct=8172 usb 5-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 5-4: SerialNumber: 00e04c000001 r8712u: DriverVersion: v7_0.20100831 r8712u: register rtl8712_netdev_ops to netdev_ops r8712u: USB_SPEED_HIGH with 4 endpoints r8712u: Boot from EFUSE: Autoload OK r8712u: CustomerID = 0x0000 r8712u: MAC Address from efuse = 00:0d:09:a1:09:d9 r8712u: 1 RCR=0x153f00e r8712u: 2 RCR=0x553f00e ADDRCONF(NETDEV_UP): wlan0: link is not ready ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready r8712u: [r8712_got_addbareq_event_callback] mac = 94:0c:6d:f1:2e:b2, seq = 0, tid = 0 wlan0: no IPv6 routers present The wireless card is now available and ready to be used. I also have another USB wireless device plugged at the same time and it wakes correctly. So it seems only related to r8712u.
Still present in 2.6.38-rc4
After a little test and observation, here is what is going on JUST BEFORE suspend in kern.log Feb 11 23:13:00 Xander kernel: r8712: suspending... Feb 11 23:13:00 Xander kernel: r8712: unable to suspend That explains why it can't resume Feb 11 23:13:00 Xander kernel: r8712: resuming... Feb 11 23:13:00 Xander kernel: r8712: unable to resume Which ends up by Feb 11 23:15:21 Xander kernel: r8712u: in r8711_wx_set_scan: bDriverStopped=1 So the problem comes first from the suspend process not working properly. Then, we'll have to figure out once fixed if the resume process works well.
After investigation, netif_running(pnetdev) in both resume and suspend functions always returns 0, thus preventing the following actions.
Sorry I did not see this bugzilla. I'll look into it now.
Still seen on 2.6.39. I have to unplug the USB network card and replug it after every suspend/wake-up cycle to be able to use the card again.
I can confirm this problem on kernel v2.6.39 on Gentoo Linux. The USB device is: Bus 002 Device 005: ID 2019:ab28 PLANEX GW-USNano Messages when the system first boots: [ 9.861538] r8712u 2-1.2:1.0: usb_probe_interface [ 9.861550] r8712u 2-1.2:1.0: usb_probe_interface - got id [ 9.861552] r8712u: DriverVersion: v7_0.20100831 [ 9.863756] r8712u: register rtl8712_netdev_ops to netdev_ops [ 9.865948] r8712u: USB_SPEED_HIGH with 4 endpoints [ 9.868732] r8712u: Boot from EFUSE: Autoload OK [ 10.569622] r8712u: CustomerID = 0x0000 [ 10.571874] r8712u: MAC Address from efuse = 00:22:cf:3d:de:ab [ 10.574712] r8712u 2-1.2:1.0: wlan0: Features changed: 0x00004800 -> 0x00004000 [ 27.478307] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin" [ 28.236680] r8712u: 1 RCR=0x153f00e [ 28.237803] r8712u: 2 RCR=0x553f00e When the system is suspended: [ 104.054829] r8712: suspending... [ 104.054831] r8712: unable to suspend When the system is resumed: [ 110.388663] r8712: resuming... [ 110.388664] r8712: unable to resume [ 112.899412] r8712u: in r8711_wx_set_scan: bDriverStopped=1 [ 113.066571] r8712u: in r8711_wx_set_scan: bDriverStopped=1 [ 133.047014] r8712u: in r8711_wx_set_scan: bDriverStopped=1 [ 163.015484] r8712u: in r8711_wx_set_scan: bDriverStopped=1 [ 202.974004] r8712u: in r8711_wx_set_scan: bDriverStopped=1 Then after removing the USB device and plugging it back in it works again: [ 238.284788] r8712u 2-1.2:1.0: usb_probe_interface [ 238.284795] r8712u 2-1.2:1.0: usb_probe_interface - got id [ 238.284800] r8712u: DriverVersion: v7_0.20100831 [ 238.284832] r8712u: register rtl8712_netdev_ops to netdev_ops [ 238.284838] r8712u: USB_SPEED_HIGH with 4 endpoints [ 238.285516] r8712u: Boot from EFUSE: Autoload OK [ 239.151832] r8712u: CustomerID = 0x0000 [ 239.151841] r8712u: MAC Address from efuse = 00:22:cf:3d:de:ab [ 239.152049] r8712u 2-1.2:1.0: wlan0: Features changed: 0x00004800 -> 0x00004000 [ 239.271810] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin" [ 239.969686] r8712u: 1 RCR=0x153f00e [ 239.970804] r8712u: 2 RCR=0x553f00e
(In reply to comment #4) > Sorry I did not see this bugzilla. I'll look into it now. Hi Larry. Since 3.0 went out and the bug is still there, I was just wondering if it was a work in progress. Maybe I could play with it a bit if you could point me to some documentation. I understand that you may have other things on the back-burner.
My machine does not hibernate or sleep for other reasons, thus I could never test any patches. I have other things on the front burner. This problem is way back.
For info, using kernel 3.10 and I still have issue with the driver. Here is what reported from "dmesg ! grep r8712u": [ 351.757562] r8712u 1-1:1.0 wlan0: Suspending... [ 351.757563] r8712u 1-1:1.0 wlan0: Unable to suspend [ 352.648507] Modules linked in: fuse r8712u(C) joydev kvm_amd kvm pcspkr serio_raw i2c_piix4 edac_core r8169 hid_logitech_dj firewire_ohci firewire_core crc_itu_t xhci_hcd nouveau mxm_wmi wmi radeon ttm [ 352.949880] r8712u 1-1:1.0 wlan0: Resuming... [ 352.949881] r8712u 1-1:1.0 wlan0: Unable to resume [ 359.172341] r8712u 1-1:1.0 wlan0: In r8711_wx_set_scan: bDriverStopped=1 [ 359.172481] r8712u 1-1:1.0 wlan0: In r8711_wx_set_scan: bDriverStopped=1
Reproducible on 3.12.13. I have to force the module to unload with "modprobe -rf r8712u", because otherwise modprobe hangs. Since hibernate-script doesn't seem to support force-unloading modules appending the following to /etc/hibernate/common.conf does the trick until this bug is fixed: OnSuspend 90 modprobe -rf r8712u OnResume 90 modprobe r8712u
Reproducible on 3.13.0 (from Ubuntu 14.04). Dimitri's modprobe commands work for me until it is fixed.
3.14 on Debian 8.0, is there a better place to report this? Also, /etc/hibernate/*.conf doesn't seem to be available for Debian. I ended up adding to /etc/pm/sleep.d/ with a script to rmmod and modprobe r8712u, using whatever script was in there as a base. Thanks
(In reply to Joshua Salles from comment #12) > 3.14 on Debian 8.0, is there a better place to report this? > > Also, /etc/hibernate/*.conf doesn't seem to be available for Debian. I ended > up adding to /etc/pm/sleep.d/ with a script to rmmod and modprobe r8712u, > using whatever script was in there as a base. > > Thanks /etc/hibernate/ is part of the hibernate script, or just `hibernate` in debian: https://packages.debian.org/squeeze/hibernate
These two patches should fix the issue: https://lkml.org/lkml/2019/1/13/46 https://lkml.org/lkml/2019/1/13/47
bug persits with kernels 4.19&5.2.x
(In reply to siyia from comment #15) > bug persits with kernels 4.19&5.2.x Can you please attach full dmesg under 5.2.x?
Created attachment 285575 [details] Dmesg after a few suspend-wake cycles kernel 5.2
(In reply to siyia from comment #17) > Created attachment 285575 [details] > Dmesg after a few suspend-wake cycles kernel 5.2 The last message is: [86221.548973] IPv6: ADDRCONF(NETDEV_CHANGE): wlxf4ec388fafbd: link becomes ready So it seems to work fine. Does this happen under S4 only?
yes but only intermittenly ussually after long sleep/wake cycles, i have to run rmmod r8712u before sleep and then modprobe r8712u at post in a script in order for the wi-fi to be available,though most of the time it works even without that.
Then I guess the original issue (doesn't work every time after S3/S4) was solved, and what you are seeing is a new issue, maybe even a userspace one. Does it work after restarting userspace WiFi daemon like NetworkManager?
no i have to unload-load the module
Ok, can you please attach dmesg when module doesn't get reloaded?
No need seems to be fixed in with kernel 5.4+, the module was being loaded, but wi-fi card couldnt find any wireless network, there was also a userpace problem with network manager in debian 10 combined with kerne 4.19 lts was causing weird issues like that.
Although the module is a little slow to initialize after wake, sometimes takes up to a minute to get connected to my usual wi-fi network, it works fine.
The slow recovery is in Network Manager. It takes a while for it to recognize that the network is down before it brings it up.
Ok, as far as i am concerned this bug can be closed
ok issue still perists here is what dmesg shows in kernel 5.7 after suspend-wake. I am pretty sure it is not a userspace problem because i switched from NW to connman. [50109.617325] r8712u 1-2:1.0 wlan0: Suspending... [50110.852648] r8712u 1-2:1.0 wlan0: Resuming... [53914.962363] r8712u 1-2:1.0 wlan0: Suspending... [53915.216696] r8712u 1-2:1.0 wlan0: r8712u: pipe error: (-108) [53916.097525] r8712u 1-2:1.0 wlan0: Resuming...
I think disabling power-save directly in the module with: options r8712u fwlps=N fixes the suspend/resume issues, but i need to test it further.
Yeap this is it! Kernel: 5.7.7 Device: Bus 003 Device 002: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter r8712u module options: options r8712u fwlps=N This option fixes the connectivity issues after suspend/resume, so it is a power-saving issue within the module itself.