bug or feature request - kernel: Removing modules do not turn off devices

Bug #150783 reported by Paulo
4
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Undecided
Unassigned
linux-source-2.6.22 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

I noticed that removing usb wireless modules, for example, does not turn
off the devices.
This is important for laptops. Devices, when not in use, should be
turned off.
I think this is caused by kernel not being built with devices->USB
support->USB selective suspend/resume and wakeup (USB_SUSPEND) enabled.
Not sure here however.

Regards.

Revision history for this message
Todd Deshane (deshantm) wrote :

What version of kernel version are you using?

Also, can somebody find the package that this affects... I thought it would be linux-image or kernel something, but I couldn't find it in the choose package interface

Revision history for this message
Paulo (psdasilva-deactivatedaccount) wrote :

kernel 2.6.22-13.
I think any recent kernels have that option.
The modules involved are those related with rt2570 legacy usb wireless drivers or ndiswrapper+rt2500usb, at least.

BTW, my ASUS wl-167g USB does not work with rt2x00usb drivers. It works with rt2570 legacy (cvs) and with ndiswrapper. I'll wait for newer rt2x00 versions before filing a new bug.

Revision history for this message
nowshining (nowshining) wrote :

i've had this issue sort of myself an example is that i blacklisted midi and supertux still plays midis which is odd because there is no midi modules to be found in lsmod. So i'm guessing this is similiar and if so then it's a confirm from me also.

Revision history for this message
Paulo (psdasilva-deactivatedaccount) wrote :

I could see that the latest K sources already have USB_SUSPEND.
Unfortunately they do not work however (!). Removing the wireless module does not turn off the led from my USB wireless card.

I have been playing with the kernel options trying to find any other reason/configuration without any success so far! I am sure that USB_SUSPEND is needed although it seems to be not enough.

Does anybody have any suggestion I could check?

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi All,

Sorry for the extremely delayed response. The Hardy Heron Alpha series was recently released which contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

Also note that we will keep this report open against the actively developed kernel. However against linux-source-2.6.22 this report will be close as it does not qualify for an SRU candidate. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates . Thanks!

Changed in linux:
status: New → Incomplete
Changed in linux-source-2.6.22:
status: New → Won't Fix
Revision history for this message
Paulo (psdasilva-deactivatedaccount) wrote :

Well ... I had a few problems in order to boot. The current release failled to recognize my graphic card and did not install "radeon" module. Perhaps because of this it also generated a wrong xorg.conf. So loading "radeon" manually did not work. After loading gdm my system displayed a black screen with some garbage on top and the keyboard was completely frozen except for kernel magic keys (ctrl+alt+prt sc+...).

Anyway I could boot without splash and typing several ctrl-c/alt-f1 when the gdm began to startup I could get a console (BTW, any other way to boot without X?).

I removed all rt2* modules but the wifi USB card still kept its led on.
So, the bug still exists.

Regards

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

Revision history for this message
Paulo (psdasilva-deactivatedaccount) wrote :

I have been analyzing the problem using a 2.6.24 kernel and I found where the problem is.

As I thought, devices->USB support->USB selective suspend/resume and wakeup (USB_SUSPEND) is needed.

Besides, for later kernels, /sys/bus/usb/devices/<n-n>/power/level is initialized with "on" instead of "auto".
Doing 'echo auto > /sys/bus/usb/devices/<n-n>/power/level' fixes the problem.

I don't know the reason for this to have changed however.
May be upstream has something to say about this.

Changed in linux:
status: Incomplete → In Progress
Revision history for this message
Paulo (psdasilva-deactivatedaccount) wrote :

Reasons for the change are reported on kernel documentation
.../linux/Documentation/usb/power-management.txt
"Warnings" section.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Paulo,

Thanks for all that research and feedback. Just to provide some additional information, USB_SUSPEND is enabled by default in the Ubuntu Hardy Kernel:

ogasawara@yoji:~/ubuntu-hardy/debian/config$ grep -rn "USB_SUSPEND" *

amd64/config:2875:CONFIG_USB_SUSPEND=y

i386/config.386:1995:CONFIG_USB_SUSPEND=y

i386/config.server:1997:CONFIG_USB_SUSPEND=y

i386/config.virtual:490:# CONFIG_USB_SUSPEND is not set

i386/config.generic:1991:CONFIG_USB_SUSPEND=y

ia64/config:2349:CONFIG_USB_SUSPEND=y

lpia/config:2657:CONFIG_USB_SUSPEND=y

powerpc/config:2521:CONFIG_USB_SUSPEND=y

I'll also provide a link to the document you reference in case others don't know where to find it:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/usb/power-management.txt;h=b2fc4d4a99177be7bd48dce560d1f28417c60aa9;hb=HEAD

The solution you've found appears to have resolved the issue. From what was mentioned in the kernel doc, it's unlikely that the power/level attribute will be set to default to "auto" because of the issues it raises so I'll be closing this report. Thanks.

Changed in linux:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.