Description of problem: older kernel (2.6.26.7-86.fc9.x86_64) seems to automatically unload usb-wireless driver on suspend, but new one (2.6.27.4-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): 2.6.27.4-69.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1. boot 2.6.27.4-69.fc10.x86_64 2. select suspend from nm-applet 3. <takes forever and never suspend> Actual results: blinking cursor, does not suspend and requires a power-off reset. Expected results: suspend properly and can resume afterwards. Additional info: reported in http://bugzilla.kernel.org/show_bug.cgi?id=11887 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 <stern.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.edu> Signed-off-by: Greg Kroah-Hartman <gregkh> -----------
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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. commit 6aab2c9285aa21512dff108ba945e1b0f2c68fba Author: Johannes Berg <johannes> 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 <johannes> Signed-off-by: Larry Finger <Larry.Finger> Signed-off-by: John W. Linville <linville>
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: commit 643e9f2959333c0a83ac33e8a247be2d3132105e Author: Herton Ronaldo Krzesinski <herton.br> Date: Wed Dec 9 14:56:13 2009 -0200 rtl8187: add radio led and fix warnings on suspend