Bug 11887

hmm, I normally go hibernate via gnome-power-manager. It gets network manager disassociate and ifconfig down the device; then the kernel unloads the whole of usb core, including the driver, without requiring a manual unload.  

(this is an off-shot of bug 11794)

If you manually get disable wireless networking (which just disassociate and ifconfig down), does it hibernate without manual unload?

I forgot to mention that besides having the latest rtl8187 code (well, being one of the people involved in adding rtl8187b support, you would expect that), I also keep my wpa_supplicant and NetworkManager quite up-to-date - not quite to the upcoming fedora 10 level, but certainly a bit ahead of fedora 9. Some of the latest changes in wpa_supplicant/NetworkManager are to do with suspend/hibernate, I think. 

Hmm, you report that suspend was successful for 2.6.22.x and failed for 2.6.27.2. Do you have anything in the middle?

I have just managed to reproduce this behavior with changing between 2.6.26.7-86.fc9 and 2.6.27.4-69.fc10 on my fedora system. (fedora have  bleeding-edge wireless stuff so my 2.6.26.x have the rtl8187 driver, despite it only entering mainline at 2.6.27.). I can suspend (not hibernate) with 2.6.26.7 without doing anything to the module but not with 2.7.27.4. 

possibly due to this?
----------
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Jun 23 16:00:40 2008 -0400

    USB: Force unbinding of drivers lacking reset_resume or other methods
    
    This patch (as1024) takes care of a FIXME issue: Drivers that don't
    have the necessary suspend, resume, reset_resume, pre_reset, or
    post_reset methods will be unbound and their interface reprobed when
    one of the unsupported events occurs.
    
    This is made slightly more difficult by the fact that bind operations
    won't work during a system sleep transition.  So instead the code has
    to defer the operation until the transition ends.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
----------

(In reply to comment #2)
> Hmm, you report that suspend was successful for 2.6.22.x and failed for
> 2.6.27.2. Do you have anything in the middle?
It is not quite correct. With the kernel 2.6.22.x the driver rtl8187 deos not seem to supprot the cards 8187B at all. That is why I use the driver from "http://www.datanorth.net/~cuervo/rtl8187b". (I need to patch this driver to add card-id 8198 to its list of supported cards and after that it seems to support everything except wpa-enterprise with my card.) But I also need to unload it and the modules ieee-*rtl it depends on before suspend.

Okay - I forgot that most people don't have the rtl8187b-part (which support 8189/8197/8198 ids) of the driver until 2.6.27... some of us who is involved in its development have been using it since 2.6.25-ish, when the vendor driver was getting more and more difficult to port forward. ("Mr Leung" mentioned on John Cuervo's page is me, so I am familiar with the vendor driver's inability to suspend).

Suspend/hibernate has been working for me for much of 2.6.25.x/2.6.26.x, and only breaks when I upgrade to 2.6.27.x; most people simply don't know that suspend/hibernate/resume used to work, because general availability was in 2.6.27.

This is really a regression as it used to work under 2.6.26.x (but can't change the regression flag).

I tried modifying the driver code and adding some skeleto suspend()/resume(), 
and get suspend to call rtl8187_stop(dev), and it suspends alright (currently it fails to suspend and just keep going with a blinking cursor), but fails to resume. I have a suspicion that the 2.6.26 code calls driver->stop before driver->disconnect, but in 2.6.27 it doesn't seem to do that any more. 

Spent ages looking at drivers/usb/core/drivers.c (which is responsible for suspend/resume for drivers not having their own code), and can't see why it is doing it, except maybe soft_unbind can be mis-initialized to non-zero?
But that's wierd.

this seems to be an rtl8187 driver bug,
cc John W. Linville.

One more issue with unloading the module. Sometimes, irregularly, the command 'modprobe -r rtl8187' (started at my computer by pm-utils before hibernation) work for a very long time and spends about 15% of CPU. I tried to kill the command but neither signal 9 nor 15 works. The command only finished after a lost my patience and made 'rcnetwork restart' (but I am not sure that this is a true reason of finishing modprobe).

BTW, as an interrim work-around measure, it is possible to define 
SUSPEND_MODULES="rtl8187" in a file placed in /etc/pm/config.d/
and have the power-management system to unload it for you. 

This work-around is not ideal - the driver should do it properly, or the kernel should do the "right" thing like it did in 2.6.26 - so we still need a fix/solution for this. 

Surely, I used this option. But I encountered the problem described above: 'modprobe -r rtl8187' probably entered an infinite loop. Then I removed 'rtl8187' from the SUSPEND_MODULES parameter (I left there 'ieee*') and added a file named '06rtl8187' into '/etc/pm/sleep.d':

#!/bin/bash

case "$1" in
	hibernate|suspend)
		modprobe -r rtl8187
		;;
	thaw|resume)
		modprobe rtl8187
		;;
	*)
		;;
