Bug 11887 - rtl8187 has to be unloaded before hibernation
rtl8187 has to be unloaded before hibernation
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: network-wireless
All Linux
: P1 normal
Assigned To: drivers_network-wireless@kernel-bugs.osdl.org
:
: 13261 (view as bug list)
Depends on:
Blocks: 7216 56331
  Show dependency treegraph
 
Reported: 2008-10-29 06:07 UTC by Michael Lashkevich
Modified: 2013-04-09 06:23 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.28-rc2-17
Tree: Mainline
Regression: Yes


Attachments
work-in-progress suspend/resume patch (1.29 KB, patch)
2008-12-30 17:08 UTC, Hin-Tak Leung
Details | Diff
make output (1.53 KB, text/plain)
2009-01-17 09:35 UTC, Michael Lashkevich
Details
The workaround of the problem with detecting access points (175 bytes, text/plain)
2009-07-02 06:42 UTC, Michael Lashkevich
Details

Description Michael Lashkevich 2008-10-29 06:07:49 UTC
Latest working kernel version:
Earliest failing kernel version: 2.6.28-rc2-17
(and 2.6.27.2 where I added the identifyer 0bda:8198 of my card to the source code manually)
Distribution:
Hardware Environment: Toshiba Satellite L300-11E (with the card 0bda:8198).
Software Environment: OpenSUSE 10.3
Problem Description: If I hibernate the computer with the rtl8187 module loaded, the hibernation prossess freeses the computer forever at some early stage (presumably at the stage for freesing tasks).

Steps to reproduce: 1. Ensure that the module is loaded (by 'lsmod').
2. echo disk > /sys/power/state (Or better, use pm-utilities since it logs the process better and can send some information to the console.)

3. After rebooting you may unload the module and ensure than hibernation proceeds with image creation.
Comment 1 Hin-Tak Leung 2008-10-29 09:24:44 UTC
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. 
Comment 2 Hin-Tak Leung 2008-10-31 16:26:36 UTC
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. 
Comment 3 Hin-Tak Leung 2008-10-31 17:55:04 UTC
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>
----------
Comment 4 Michael Lashkevich 2008-11-01 02:23:13 UTC
(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.
Comment 5 Hin-Tak Leung 2008-11-01 10:14:11 UTC
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.
Comment 6 Hin-Tak Leung 2008-11-06 20:27:49 UTC
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.
Comment 7 Zhang Rui 2008-11-20 21:51:35 UTC
this seems to be an rtl8187 driver bug,
cc John W. Linville.
Comment 8 Michael Lashkevich 2008-11-26 00:31:53 UTC
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).
Comment 9 Hin-Tak Leung 2008-12-09 16:16:17 UTC
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. 
Comment 10 Michael Lashkevich 2008-12-10 23:52:44 UTC
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.
Comment 11 Hin-Tak Leung 2008-12-11 04:20:40 UTC
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.
Comment 12 Hin-Tak Leung 2008-12-30 17:08:08 UTC
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).
Comment 13 Michael Lashkevich 2009-01-17 09:35:02 UTC
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.
Comment 14 Hin-Tak Leung 2009-01-17 18:35:19 UTC
(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).
Comment 15 Michael Lashkevich 2009-01-19 13:02:49 UTC
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.
Comment 16 Michael Lashkevich 2009-01-23 01:31:28 UTC
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.
Comment 17 John W. Linville 2009-06-17 17:43:26 UTC
Hin-Tak, are you going to submit this patch?
Comment 18 Hin-Tak Leung 2009-06-17 21:21:40 UTC
(In reply to comment #17)
> Hin-Tak, are you going to submit this patch?

Will do. Sorry for the delay.
Comment 19 Hin-Tak Leung 2009-06-18 02:30:57 UTC
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.
Comment 20 Michael Lashkevich 2009-07-02 06:42:06 UTC
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.
Comment 21 Hin-Tak Leung 2009-07-02 19:31:27 UTC
(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.
Comment 22 Michael Lashkevich 2009-07-02 20:29:06 UTC
(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.
Comment 23 John W. Linville 2010-03-05 18:35:00 UTC
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?
Comment 24 John W. Linville 2010-03-05 18:39:09 UTC
*** Bug 13261 has been marked as a duplicate of this bug. ***
Comment 25 Michael Lashkevich 2010-04-11 13:13:27 UTC
Lastly, I am using the kernel 2.6.31 (from openSUSE 11.2) and do not experience this problem.
Comment 26 John W. Linville 2010-04-12 13:24:14 UTC
Closing based on comment 25...

Note You need to log in before you can comment on or make changes to this bug.