[lsusb: ID 0bda:8187 Realtek Semiconductor Corp]
I'd like to use this wireless adaptor I have, but the driver doesn't
play nice with suspend. It hangs after switching to the console,
without printing anything. This happens even if I haven't used the
adaptor (i.e. ifconfig shows 0 bytes rx/tx). Interestingly the numlock
key on my USB keyboard still works.
I tried "no_console_suspend nmi_watchdog=1", but it didn't show any more
output. (I waited 3 minutes for the watchdog to trigger).
However, I can insert panic() calls, and see whether I hit the hang
first, or go into a panic with flashing keyboard LEDs. I used this to
confirm that the hang happens inside the rtl8187_disconnect() function.
There's a good chance I can track this down myself, using panic()
again. Before I start, does anyone have an idea what might be happening?
Ta
Alan
--- On Tue, 30/12/08, Larry Finger <[email protected]> wrote:
> From: Larry Finger <[email protected]>
> Subject: Re: [linux-pm] rtl8187 usb wifi adaptor causes suspend hang
> To: "Alan Jenkins" <[email protected]>
> Cc: "Alan Stern" <[email protected]>, "Bob Copeland" <[email protected]>, [email protected], [email protected], "USB list" <[email protected]>, "Hin-Tak Leung" <[email protected]>, "Herton Ronaldo Krzesinski" <[email protected]>
> Date: Tuesday, 30 December, 2008, 5:52 PM
> Alan Jenkins wrote:
> > That won't fix hibernation though. The disconnect
> method can still get
> > called in resume from hibernation, before the
> workqueue gets unfrozen.
> > To be honest, I'm far more interested in
> suspend-to-disk than
> > suspend-to-ram.
>
> Does this patch fix your problem? It works here, but I only
> did one
> test. The patch is for wireless-testing.
BTW, there is already a bug on kernel bugzilla on this - maybe useful to
attach the patch to get the three people to test:
http://bugzilla.kernel.org/show_bug.cgi?id=11887
In fact I'll do this when I get back in a couple of hours. (am going
out soon...). I'll give this a try myself.
>
> Larry
>
>
> Index:
> wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
> ===================================================================
> ---
> wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_dev.c
> +++
> wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
> @@ -1464,6 +1464,32 @@ static int __devinit
> rtl8187_probe(struc
> return err;
> }
>
> +#ifdef CONFIG_PM
> +
> +static int rtl8187_suspend(struct usb_interface *intf,
> pm_message_t
> state)
> +{
> + struct ieee80211_hw *dev = usb_get_intfdata(intf);
> + struct rtl8187_priv *priv;
> + int time;
> +
> + if (!dev)
> + return 0;
> +
> + priv = dev->priv;
> +
> + time =
> usb_wait_anchor_empty_timeout(&priv->anchored, 1000);
> + if (!time)
> + usb_kill_anchored_urbs(&priv->anchored);
> + return 0;
> +}
> +
> +static int rtl8187_resume(struct usb_interface *intf)
> +{
> + return 0;
> +}
> +
> +#endif /* CONFIG_PM */
> +
> static void __devexit rtl8187_disconnect(struct
> usb_interface *intf)
> {
> struct ieee80211_hw *dev = usb_get_intfdata(intf);
> @@ -1484,6 +1510,10 @@ static struct usb_driver
> rtl8187_driver
> .id_table = rtl8187_table,
> .probe = rtl8187_probe,
> .disconnect = __devexit_p(rtl8187_disconnect),
> +#ifdef CONFIG_PM
> + .suspend = rtl8187_suspend,
> + .resume = rtl8187_resume,
> +#endif /* CONFIG_PM */
> };
>
> static int __init rtl8187_init(void)
Alan Stern wrote:
> On Tue, 30 Dec 2008, Bob Copeland wrote:
>
>
>> On Tue, Dec 30, 2008 at 10:45 AM, Alan Stern <[email protected]> wrote:
>>
>>>> Is it possible to fix this without suspend support in mac80211? If not,
>>>> I vote we change rtl8187 (and zd_usb) to prevent suspend. I.e. set USB
>>>> suspend callbacks which return an error.
>>>>
>> Alan J:
>>
>> Are you using 'echo -n mem > /sys/power/state' directly to do suspend,
>> or hitting the power button? I'm guessing we shouldn't be calling
>> disconnect() when suspending.
>>
>>
>>> It certainly should be possible to fix this. For instance, why
>>> unregister anything during suspend? If ieee80211_unregister_hw()
>>> weren't called then this problem would go away, right?
>>>
>> Yes, we shouldn't need to.
>>
>> But it's not the suspend() callback that's getting called (the driver
>> doesn't have one) but disconnect, which unregisters itself from the
>> upper layers. I just read the stuff in Documentation/usb but admit I
>> don't fully get the rules. AIUI, without suspend/resume callbacks,
>> disconnect will sometimes get called on resume? But the original
>> email is a hang at suspend time?
>>
>
> This explains the problem. Yes, drivers that don't have a suspend or
> resume method will have their disconnect method called when a system
> suspend occurs.
>
> An easy way to prevent this is to add empty suspend and resume methods
> (and a resume_reset method too).
>
That won't fix hibernation though. The disconnect method can still get
called in resume from hibernation, before the workqueue gets unfrozen.
To be honest, I'm far more interested in suspend-to-disk than
suspend-to-ram.
> Alternatively, you can allow the disconnect to occur. If the workqueue
> weren't freezable then the problem would be solved. Which leads to the
> question: Why have a freezable workqueue if there's no suspend/resume
> support in the driver?
>
Am Dienstag, 30. Dezember 2008 18:52:44 schrieb Larry Finger:
> Alan Jenkins wrote:
> > That won't fix hibernation though. =A0The disconnect method can sti=
ll get
> > called in resume from hibernation, before the workqueue gets unfroz=
en.=20
> > To be honest, I'm far more interested in suspend-to-disk than
> > suspend-to-ram.
>=20
> Does this patch fix your problem? It works here, but I only did one
> test. The patch is for wireless-testing.
Did you test STD or STR?
Regards
Oliver
Bob Copeland wrote:
> On Wed, Dec 31, 2008 at 02:33:47PM +0000, Alan Jenkins wrote:
>
>> Thanks for the patch. I tested STD too, and it doesn't seem to hang
>> anymore. I even tested removing the adaptor while the system was
>> hibernated. However, after resume the interface is useless.
>>
>
> Kind of sounds like the hardware is not responding... so this probably
> won't help, but you can always give my patches a spin:
>
> http://bobcopeland.com/kernel/wl/20081214/
>
> Should apply with fuzz. Just ignore patch 3, also you don't need
> anything special for rtl8187 since the classdev will suspend/resume
> on its own and rtl8187 already didn't do anything special for PM.
>
You were right, they didn't help :-). Thanks anyway.
On Wed, Dec 31, 2008 at 02:33:47PM +0000, Alan Jenkins wrote:
> Thanks for the patch. I tested STD too, and it doesn't seem to hang
> anymore. I even tested removing the adaptor while the system was
> hibernated. However, after resume the interface is useless.
Kind of sounds like the hardware is not responding... so this probably
won't help, but you can always give my patches a spin:
http://bobcopeland.com/kernel/wl/20081214/
Should apply with fuzz. Just ignore patch 3, also you don't need
anything special for rtl8187 since the classdev will suspend/resume
on its own and rtl8187 already didn't do anything special for PM.
> Regards
> "Alan J"
Heh!
--
Bob Copeland %% http://www.bobcopeland.com
On Tue, 30 Dec 2008, Alan Jenkins wrote:
> Ok, I think I got it.
>
> The hang is in ieee80211_unregister_hw(), on this line:
>
> destroy_workqueue(local->hw.workqueue);
>
>
> local->hw.workqueue is created using create_freezeable_workqueue(). So
> presumably destroy_workqueue() deadlocks because the workqueue has
> already been frozen.
>
> Is it possible to fix this without suspend support in mac80211? If not,
> I vote we change rtl8187 (and zd_usb) to prevent suspend. I.e. set USB
> suspend callbacks which return an error.
It certainly should be possible to fix this. For instance, why
unregister anything during suspend? If ieee80211_unregister_hw()
weren't called then this problem would go away, right?
Alan Stern
--- On Tue, 30/12/08, Larry Finger <[email protected]> wrote:
> Alan Jenkins wrote:
> > That won't fix hibernation though. The disconnect
> method can still get
> > called in resume from hibernation, before the
> workqueue gets unfrozen.
> > To be honest, I'm far more interested in
> suspend-to-disk than
> > suspend-to-ram.
>
> Does this patch fix your problem? It works here, but I only
> did one
> test. The patch is for wireless-testing.
>
> Larry
My test is that STD works alright, but STR still does not work. I haven't tried STD for a long time - I mostly use STR with SUSPEND_MODULES -, so I have no idea if STD works before the patch or not. With the patch, I can suspend to RAM (removing my SUSPEND_MODULES workaround temporarily), but it would not "defrost - this is similiar to my failed attempt at fixing this - adding some skeleton _suspend()/_resume() routines can get the driver to STR, but it won't defrost. Without any _suspend()/_resume() routines, it won't even suspend, but just spend ages trying to suspend.
I'll post your patch to http://bugzilla.kernel.org/show_bug.cgi?id=11887 as a work-in-progress...
Hin-Tak
Oliver Neukum wrote:
> Did you test STD or STR?
STD. My machine gets a dbus error whenever I try STR even with no
wireless drivers loaded.
Larry
On Tue, 30 Dec 2008, Bob Copeland wrote:
> On Tue, Dec 30, 2008 at 10:45 AM, Alan Stern <[email protected]> wrote:
> >> Is it possible to fix this without suspend support in mac80211? If not,
> >> I vote we change rtl8187 (and zd_usb) to prevent suspend. I.e. set USB
> >> suspend callbacks which return an error.
>
> Alan J:
>
> Are you using 'echo -n mem > /sys/power/state' directly to do suspend,
> or hitting the power button? I'm guessing we shouldn't be calling
> disconnect() when suspending.
>
> > It certainly should be possible to fix this. For instance, why
> > unregister anything during suspend? If ieee80211_unregister_hw()
> > weren't called then this problem would go away, right?
>
> Yes, we shouldn't need to.
>
> But it's not the suspend() callback that's getting called (the driver
> doesn't have one) but disconnect, which unregisters itself from the
> upper layers. I just read the stuff in Documentation/usb but admit I
> don't fully get the rules. AIUI, without suspend/resume callbacks,
> disconnect will sometimes get called on resume? But the original
> email is a hang at suspend time?
This explains the problem. Yes, drivers that don't have a suspend or
resume method will have their disconnect method called when a system
suspend occurs.
An easy way to prevent this is to add empty suspend and resume methods
(and a resume_reset method too).
Alternatively, you can allow the disconnect to occur. If the workqueue
weren't freezable then the problem would be solved. Which leads to the
question: Why have a freezable workqueue if there's no suspend/resume
support in the driver?
Alan Stern
Alan Jenkins wrote:
> [lsusb: ID 0bda:8187 Realtek Semiconductor Corp]
>
>
> I'd like to use this wireless adaptor I have, but the driver doesn't
> play nice with suspend. It hangs after switching to the console,
> without printing anything. This happens even if I haven't used the
> adaptor (i.e. ifconfig shows 0 bytes rx/tx). Interestingly the numlock
> key on my USB keyboard still works.
>
> I tried "no_console_suspend nmi_watchdog=1", but it didn't show any more
> output. (I waited 3 minutes for the watchdog to trigger).
>
> However, I can insert panic() calls, and see whether I hit the hang
> first, or go into a panic with flashing keyboard LEDs. I used this to
> confirm that the hang happens inside the rtl8187_disconnect() function.
>
> There's a good chance I can track this down myself, using panic()
> again. Before I start, does anyone have an idea what might be happening?
>
Ok, I think I got it.
The hang is in ieee80211_unregister_hw(), on this line:
destroy_workqueue(local->hw.workqueue);
local->hw.workqueue is created using create_freezeable_workqueue(). So
presumably destroy_workqueue() deadlocks because the workqueue has
already been frozen.
Is it possible to fix this without suspend support in mac80211? If not,
I vote we change rtl8187 (and zd_usb) to prevent suspend. I.e. set USB
suspend callbacks which return an error.
Thanks
Alan
On Tue, Dec 30, 2008 at 10:45 AM, Alan Stern <[email protected]> wrote:
>> Is it possible to fix this without suspend support in mac80211? If not,
>> I vote we change rtl8187 (and zd_usb) to prevent suspend. I.e. set USB
>> suspend callbacks which return an error.
Alan J:
Are you using 'echo -n mem > /sys/power/state' directly to do suspend,
or hitting the power button? I'm guessing we shouldn't be calling
disconnect() when suspending.
> It certainly should be possible to fix this. For instance, why
> unregister anything during suspend? If ieee80211_unregister_hw()
> weren't called then this problem would go away, right?
Yes, we shouldn't need to.
But it's not the suspend() callback that's getting called (the driver
doesn't have one) but disconnect, which unregisters itself from the
upper layers. I just read the stuff in Documentation/usb but admit I
don't fully get the rules. AIUI, without suspend/resume callbacks,
disconnect will sometimes get called on resume? But the original
email is a hang at suspend time?
The drivers themselves actually shouldn't be doing much in suspend
callbacks once mac80211 suspend support is done -- just powering down
the device -- since mac80211 will handle all the softmac state.
--
Bob Copeland %% http://www.bobcopeland.com
Alan Jenkins wrote:
> That won't fix hibernation though. The disconnect method can still get
> called in resume from hibernation, before the workqueue gets unfrozen.
> To be honest, I'm far more interested in suspend-to-disk than
> suspend-to-ram.
Does this patch fix your problem? It works here, but I only did one
test. The patch is for wireless-testing.
Larry
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -1464,6 +1464,32 @@ static int __devinit rtl8187_probe(struc
return err;
}
+#ifdef CONFIG_PM
+
+static int rtl8187_suspend(struct usb_interface *intf, pm_message_t
state)
+{
+ struct ieee80211_hw *dev = usb_get_intfdata(intf);
+ struct rtl8187_priv *priv;
+ int time;
+
+ if (!dev)
+ return 0;
+
+ priv = dev->priv;
+
+ time = usb_wait_anchor_empty_timeout(&priv->anchored, 1000);
+ if (!time)
+ usb_kill_anchored_urbs(&priv->anchored);
+ return 0;
+}
+
+static int rtl8187_resume(struct usb_interface *intf)
+{
+ return 0;
+}
+
+#endif /* CONFIG_PM */
+
static void __devexit rtl8187_disconnect(struct usb_interface *intf)
{
struct ieee80211_hw *dev = usb_get_intfdata(intf);
@@ -1484,6 +1510,10 @@ static struct usb_driver rtl8187_driver
.id_table = rtl8187_table,
.probe = rtl8187_probe,
.disconnect = __devexit_p(rtl8187_disconnect),
+#ifdef CONFIG_PM
+ .suspend = rtl8187_suspend,
+ .resume = rtl8187_resume,
+#endif /* CONFIG_PM */
};
static int __init rtl8187_init(void)
Hin-Tak Leung wrote:
> --- On Tue, 30/12/08, Larry Finger <[email protected]> wrote:
>
>> Alan Jenkins wrote:
>>
>>> That won't fix hibernation though. The disconnect
>>>
>> method can still get
>>
>>> called in resume from hibernation, before the
>>>
>> workqueue gets unfrozen.
>>
>>> To be honest, I'm far more interested in
>>>
>> suspend-to-disk than
>>
>>> suspend-to-ram.
>>>
>> Does this patch fix your problem? It works here, but I only
>> did one
>> test. The patch is for wireless-testing.
>>
>> Larry
>>
>
> My test is that STD works alright, but STR still does not work. I haven't tried STD for a long time - I mostly use STR with SUSPEND_MODULES -, so I have no idea if STD works before the patch or not. With the patch, I can suspend to RAM (removing my SUSPEND_MODULES workaround temporarily), but it would not "defrost - this is similiar to my failed attempt at fixing this - adding some skeleton _suspend()/_resume() routines can get the driver to STR, but it won't defrost. Without any _suspend()/_resume() routines, it won't even suspend, but just spend ages trying to suspend.
>
> I'll post your patch to http://bugzilla.kernel.org/show_bug.cgi?id=11887 as a work-in-progress...
>
> Hin-Tak
Thanks for the patch. I tested STD too, and it doesn't seem to hang
anymore. I even tested removing the adaptor while the system was
hibernated. However, after resume the interface is useless.
I get a kernel error message, which repeats regularly (something like
every 5 or 10 seconds):
phy0: Reset timeout!
and it doesn't work:
# iwlist wlan0 scan
wlan0 Interface doesn't support scanning : Network is down
# ifconfig wlan0 up
SIOCSIFFLAGS: Connection timed out
I have to re-plug the adaptor, and then it works again.
Regards
"Alan J"
Am Mittwoch, 31. Dezember 2008 15:33:47 schrieb Alan Jenkins:
> Thanks for the patch. =C2=A0I tested STD too, and it doesn't seem to =
hang
> anymore. =C2=A0I even tested removing the adaptor while the system wa=
s
> hibernated. =C2=A0However, after resume the interface is useless.
=46or STD you need to implement reset_resume()
Regards
Oliver
Bob Copeland wrote:
> On Tue, Dec 30, 2008 at 10:45 AM, Alan Stern <[email protected]> wrote:
>
>>> Is it possible to fix this without suspend support in mac80211? If not,
>>> I vote we change rtl8187 (and zd_usb) to prevent suspend. I.e. set USB
>>> suspend callbacks which return an error.
>>>
>
> Alan J:
>
> Are you using 'echo -n mem > /sys/power/state' directly to do suspend,
> or hitting the power button?
Various. Normally I use my GUI, which is using s2disk. I did try using
/sys/power/state directly as well, but there was no difference.
Alan Jenkins wrote:
> Hin-Tak Leung wrote:
>> --- On Tue, 30/12/08, Larry Finger <[email protected]> wrote:
>>
>>> Alan Jenkins wrote:
>>>
>>>> That won't fix hibernation though. The disconnect
>>>>
>>> method can still get
>>>
>>>> called in resume from hibernation, before the
>>>>
>>> workqueue gets unfrozen.
>>>
>>>> To be honest, I'm far more interested in
>>>>
>>> suspend-to-disk than
>>>
>>>> suspend-to-ram.
>>>>
>>> Does this patch fix your problem? It works here, but I only
>>> did one
>>> test. The patch is for wireless-testing.
>>>
>>> Larry
>>>
>> My test is that STD works alright, but STR still does not work. I haven't tried STD for a long time - I mostly use STR with SUSPEND_MODULES -, so I have no idea if STD works before the patch or not. With the patch, I can suspend to RAM (removing my SUSPEND_MODULES workaround temporarily), but it would not "defrost - this is similiar to my failed attempt at fixing this - adding some skeleton _suspend()/_resume() routines can get the driver to STR, but it won't defrost. Without any _suspend()/_resume() routines, it won't even suspend, but just spend ages trying to suspend.
>>
>> I'll post your patch to http://bugzilla.kernel.org/show_bug.cgi?id=11887 as a work-in-progress...
>>
>> Hin-Tak
>
> Thanks for the patch. I tested STD too, and it doesn't seem to hang
> anymore. I even tested removing the adaptor while the system was
> hibernated. However, after resume the interface is useless.
>
> I get a kernel error message, which repeats regularly (something like
> every 5 or 10 seconds):
>
> phy0: Reset timeout!
>
> and it doesn't work:
>
> # iwlist wlan0 scan
> wlan0 Interface doesn't support scanning : Network is down
>
> # ifconfig wlan0 up
> SIOCSIFFLAGS: Connection timed out
>
> I have to re-plug the adaptor, and then it works again.
Thanks for testing. I have some ideas on how to improve the
suspend/resume, but they will require some changes in the structure. I
will also try to determine why my system fails at STR so I can test
both flavors.
Larry
On Wed, 31 Dec 2008, Larry Finger wrote:
> Here is a second try at a suspend/resume patch for rtl8187. This one
> also seems a bit too easy; however, it did work for me, at least for
> STD. I now realize that my machine didn't power off in my previous
> test. This time I manually turned it off before restarting. My
> computer still doesn't STR, thus that was not tested.
As Oliver pointed out, you generally need to implement a reset_resume
method for hibernation to work. See
Documentation/usb/power-management.txt.
Alan Stern
Hin-Tak Leung wrote:
>
> Yes, that's the (older) non-B device. B devices says RTL8187Bv{B,D,E} . with a B before the 7; I have a rev E .The B device and the non-B device while similiar enough to share some driver code, are different enough that
> they might suspend/resume differently - they do probe/init slightly differently. Besides, I think all the people who recently worked on that code are B-device owners, with maybe Larry who probably owns both types (or a few).
I only have one. It is the strange device that reports an 8187 USB ID,
but is really an 8187B.
Larry
On Thu, Jan 1, 2009 at 2:07 PM, Alan Jenkins
<[email protected]> wrote:
> Hin-Tak Leung wrote:
>> --- On Wed, 31/12/08, Alan Jenkins <[email protected]> wrote:
>>
>>
>>> Thanks for the patch. I tested STD too, and it doesn't
>>> seem to hang
>>> anymore. I even tested removing the adaptor while the
>>> system was
>>> hibernated. However, after resume the interface is
>>> useless.
>>>
>>
>> Wierd - do you have NetworkManager running?
>>
>
> Yes, but it's not managing the wireless interface - I'm still using the
> wired network. When I tested, I didn't use the wireless interface at
> all before I hibernated.
>
>> These days I leave NM running - besides the occasional /etc/rc.d/init.d/{wpa_supplicant/NetworkManager} stop/start to re-establish connectivity (seems to be some timing issue with dhcp taking too long and nm ifconfig up/down the device wrongly) - and *when STD/STR works*, NM usually just re-connect within a minute on resume/defrost.
>>
>> I don't have the choice of unhooking the device - integrated to laptop. BTW, is it a B device or a non-B device that didn't work?
>>
>
> I think it's a B device.
>
> phy0: hwaddr 00:1b:2f:76:02:bc, RTL8187vB (default) V1 + rtl8225z2
>
>
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
That is an RTL8187L, rev. B. It is not an RTL8187B.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Here is a second try at a suspend/resume patch for rtl8187. This one
also seems a bit too easy; however, it did work for me, at least for
STD. I now realize that my machine didn't power off in my previous
test. This time I manually turned it off before restarting. My
computer still doesn't STR, thus that was not tested.
Larry
=============
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -1464,6 +1464,28 @@ static int __devinit rtl8187_probe(struc
return err;
}
+#ifdef CONFIG_PM
+
+static int rtl8187_suspend(struct usb_interface *intf, pm_message_t
state)
+{
+ struct ieee80211_hw *dev = usb_get_intfdata(intf);
+
+ rtl8187_stop(dev);
+
+ return 0;
+}
+
+static int rtl8187_resume(struct usb_interface *intf)
+{
+ struct ieee80211_hw *dev = usb_get_intfdata(intf);
+
+ rtl8187_start(dev);
+
+ return 0;
+}
+
+#endif /* CONFIG_PM */
+
static void __devexit rtl8187_disconnect(struct usb_interface *intf)
{
struct ieee80211_hw *dev = usb_get_intfdata(intf);
@@ -1484,6 +1506,10 @@ static struct usb_driver rtl8187_driver
.id_table = rtl8187_table,
.probe = rtl8187_probe,
.disconnect = __devexit_p(rtl8187_disconnect),
+#ifdef CONFIG_PM
+ .suspend = rtl8187_suspend,
+ .resume = rtl8187_resume,
+#endif /* CONFIG_PM */
};
static int __init rtl8187_init(void)
Hin-Tak Leung wrote:
> --- On Wed, 31/12/08, Alan Jenkins <[email protected]> wrote:
>
>
>> Thanks for the patch. I tested STD too, and it doesn't
>> seem to hang
>> anymore. I even tested removing the adaptor while the
>> system was
>> hibernated. However, after resume the interface is
>> useless.
>>
>
> Wierd - do you have NetworkManager running?
>
Yes, but it's not managing the wireless interface - I'm still using the
wired network. When I tested, I didn't use the wireless interface at
all before I hibernated.
> These days I leave NM running - besides the occasional /etc/rc.d/init.d/{wpa_supplicant/NetworkManager} stop/start to re-establish connectivity (seems to be some timing issue with dhcp taking too long and nm ifconfig up/down the device wrongly) - and *when STD/STR works*, NM usually just re-connect within a minute on resume/defrost.
>
> I don't have the choice of unhooking the device - integrated to laptop. BTW, is it a B device or a non-B device that didn't work?
>
I think it's a B device.
phy0: hwaddr 00:1b:2f:76:02:bc, RTL8187vB (default) V1 + rtl8225z2
Alan
On Wed, Dec 31, 2008 at 05:00:05PM -0600, Larry Finger wrote:
> +#ifdef CONFIG_PM
> +
> +static int rtl8187_suspend(struct usb_interface *intf, pm_message_t
> state)
> +{
> + struct ieee80211_hw *dev = usb_get_intfdata(intf);
> +
> + rtl8187_stop(dev);
> +
> + return 0;
> +}
Won't this do the wrong thing if the interface is never brought up
before you do suspend? (And then you can add a flag etc. to handle
that case, but that's exactly what my mac80211 patches aim to do.)
--
Bob Copeland %% http://www.bobcopeland.com
On Thu, 1 Jan 2009, Hin-Tak Leung wrote:
> So it has... I found Documentation/usb/power-management.txt a bit brief...
> and I am planning to read
> http://ols.fedoraproject.org/OLS/Reprints-2008/brown-reprint.pdf
> which seems to be quite relevant...
It doesn't cover USB suspend/resume specifically. But maybe it will
help you.
> do you have any recommended readings? I have tried "use the source",
> but the majority of wireless device drivers don't have any
> suspend/resume hooks :-). The behavior of 2.6.26pre - somewhere in
> usbcore forces unloading of all usb device drivers on suspend - was
> useable.
There aren't any other good documents to read, as far as I know.
2.6.28 also forces unloading of all USB drivers that don't have
suspend/resume support -- that was the part of the problem which
started this thread.
Alan Stern
--- On Wed, 31/12/08, Larry Finger <[email protected]> wrote:
<snipped>
> Thanks for testing. I have some ideas on how to improve the
> suspend/resume, but they will require some changes in the
> structure. I
> will also try to determine why my system fails at STR so I
> can test
> both flavors.
I had a crash STR, after restoring my SUSPEND_MODULES workaround , so it is possible that the new addition actually stop the module getting unloaded. In any case, I suggest testing STR/STD while leaving a ping to the router running, just to be sure that the suspend/resume code does the right thing.
Also since Alan Stern is now CC'ed, can I ask the in-tree skeleton usb driver code updated to reflect the recent PM-related changes? There seems to be quite some changes between 2.6.26 and 2.6.27 .
Cheers,
Hin-Tak
--- On Thu, 1/1/09, Stefanik G=E1bor <[email protected]> wrote:
> On Thu, Jan 1, 2009 at 2:07 PM, Alan Jenkins
> <[email protected]> wrote:
> > I think it's a B device.
> >
> > phy0: hwaddr 00:1b:2f:76:02:bc, RTL8187vB (default) V1
> + rtl8225z2
> That is an RTL8187L, rev. B. It is not an RTL8187B.
Yes, that's the (older) non-B device. B devices says RTL8187Bv{B,D,E} .=
with a B before the 7; I have a rev E .The B device and the non-B devi=
ce while similiar enough to share some driver code, are different enoug=
h that
they might suspend/resume differently - they do probe/init slightly dif=
ferently. Besides, I think all the people who recently worked on that c=
ode are B-device owners, with maybe Larry who probably owns both types =
(or a few).
Hin-Tak
=20
On Thu, 1 Jan 2009, Hin-Tak Leung wrote:
> Also since Alan Stern is now CC'ed, can I ask the in-tree skeleton
> usb driver code updated to reflect the recent PM-related changes?
> There seems to be quite some changes between 2.6.26 and 2.6.27 .
It _has_ been updated. But the USB PM interfaces allow several
different modes of operation, and usb-skeleton can illustrate only one
of them.
Alan Stern
--- On Wed, 31/12/08, Alan Jenkins <[email protected]> wrote:
> Thanks for the patch. I tested STD too, and it doesn't
> seem to hang
> anymore. I even tested removing the adaptor while the
> system was
> hibernated. However, after resume the interface is
> useless.
Wierd - do you have NetworkManager running?
These days I leave NM running - besides the occasional /etc/rc.d/init.d/{wpa_supplicant/NetworkManager} stop/start to re-establish connectivity (seems to be some timing issue with dhcp taking too long and nm ifconfig up/down the device wrongly) - and *when STD/STR works*, NM usually just re-connect within a minute on resume/defrost.
I don't have the choice of unhooking the device - integrated to laptop. BTW, is it a B device or a non-B device that didn't work?
Hin-Tak
--- On Thu, 1/1/09, Alan Stern <[email protected]> wrote:
> On Thu, 1 Jan 2009, Hin-Tak Leung wrote:
>
> > Also since Alan Stern is now CC'ed, can I ask the
> in-tree skeleton
> > usb driver code updated to reflect the recent
> PM-related changes?
> > There seems to be quite some changes between 2.6.26
> and 2.6.27 .
>
> It _has_ been updated. But the USB PM interfaces allow
> several
> different modes of operation, and usb-skeleton can
> illustrate only one
> of them.
So it has... I found Documentation/usb/power-management.txt a bit brief...
and I am planning to read
http://ols.fedoraproject.org/OLS/Reprints-2008/brown-reprint.pdf
which seems to be quite relevant... do you have any recommended readings? I have tried "use the source", but the majority of wireless device drivers don't have any suspend/resume hooks :-). The behavior of 2.6.26pre - somewhere in usbcore forces unloading of all usb device drivers on suspend - was useable.
Hin-Tak