esac

exit $?

Now it works.

SUSPEND_MODULES works adequately for me - I suspend quite often; but I am mostly tracking wireless-testing which is quite a bit further from 2.6.27. It is not ideal, I agree, though.

Created attachment 19551 [details]
work-in-progress suspend/resume patch

Larry Finger wrote this - it works for me for suspend-to-disk, suspend-to-ram still doesn't work. YMMV. 

Please report experience if anybody wants to try this patch. It is against latest wireless-testing/compat-wireless, but probably will patch cleanly against most recent rtl8187 code. (it just adds the suspend/resume hooks, so is quite independent of the rest of the rtl8187 code).

Created attachment 19860 [details]
make output

I tryed the patch (id=19551) for 2.6.28, but it produces an error. Here I attach the output.

(In reply to comment #13)
> I tryed the patch (id=19551) for 2.6.28, but it produces an error. Here I
> attach the output.

Argh, sorry, 2.6.28 is different from wireless-testing/compat-wireless then... 
Feel adverturous enough to apply it against compat-wireless and install it after patching?

http://linuxwireless.org/en/users/Download#Wheretodownload

compat-wireless should work on 2.6.28. (actually that's how I normally test new changes).

I tried by applying the patch to 'compat-wireless-2009-01-18'. I removed all rtl8187 unload hints from /etc/pm and hibernated the computer. It hibernated and resumed successfully. No trace of unloading the driver in /var/log/pm-suspend. The driver seems to work properly. I will make a final check this Friday at my office, where I really can connect to a (wep protected) wireless network.

The patched module works properly at my office after hibernation and resume with WPA/TKIP. I am using it just now while writing this comment.

Hin-Tak, are you going to submit this patch?

(In reply to comment #17)
> Hin-Tak, are you going to submit this patch?

Will do. Sorry for the delay.

I reviewed the exchange on linux-wireless and it seems that more work may be needed. So I'll post it as an RFC and see what comes of it and/or others objects to it. The patch is not wrong but likely incomplete, I believe.

Created attachment 22175 [details]
The workaround of the problem with detecting access points

Lastly, with the kernels 2.6.29.1 and 2.6.30 I experienced the problem that after hibernation/resume the card often does not find any access points till I reload (remove and load again) the kernel module rtl8187. I tried both the patched and unpatched versions of the module. It is not enough to unload it before hibernation and load after thaw, so I needed to reload it once again. As a workaround of the problem I use the file /etc/pm/sleep.d/06rtl8187 attached here. It contains an extra "modprobe -r" - "modprobe" pair while resuming.

(In reply to comment #20)
> Created an attachment (id=22175) [details]
> The workaround of the problem with detecting access points
> 
> Lastly, with the kernels 2.6.29.1 and 2.6.30 I experienced the problem that
> after hibernation/resume the card often does not find any access points till
> I
> reload (remove and load again) the kernel module rtl8187. I tried both the
> patched and unpatched versions of the module. It is not enough to unload it
> before hibernation and load after thaw, so I needed to reload it once again.
> As
> a workaround of the problem I use the file /etc/pm/sleep.d/06rtl8187 attached
> here. It contains an extra "modprobe -r" - "modprobe" pair while resuming.

what do you mean by 'does not find any access points' ?  dbus & wpa_supplicant but need time to notice the device reappearing and start scanning for AP again.

(In reply to comment #21)
> what do you mean by 'does not find any access points' ?  dbus &
> wpa_supplicant
> but need time to notice the device reappearing and start scanning for AP
> again.
I mean that the KNetworkManager does not show any available access point, and any attempt to connect to known to me access points as to 'hidden' fails untill I reload the module. It may last for hours (first time it happened I did not realized that something is wrong with the computer for a long time), while normally it demands 10 seconds at most (usually 3-5 seconds) to find the access points.

Hin-Tak posted his patch, and I don't recall any comments.  Is there any new information here?  I presume that this problem persists w/ 2.6.33?

*** Bug 13261 has been marked as a duplicate of this bug. ***

Lastly, I am using the kernel 2.6.31 (from openSUSE 11.2) and do not experience this problem.

Closing based on comment 25...