Slashdot Mirror
Misinterpretation of Standard Causing USB Disconnects On Resume In Linux
hypnosec writes "According to a new revelation by Sarah Sharp, misinterpretation of the USB 2.0 standard may have been the culprit behind USB disconnects on resume in Linux all along rather than cheap and buggy devices. According to Sharp the USB core is to blame for the disconnections rather than the devices themselves as the core doesn't wait long enough for the devices to transition from a 'resume state to U0.' The USB 2.0 standard states that system software that handles USB must provide for 10ms resume recovery time (TRSMRCY) during which it shouldn't attempt a connection to the device connected to that particular bus segment."
Clearly the whole thing is broken, and we should transition to a newer, more open and transparent system than even open source.
I will call it OPENER Source. You aren't just able to read the source, you're required to read it!
"Update: Looks like this is an xHCI specific issue, and probably not the cause of the USB device disconnects under EHCI. "
Could have fooled me, I end up spending upwards of 3 months a year fixing bugs in the base os that we ship to run our appliance on. Some of the linux subsystems still read like they were written in someone's basement even after a decade of most of the maintainers being paid a yearly salary to maintain it. God forbid you actually fix some of the crap and post fixes though that are more than ten lines long.. Its a fine way to get blacklisted.
Sarah's Google+ post has an update:
Visit the
USB as a whole is already a silly design, having all these silly details and ambiguities. For example, where it has a minimum time (10ms in this case), it should also have a maximum time (for example 50ms). Devices should be able to communicate after that maximum time or they are broken. Actually, there should be a maximum time when powered up ... how is a minimum even useful for anything.
This only needs to specify controller communication, not device function. For example a hard drive might take several seconds to spin up and get in sync. But the controller should be able to do basic communication in 50ms, even if all it can say about the actual hard drive is "spinning up but not ready". USB has a lot of other stuff that is far from the KISS principle.
now we need to go OSS in diesel cars
You just said power management worked well on windows 98 and 95.
I am calling you a liar.
15+ years is a stretch. Even in the 2006-07 era at the end of XP's development, there were brand new machines that couldn't return from sleep correctly. It was particularly vexing since a lot of them were laptops factory configured to sleep when left unattended. I will say that I haven't had any complaints with S3 sleep since the advent of Windows 7, however.
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
Back in the mid-1990s to the mid-2000s when I used Windows, I realized sleep mode was a complete joke, unreliable, and just stopped using it by the time I upgraded to Windows XP or shortly after. In Linux, I am still not a fan of waiting for the damn thing to "wake up" for 5-10 seconds before it will even accept my password, so the only component that ever even enters standby on my machines is the moniter (and this has been the case for over a decade, even dating back to my last years in Windows). Windows, Linux--doesn't matter what the OS is, not putting the system into standby makes the whole experience much smoother, faster and hassle-free.
On the other hand, though--it is a good thing this was fixed for those laptop users out there.
Spoken like someone who's never had to reboot a computer from coma mode.
If I have been able to see further than others, it is because I bought a pair of binoculars.
The 10ms is for the software. The flip side of this is that the hardware has a maximum of 10ms to get its shit together so that it can be connected to. And 10ms is forever in hardware.
Far too many vendors are only willing to provide chip documentation under a Non-Disclosure Agreement (NDA), which prevents a knowlege-, as opposed to empirical-based Linux driver. This allows them to kludge around chip deficiencies in a Windows driver without the user being aware of any issues. Even Intel has started making it harder to get the real manuals for their CPUs and bridges (they used to ALL be published on Intel's FTP and HTTP sites). Frequently, in System-on-Chip (SoC) implementations, even the CHIP vendors don't know anything; they just pass along whatever quick and dirty proof of concept the designers of some feature of the chip provided and call it a "working driver", while it is nothing that would pass even a cursory QA process.
The first Linux code I wrote was a "quirk" handler for a parallel ATA PCI chip that came up programmed to the same default I/O addresses as the South Bridge's internal ports, and a BIOS that didn't properly perform PCI enumeration on it, since it already had PCI addresses.
So I can close my laptop now instead of carrying it around like a sort of open pizza box for fear of never having a working mouse until the next reboot? How annoying to start a meeting by rebooting a Linux laptop.
Kriston
THe other one is my wife's so it isn't running Linux.
My wife's laptop is running Debian 7. What's up with your wife? :)
Write failed: Broken pipe
That is why my laptop sd-card reader is not working when I close the lid... until reboot. F!*$&%" usb...
Tomorrow is another day...
There is no ambiguity in the USB spec, and Sarah has an incorrect interpretation. The spec requires that the host provide at least 10 ms of recovery time coming out of suspend; a device is required to be able to communicate after this minimum time. Any device which isn't ready for communications after 10 ms of resume recovery time is broken. A host is permitted to provide more than this, but isn't required to.
So, yes, it's perfectly valid for the host to blindly attempt to communicate with the device after 10 ms - presuming that the host KNOWS precisely when the recovery period began. If the host requested that the bus resume, set a timer for 10 ms, and then tried talking, the HOST is at fault because it didn't check with the hardware as to when the resume period began. I think the 17 ms that they reference in the article is related to this - there is a delay between the request to resume the bus and the actual time that the hardware does resume the bus, so they were trying to talk with devices before the 10 ms period was up.
The device is perfectly within the spec if it ignores communications prior to 10 ms, or if it responds to them - it has complete flexibility. After 10 ms, however, it MUST be ready to communicate.
And the worms ate into his brain.
i've got a laptop that blue screens when you pull out the power cord.
If i remember correctly a lot of the power management problems are due to the manufacturers not implementing the standards correctly, they implemented them to the broken Windows implementation in order to keep WIndows working.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
FWIW, I now have a policy of avoiding Acer like the plague and advising my customers to do the same, owing to their appealing customer support when advised that an entire product line had a bios bug.
http://www.nexusuk.org/~steve/acer.xhtml
TL;DR: one of their lines of laptops has a dsdt bug, I informed them, they weren't interested. I even sent them a patch, still not interested (and decided that completely ignoring my emails was the best approach). To this date they haven't released an updated bios.
http://blog.nexusuk.org
Oh heavens, it must be happening again. I'm obviously experiencing a relapse of those terrible hallucinations that have plagued me for years.
Oh, wait, she's real after all.
Dude, you posted a photo of a laptop sitting on the armrest of an empty couch ;)
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
... stubbornly refuses to sleep with win7. Works fine with Linux.
At least she has some standards.
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.