Red Hat Bugzilla – Bug 469461
[regression] rawhide kernel doesn't unload usb wireless driver on suspend?
Last modified: 2009-12-18 01:58:55 EST
Description of problem:
older kernel (22.214.171.124-86.fc9.x86_64) seems to automatically unload usb-wireless driver on suspend, but new one (126.96.36.199-69.fc10.x86_64) does not do this any more, and requires a manual modprobe -r - otherwise
suspend just get stuck forever.
With the older kernel, dmesg emits a warning
"rtl8187 1-6:1.0: no suspend for driver rtl8187?" and suspend/resume properly anyway.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot 188.8.131.52-69.fc10.x86_64
2. select suspend from nm-applet
3. <takes forever and never suspend>
blinking cursor, does not suspend and requires a power-off reset.
suspend properly and can resume afterwards.
but with a wider range, and non-fedora kernels.
BTW, I was one of the people involved in developing the new rtl8187b-related code in rtl8187, so if this goes upstream and/or to John Linsville, it would come back to me :-(.
Not sure if the driver should relie on automatic usbcore unload, but it did work in 2.6.26.x (and it makes life easier for the driver writers...).
possibly due to this?
Author: Alan Stern <firstname.lastname@example.org>
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 <email@example.com>
Signed-off-by: Greg Kroah-Hartman <firstname.lastname@example.org>
Indeed, this causes regressions in ANY AND ALL drivers that use a reset
and have disconnects that wait (such as ub, for instance). I already
complained to Alan Stern about it, his suggestion was to add stub
methods... I am not happy, but what can we do. Time to audit everything
including rtl8187, I guess.
If the usb core can deal with suspend/resume issues, obviously it makes sense for drivers *not* to have suspend/resume-related code, and everything is simplier. OTOH, if stub methods are needed, I'll be happy to do that - but I don't seem to be able to find either documentation or example code on what needed to be done in the stubs.
In the upstream report, I mentioned that I added a suspend() method which disconnects; it allows the machine to suspend; but it crashes on resume, so it looks like I don't entirely understand what needed to be done. (I realise it might fall onto my own shoulder to provde a patch, and tested it myself, but I could do with a little hint/help...).
The thing is, since manually rmmod/modprobe works, it should just work if I just stuff the bulk of "what happens on rmmod" into suspend(), and "what happens on modprobe" into resume(). I guess my question is, I am not too sure about the precise roles, overlaps and differences between probe() vs resume(), and disconnect() vs suspend(). (granted the pairs overlap substantially).
okay, I checked git and saw that ub added pre_reset()/post_reset() stubs 10 days ago... that's unexpected voodoo - I thought I need to do suspend()/resume() properly?) - I'll try to see if pre/post_reset() stubs works for rtl8187 as well, but can somebody explain how this voodoo work?
tried subbing pre_reset()/post_reset() - it doesn't do anything useful...
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
There was a fix for this upstream, no? What was it?
The patch concerned committed upstream recently is this - it fixes suspend-to-disk, but has no effect to suspend-to-ram... suspend-to-ram still need work.
Author: Johannes Berg <email@example.com>
Date: Mon Jan 5 23:11:26 2009 -0600
rtl8187: Fix module so that rmmod/insmod does not error
Due to misunderstanding of the returned values allowed for the tx callback
of mac80211, rtl8187 was using skb's that had been freed. This problem was
triggered when the module was sujected to a rmmod/insmod cycle.
After that was fixed, the modules would not work after the rmmod/insmod cycle
until the USB device was reset.
Signed-off-by: Johannes Berg <firstname.lastname@example.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <email@example.com>
Hin-Tak, Zaitcev -- is there any progress/change here? What needs to happen to resolve this upstream and in Fedora?
I dunno, John. If I had a Realtek WiFi dongle to play with...
The commit 6aab2c928* is actually the inverse of what we need: it fixes
rmmod cycle, but we are not doing rmmod.
AFAIK, no work has been done in the suspend-to-ram direction - I think some proper suspend()/resume() hooks are needed...
*** Bug 491235 has been marked as a duplicate of this bug. ***
*** Bug 513751 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
Larry has done some work in this area recently, and it is possible that the driver code in wireless-testing can suspend:
Author: Herton Ronaldo Krzesinski <firstname.lastname@example.org>
Date: Wed Dec 9 14:56:13 2009 -0200
rtl8187: add radio led and fix warnings on suspend