Bug 469461 - [regression] rawhide kernel doesn't unload usb wireless driver on suspend?
[regression] rawhide kernel doesn't unload usb wireless driver on suspend?
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
: Triaged
: 491235 513751 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-31 20:24 EDT by Hin-Tak Leung
Modified: 2009-12-18 01:58 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:43:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 11887 None None None Never

  None (edit)
Description Hin-Tak Leung 2008-10-31 20:24:54 EDT
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...).
Comment 1 Hin-Tak Leung 2008-10-31 20:54:32 EDT
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 2 Pete Zaitcev 2008-11-20 16:41:25 EST
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.
Comment 3 Hin-Tak Leung 2008-11-20 18:05:31 EST
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...).
Comment 4 Hin-Tak Leung 2008-11-20 18:11:59 EST
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).
Comment 5 Hin-Tak Leung 2008-11-20 18:39:16 EST
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?
Comment 6 Hin-Tak Leung 2008-11-21 05:31:45 EST
tried subbing pre_reset()/post_reset() - it doesn't do anything useful...
Comment 7 Bug Zapper 2008-11-25 23:35:40 EST
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
Comment 8 John W. Linville 2009-01-13 14:40:26 EST
There was a fix for this upstream, no?  What was it?
Comment 9 Hin-Tak Leung 2009-01-13 17:55:11 EST
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@sipsolutions.net>
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@sipsolutions.net>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Comment 10 John W. Linville 2009-04-14 13:48:57 EDT
Hin-Tak, Zaitcev -- is there any progress/change here?  What needs to happen to resolve this upstream and in Fedora?
Comment 11 Pete Zaitcev 2009-04-14 14:02:29 EDT
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.
Comment 12 Hin-Tak Leung 2009-04-14 19:34:16 EDT
AFAIK, no work has been done in the suspend-to-ram direction - I think some proper suspend()/resume() hooks are needed...
Comment 13 John W. Linville 2009-07-21 15:48:40 EDT
*** Bug 491235 has been marked as a duplicate of this bug. ***
Comment 14 Till Maas 2009-08-17 14:44:52 EDT
*** Bug 513751 has been marked as a duplicate of this bug. ***
Comment 15 Bug Zapper 2009-11-18 03:43:24 EST
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
Comment 16 Bug Zapper 2009-12-18 01:43:00 EST
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.
Comment 17 Hin-Tak Leung 2009-12-18 01:58:55 EST
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@mandriva.com.br>
Date:   Wed Dec 9 14:56:13 2009 -0200

    rtl8187: add radio led and fix warnings on suspend

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