Weekly Edition
Return to the Kernel page
| |||||||||||||
Putting a lid on USB power
Kernel bugs are bad news. Among the worst bugs are regressions -
situations where a once-working system breaks after a kernel upgrade. The
kernel developers have been taking an increasingly hard line against
regressions; patches which break working systems will usually be reverted,
even if those patches fix other problems. The idea, as pushed by Linus, is
that once a system works, it should
continue to work into the future.
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:
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. (Log in to post comments)
Putting a lid on USB power Posted Jun 8, 2006 2:20 UTC (Thu) by allesfresser (subscriber, #216) [Link] 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.
Coercing users is *never* a good idea Posted Jun 8, 2006 12:43 UTC (Thu) by bjanz (guest, #1560) [Link] I agree that standards should be followed as closely as possible.
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
Coercing users is *never* a good idea [Unless they already expect perfection] Posted Jun 8, 2006 15:50 UTC (Thu) by smoogen (subscriber, #97) [Link] The issue is that Linux will get the blame either way. The following is a real world example.
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.
Coercing users is *never* a good idea Posted Jun 8, 2006 16:05 UTC (Thu) by ebirdie (subscriber, #512) [Link] Hardware may be cheap, but data put into it isn't.
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.
Coercing users is *never* a good idea Posted Jun 8, 2006 19:35 UTC (Thu) by bronson (subscriber, #4806) [Link] Hardware is cheap, folks. Much cheaper than a damaged reputation.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 Posted Jun 8, 2006 21:36 UTC (Thu) by bjanz (guest, #1560) [Link] "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?"
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.
Coercing users is *never* a good idea Posted Jun 9, 2006 21:22 UTC (Fri) by Pedja (guest, #37794) [Link] "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."
If I understand corectly, kernel disables out-of-spec devices.So, how
Coercing users is *never* a good idea but protecting hardware usually is Posted Jun 11, 2006 11:16 UTC (Sun) by jmayer (subscriber, #595) [Link] 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.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.
Putting a lid on USB power Posted Jun 8, 2006 20:42 UTC (Thu) by cdmiller (subscriber, #2813) [Link] 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 Posted Jun 15, 2006 10:38 UTC (Thu) by quintesse (subscriber, #14569) [Link] 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.
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 :-)
Putting a lid on USB power Posted Jun 8, 2006 22:12 UTC (Thu) by giraffedata (subscriber, #1954) [Link] The fact is, however, that running hardware outside of its specifications is always a dangerous thing to do. 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?
Putting a lid on USB power Posted Jun 8, 2006 22:43 UTC (Thu) by ehovland (subscriber, #2284) [Link] > What hardware is being run outside its specs?
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.
Putting a lid on USB power Posted Jun 9, 2006 2:00 UTC (Fri) by giraffedata (subscriber, #1954) [Link] 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 Posted Jun 11, 2006 20:49 UTC (Sun) by Frej (subscriber, #4165) [Link] 1) user plugs in device2) big fat warnings shows up, explaining the problem, i think people understand electricity :) 3) allow the user to enable the device, maybe readonly?
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.
|
|||||||||||||