USB is an irritating protocol that requires USB controllers to remain active whenever a device is attached, even if that device is doing nothing. This consumes unnecessary power and can prevent the system going into deep idle states under some circumstances. The kernel supports USB autosuspend, which allows idle USB devices to be suspended and the upstream ports to power down. This is disabled by default because it breaks various pieces of hardware.
Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky.
The first part of this is an upload of libfprint which enables autosuspend on fingerprint readers. I'm expecting this to be pretty safe, but there's always the possibility that a couple of people will find problems. If your fingerprint reader suddenly stops working after this change, please file a bug and include the output of lsusb.
On Tue, Jun 9, 2009 at 10:32 AM, Matthew Garrettmjg@redhat.com wrote:
Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it.
As you move forward with this across the devicescape, how are you going to selectively enable devices to apply autosuspend to? Is this done by a whitelisting of specific device ids? Or is this going to be done based on a detected set of capabilities and then pruning that back with a blacklist?
I've got some exotic homebrew usb equipment that I'm going to have to troubleshoot on my own, so it would be useful to know how you are going to slice the device space so I can figure out which devices should and should not be affected..eventually.
-jef
On Tue, Jun 09, 2009 at 01:18:31PM -0800, Jeff Spaleta wrote:
As you move forward with this across the devicescape, how are you going to selectively enable devices to apply autosuspend to? Is this done by a whitelisting of specific device ids? Or is this going to be done based on a detected set of capabilities and then pruning that back with a blacklist?
A mixture. Some devices will be explicitly whitelisted, while in other cases we'll be enabling all devices in a class (generally as determined by the kernel driver they use) and possibly blacklisting some of them.
I've got some exotic homebrew usb equipment that I'm going to have to troubleshoot on my own, so it would be useful to know how you are going to slice the device space so I can figure out which devices should and should not be affected..eventually.
It's unlikely that any of them will be covered by this. For now I'll be concentrating on fairly common hardware in order to get the maximum benefit at minimum effort. We'll worry about more obscure devices at some later point.
On Tue, Jun 9, 2009 at 8:32 PM, Matthew Garrettmjg@redhat.com wrote:
USB is an irritating protocol that requires USB controllers to remain active whenever a device is attached, even if that device is doing nothing.
Is this somewhat addressed in the USB3 specs?
On Tue, 2009-06-09 at 19:32 +0100, Matthew Garrett wrote:
Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky.
Is this something worthy of being a feature?
On Wed, Jun 10, 2009 at 09:15:30AM -0400, Jesse Keating wrote:
On Tue, 2009-06-09 at 19:32 +0100, Matthew Garrett wrote:
Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky.
Is this something worthy of being a feature?
Possibly. I'd pretty much thought of it as bugfixing, but feature sounds fair.
On Wed, 2009-06-10 at 17:04 +0100, Matthew Garrett wrote:
On Wed, Jun 10, 2009 at 09:15:30AM -0400, Jesse Keating wrote:
On Tue, 2009-06-09 at 19:32 +0100, Matthew Garrett wrote:
Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky.
Is this something worthy of being a feature?
Possibly. I'd pretty much thought of it as bugfixing, but feature sounds fair.
Making it a feature would make for easy integration with the Test Day process, and this sounds like a good thing to have a Test Day for - it should be relatively easy, and beneficial to development (as we should be able to get people with a wide variety of devices to show up).
Please do ping me or jlaska if you'd be interested in doing a test day for this.
Matthew Garrett wrote:
The first part of this is an upload of libfprint which enables autosuspend on fingerprint readers.
Fingerprint readers and other "un-unpluggable" USB laptop stuff such as flash-readers, bluetooth adapters etc. are perfect candidates for suspending.
Is there somewhere any estimate about the amount of power this feature can save?
Best regards.
On Wed, Jun 10, 2009 at 05:16:41PM +0200, Roberto Ragusa wrote:
Matthew Garrett wrote:
The first part of this is an upload of libfprint which enables autosuspend on fingerprint readers.
Fingerprint readers and other "un-unpluggable" USB laptop stuff such as flash-readers, bluetooth adapters etc. are perfect candidates for suspending.
USB mass storage is more awkward, but otherwise yes. Note that this isn't inherently about suspending the device - they may go into a power savig state, but it's not required that they be fully powered down. The issue is more about letting the *bus* power down. How much we save will depend on the specific bus layout on a given machine, and also whether we can successfully autosuspend all of the drivers.
Matthew Garrett wrote:
The issue is more about letting the *bus* power down. How much we save will depend on the specific bus layout on a given machine, and also whether we can successfully autosuspend all of the drivers.
Modern machines are full of (mostly empty) buses, so there is hope the gain will not be insignificant. :-)
$ lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 010: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller Bus 003 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
issue is more about letting the *bus* power down. How much we save will depend on the specific bus layout on a given machine, and also whether we can successfully autosuspend all of the drivers.
Modern machines are full of (mostly empty) buses, so there is hope the gain will not be insignificant. :-)
This is also very true of servers where the vast majority of expansion and peripherals are either in regular use or not at all. In a data centre environment the vast majority of usb and KVM are disconnected for 99.999% of the servers life span. Would certainly be very significant across the lifespan of the average server.
Peter
-
Adam Williamson -
Gianluca Sforna -
Jef Spaleta -
Jesse Keating -
Matthew Garrett -
Peter Robinson -
Roberto Ragusa