Bug 210600 – Removing the a usb card wireless module does not turn off the device

• Product: Gentoo Linux
• Status: VERIFIED INVALID

[Description Paulo da Silva 2008-02-18 16:38:11 UTC]

Removing usb wireless modules, for example ndiswrapper, does not turn off the devices.
This is important for laptops. Devices, when not in use, should be
turned off.


Reproducible: Always

Steps to Reproduce:
1. devices->USB support->USB selective suspend/resume and wakeup (USB_SUSPEND) is needed
2. rmmod ndiswrapper
3.

Actual Results:  
The led of the usb card remains on


Expected Results:  
The led of the usb card turns off


This only happens with later kernels (2.6.24 in my case, but may be before of this). My last working kernel was 2.6.22-suspend2-r2.

The reason for this problem is:
For later kernels, /sys/bus/usb/devices/<n-n>/power/level is initialized with "on" instead of "auto" as it was before.
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.

[Comment 1 Mike Pagano 2008-02-19 02:56:52 UTC]

This is by design and the reasons are documented at length in the following file:

<kernel src directory>/Documentation/usb/power-management.txt

in the "Warnings" section.

[Comment 2 Daniel Drake (RETIRED) 2008-02-19 08:54:16 UTC]

and it is an ndiswrapper bug that ndiswrapper does not power the device down when the network interface is brought down. You might want to try contacting ndiswrapper upstream.

[Comment 3 Paulo da Silva 2008-02-19 18:23:32 UTC]

(In reply to comment #1)
> This is by design and the reasons are documented at length in the following
> file:
> 
> <kernel src directory>/Documentation/usb/power-management.txt
> 
> in the "Warnings" section.
> 

Ok! I read that. For me was easy to turn around this. I just changed my script to turn the net on.
But what about Gentoo (and other distros)? An average user does not care where the problem is but that the problem exists.
For laptops this is a very important issue as you know.

[Comment 4 Paulo da Silva 2008-02-19 18:38:32 UTC]

(In reply to comment #2)
> and it is an ndiswrapper bug that ndiswrapper does not power the device down
> when the network interface is brought down. You might want to try contacting
> ndiswrapper upstream.
> 

No. This is not my role. I don't even know if the problem is from ndiswrapper or any other wifi driver! For example when the computer starts, without ndiswrapper being loaded yet, the card is "on".

In previous kernels, the card started off, turned on when ndiswrapper (or any rt2* modules) was loaded and turned off again when I removed the module. May be the need to insert/remove the module to turn the card on/off is not the best idea but there should be a way to turn the card on when I start the network and off when I shutdown the network.

IMO this should be a matter to be discussed by distributions, kernel (and ???) developers.

Regards.

[Comment 5 Mike Pagano 2008-02-20 00:16:20 UTC]

Paulo,

Gentoo does change make unilateral changes to the kernel.  Our policy is to troubleshoot problems and if needed, submit changes to the upstream kernel and/or backport fixes already in the development kernel via genpatches.

http://dev.gentoo.org/~dsd/genpatches/about.htm

This is not a kernel bug. 

[Comment 6 Paulo da Silva 2008-02-20 00:53:06 UTC]

(In reply to comment #5)
...
> 
> This is not a kernel bug. 
> 

At this point I am not saying this is a kernel bug or even a bug at all.
But it is certainly a distribution issue. Distribution developers have at least part of the responsibility to have its OS performing correctly. If something is or seems wrong they must discuss the problem among them, with the users and/or with upstream of the applications involved.

Besides, the distribution devs may change the script to start/stop the network to change the erroneous behavior when a usb card is involved.
From the document cited in comment #1:
"we hope that in the near future device managers such as HAL will take on this added responsibility. In the meantime you can always carry out the necessary operations by hand or add them to a udev script."

Being this not a real bug, I agree that the discussion should be moved to any other place (any forum?).

A I said I turned around the problem. So, you may close this "bug" report.
But the problem remains, however.

Regards.
Paulo

[Comment 7 Daniel Drake (RETIRED) 2008-02-20 01:10:21 UTC]

Unfortunately we do not have a good out-of-the-box solution for this right now. Sorry about that.

The problem is that many many many USB devices break after being suspended, so many that maintaining a blacklist of broken devices is infeasible. If we were to adjust the kernel default back to automatically suspending devices, we would have a lot of non-operational devices on our hands.

The real solution will be selective suspending controlled by a userspace agent (HAL or something). If you wish to take this up further, the linux-usb mailing list would be a good place to start.