Putting a lid on USB power
As it happens, a number of USB users have found that, on upgrading to 2.6.16, their systems do not work anymore. But, in this case, this "regression" is not seen as such by the developers and is not likely to change. This issue is a good demonstration of the sort of tradeoffs which operating systems developers must make.
USB ports can supply power to the devices plugged into them; this power is sufficient to drive many devices, as well as totally unrelated items (such as USB-powered LED lamps). There are limits to the amount of power which can be supplied, however. USB devices will communicate their maximum current draw to the host, which can then decide whether it has the capacity available or not. If sufficient power is not available, the device will not be allowed to configure itself and operate.
There are many rules in the USB specification on how power configuration should work. One of those applies to unpowered USB hubs - the ones which lack a power supply of their own. The total current drawn by an unpowered hub cannot be allowed to exceed what the host can supply; in particular, the USB specification limits devices on unpowered USB hubs to 100 mA of current. Even if only one hub port is in use, that single port is limited to that value, despite the fact that a larger draw should work in that situation.
Prior to 2.6.16, the Linux kernel did not actually check power requirements before configuring devices. With 2.6.16, however, any device whose stated maximum power requirement exceeds 100 mA will not be allowed to configure itself on an unpowered hub. Thus, devices which worked in that mode in earlier kernels now fail to operate; not all users are entirely pleased.
The argument has been made that, since these configurations almost always work in the real world, the kernel should not be shutting them down now. The fact is, however, that running hardware outside of its specifications is always a dangerous thing to do. Often one will get away with it, but sometimes things can fail badly. A fairly large class of USB devices are mass storage devices; the consequences of power-related problems with these devices could include corrupted data and damaged hardware. These are not consequences which the USB developers wish to inflict on their users, so, instead, they refuse to operate devices out of their specifications.
To the developers, the fact that some previously-working hardware now fails to operate is not a regression. It is a bug fix, with the kernel finally performing some due diligence which should have been happening all along. They do not intend to change this behavior.
As it happens, it is possible to convince the kernel to override its good sense and configure the device anyway. It is not easy, however. Essentially, the steps are this:
- Run lsusb -v and find the entry for the device of interest.
Your editor's USB mouse, for example, is described by an entry
starting "Bus 001 Device 003: ID 046d:c01b Logitech, Inc. MX310
Optical Mouse". This mouse is plugged into a hub listed
previously as being "Bus 001, Device 002". Together, these numbers
turn into a path number "1-2.3". This number is important.
- Under that same device entry will be found one or more possible device
configurations, along with their associated power requirements. Each
of these configurations includes a bConfigurationValue number
describing it. The number associated with the desired configuration
must be found; in many cases it is one.
- Force the device configuration with a line like:
echo -n 1 > /sys/bus/usb/devices/1-2.3/bConfigurationValueThe configuration values and path number must be replaced with the actual values determined from the lsusb output.
Needless to say, this sequence of steps is not entirely easy - and it must
be repeated each time the device is plugged in. For those who are
comfortable writing udev rules, this configuration change can be
automated without too much trouble. Perhaps the desktop environments will
eventually be made smart enough to detect this situation and offer (with
suitable scary warnings) to override the kernel for specific devices. But
it might just be better to buy a powered hub or plug the device directly
into the host.
| Index entries for this article | |
|---|---|
| Kernel | Development model/Kernel quality |
| Kernel | USB |
Posted Jun 8, 2006 2:20 UTC (Thu)
by allesfresser (guest, #216)
[Link]
Posted Jun 8, 2006 12:43 UTC (Thu)
by bjanz (guest, #1560)
[Link] (6 responses)
That being said, this change may have one significant "political" factor that seems to have been ignored: if the same device works under MS Windows but doesn't work under Linux, Linux will blamed. Period. And, if one of the myriad of "technology reporters" finds out that he can't use his mouse (the author's example, not mine), the bad news for the Linux community will be hard to overcome.
For some of us "road warriors", a way to power our hubs is not always available. But, we still need to use our USB devices. Hence, without commensurate instructions ("scary warnings" *as well as* "what-to-do's"), you may be shutting me down while I'm using my laptop on its internal battery. This is a *VERY BAD THING*.
Doing "the right thing" is not always the best thing to do. In this case, the Linux community may have acted exactly the way it claims Microsoft acts: "We know what is good for you -- even better than you do."
Me? I'll be writing the necessary UDEV rules to ensure that the devices I'm currently using *continue* to work the way they always have. And, if I "blow out" my hardware, ok. It would have blown out under MS Windows, too.
Hardware is cheap, folks. Much cheaper than a damaged reputation.
\burt
Posted Jun 8, 2006 15:50 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
We had a user who had an external USB drive that got its power off of his laptop along with his keyboard, mouse and LED light so he could work on his red-eye flights on the plane etc. His data got corrupted on the USB drive and it was Linux's fault. Turns out that his data had been corrupted regularly on his Windows side.. but he had come to expect that as a standard Windows bug. Turns out that we had a whole class of users who had been having the same problem with their windows systems, but had found it to be a known bug for the USB drive and just took it as an oh-well. It only became a 'known problem' to central support once Linux started corrupting data.
So, if your data is corrupted on your remote USB drive in Windows because it couldnt get enough power.. well thats what 99% of the world has come to expect of Windows. If you have that happen under Linux.. it is Linux's fault because it is supposed to be better.
Posted Jun 8, 2006 16:05 UTC (Thu)
by ebirdie (guest, #512)
[Link]
Secondly in my technopolitical experience many people would put data loss under their legitimacy Windows system to law of nature and data loss under a Linux system to untrustable technology, reputation damaged.
What comes to political correctness, at times Linux community is blaimed to follow Windows trails. Here I find it responsible as any other act put into fs- and block-layer to protect user's data (ata-drive cache issue comes to mind here). Although I admit, there will be fierce moments of frustration due to policy change unknown or forgotten at the moment of unusable USB-drive.
At the moment USB-drive doesn't mount it is very simple and inherent on Linux system to "dmesg | tail" and you are reminded and on your way to make it work. Well, some kernel messages leave space for better glue into the event/issue - at least to mere mortal like me.
Previous brings me to GUI, where I haven't yet found a configurable tool (window), which pops up when noticable things hapen in syslog as easily as manually doing "dmesg |tail" thus making a kernel message "usb-core: USB device not connected due to too high power requirement from USB-bus, change kernel policy or connect your USB device to external power." wipe away whole issue.
Posted Jun 8, 2006 19:35 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (2 responses)
That's right! So buy a $5.00 wall wart. Corrupted data causes farm more damage to reputation than the ability to run hardware outside of specification... doesn't it?
Posted Jun 8, 2006 21:36 UTC (Thu)
by bjanz (guest, #1560)
[Link] (1 responses)
You're missing the point. Someone who is running a device under MS Windows will question *and then abandon* Linux if the same device does *not* run under Linux.
If I buy a $5.00 WalMart cheap POS adapter, it'd blow up my system whether I was running MS Windows *or* Linux -- and I deserve what I get. But, if I buy a Logitech mouse or keyboard, or a SanDisk USB drive, or some other USB 2.0 "bus powered" device that is properly made and meets the USB 2.0 spec (like a Western Digital 120GB drive), and they *DON'T* work under Linux... that's a *very bad* thing.
This isn't about plugging in crap components. It's about compatibility. The only way to get new users comfortable with Linux is to provide *MORE* compability with existing devices -- not *LESS*. The way to keep "marginal" Linux users from migrating to other platforms (such as FreeBSD, or - Lord help us - Windows) is to be *BETTER* than the other platforms.
I opened my comments by saying that standards are a good thing. I'll even say that operating hardware according to standards is an even better thing. Protecting your system from unpredictable power events is an *excellent* thing.
But, a *backward* move in compatibility - "less" is NOT "more" - will only be seen as a *bad* thing.
Posted Jun 9, 2006 21:22 UTC (Fri)
by Pedja (guest, #37794)
[Link]
If I understand corectly, kernel disables out-of-spec devices.So, how
Posted Jun 11, 2006 11:16 UTC (Sun)
by jmayer (guest, #595)
[Link]
Posted Jun 8, 2006 20:42 UTC (Thu)
by cdmiller (guest, #2813)
[Link] (1 responses)
Posted Jun 15, 2006 10:38 UTC (Thu)
by quintesse (guest, #14569)
[Link]
And if attaching network cable that is too long can result in damage to my system I would certainly like the OS to turn off networking!
Of course, this being Linux and all I would also expect a way to turn those checks off if you really know what you are doing :-)
Posted Jun 8, 2006 22:12 UTC (Thu)
by giraffedata (guest, #1954)
[Link] (2 responses)
I guess I didn't follow the explanation. What hardware is being run outside its specs? You have a USB device designed to draw 150 mA. It's the only thing on the USB bus and the host port is designed to supply 500 mA. Linux knows all this and allows the device to join the system. What's wrong with that?
Others are talking about losing data. How does the old Linux behavior lose data where the new one doesn't?
Posted Jun 8, 2006 22:43 UTC (Thu)
by ehovland (subscriber, #2284)
[Link] (1 responses)
I would say that the hub and the USB host controller are the two hardware devices that would be driven to power levels that they were not necessarily specified. Since they were the ones who were suffering the brunt of this issue in older kernels.
Although I doubt running the hub beyond power spec is a serious problem, running the usb host controller hardware out of spec could cause no end of problems that may be difficult to diagnose if it is drawing too much power.
Posted Jun 9, 2006 2:00 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
Posted Jun 11, 2006 20:49 UTC (Sun)
by Frej (guest, #4165)
[Link]
Maybe show the all of the devices on the bus with not enough power.
If warning only shows when too much current is drawn, it should not be annoying.
I fully support this change--I've always considered powering high-draw mass storage devices over USB to be a foolish and dangerous exercise, and FireWire even more so. Running hardware on a connection that potentially underpowers it is just asking for trouble. And the USB coffee warmer, well, whatever floats your boat I guess but don't blame me if your port burns out.Putting a lid on USB power
I agree that standards should be followed as closely as possible.Coercing users is *never* a good idea
The issue is that Linux will get the blame either way. The following is a real world example.Coercing users is *never* a good idea [Unless they already expect perfection]
Hardware may be cheap, but data put into it isn't.Coercing users is *never* a good idea
Hardware is cheap, folks. Much cheaper than a damaged reputation.
Coercing users is *never* a good idea
"That's right! So buy a $5.00 wall wart. Corrupted data causes farm more damage to reputation than the ability to run hardware outside of specification... doesn't it?"Coercing users is *never* a good idea
"But, if I buy a Logitech mouse or keyboard, or a SanDisk USB drive, or some other USB 2.0 "bus powered" device that is properly made and meets the USB 2.0 spec (like a Western Digital 120GB drive), and they *DON'T* work under Linux... that's a *very bad* thing."Coercing users is *never* a good idea
can that WD 120GB drive, or any other properly made, by-the-specs, device
not work under Linux?
IMHO, this is a GoodThing[tm].
Why would Linux support badly made hardware?
I always assumed that the power protection was there. It never occurred to me, that Linux was skipping the check. Now I understand that the problems I'm seeing with the USB ports on my laptop is one of broken hardware: ehci worked fine in the beginning, but after I connected a usb-powered harddrive for the first time ehci would work only sometimes. To me it looks like my USB hardware got fried.Coercing users is *never* a good idea but protecting hardware usually is
The correct way to implemnent this is to turn it on to protect the hardware and make it possible to either turn off the check manually (in a global or per device way) or to manually change the powerlevel, e.g. if your hardware works reliably up to 200mW, then why not be able to change the limit to that value.
What next? The kernel checks to see if you are overclocking your processor and refuses to boot? The kernel determines your network cable is too long and disables networking? Why not produce a prominent warning instead of breaking functionality?Putting a lid on USB power
Well overclocking is a conscious action very difficult to perform by accident, plugging in one too many devices on the other hand is very easy. So the potential in doing damage to your system is much greater. I have a bunch of USB devices, but I have no idea how much juice they need or how much the ports on my system can provide (or should provide according to the specs) so yes I would like my OS to protect my system and my devices.Putting a lid on USB power
Putting a lid on USB power
The fact is, however, that running hardware outside of its specifications is always a dangerous thing to do.
> What hardware is being run outside its specs?Putting a lid on USB power
I thought the article was saying that Linux knows the capacity of the host USB controller hardware and therefore knows that it is within specs if the USB device is allowed to power up. Otherwise, what is the point of the device telling Linux how much current it needs?
Putting a lid on USB power
1) user plugs in devicePutting a lid on USB power
2) big fat warnings shows up, explaining the problem, i think people understand electricity :)
3) allow the user to enable the device, maybe readonly?