Misinterpretation of Standard Causing USB Disconnects On Resume In Linux 280
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."
Update (Score:5, Informative)
"Update: Looks like this is an xHCI specific issue, and probably not the cause of the USB device disconnects under EHCI. "
Maybe not all the disconnects? (Score:5, Informative)
Sarah's Google+ post has an update:
USB sucks (Score:5, Informative)
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.
Re:not surprising (Score:4, Informative)
You just said power management worked well on windows 98 and 95.
I am calling you a liar.
Re:not surprising (Score:5, Informative)
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.
Re:not surprising (Score:4, Informative)
Spoken like someone who's never had to reboot a computer from coma mode.
Re:not surprising, since there are few docs (Score:5, Informative)
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? (Score:4, Informative)
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.
Re:not surprising (Score:2, Informative)
There's a big difference between Windows where problems are a corner case, vs. Linux where success is a corner case. But the point still remains that I've used sleep and hibernate on most of my Windows machines without really fearing problems or data loss (I'll still save any progress before initiating it, though thanks to Office 97 I'm in the habit of saving regularly regardless), but I can't think of even bothering to try such a thing on Linux (nor can even of the people I know who love Linux enough to actually enjoy updating to a new distro every few months/years). I probably won't even think of trying to use sleep or hibernate on a Linux box until I see that the Linux kernel has developed drivers models that have some hint of being designed with power management in mind. Heck even the PCI driver model in Linux doesn't fit the spec well. Most Linux drivers I've had to deal with need to mess with the device's PCI configuration space themselves, whereas on Windows that's pretty rare because it's usually handled by the core kernel (which was the intent of the PCI spec based on how it's written).
Re:linux has bugs? (Score:1, Informative)
shh, its talk like that gets you downmodded to hell a week after the fact by the fanboi's who think icewasel + linux + libre office is all the universe needs
Re:linux has bugs? (Score:5, Informative)
Basically, the kernel has an Application Binary Interface which is a bit like a contract. If the application gives the kernel something formatted in a specific way, the kernal promises to give it back something in a specific way and the other way around. Any software that is written to respect the contract should never be broken by a change to the kernel as the application has no knowledge of how the kernel performs its obligation.
Changes to the ABI are not supposed to be common events. They're supposed to be changed only when lesser changes can't work. FreeBSD handles it using compatibility libraries which maintain the ABI for various kernel revisions so that applications can continue to use older ones if need be. AFAIK, Linux doesn't do that, and as a result, the kernel maintainer and the developers writing the code have to be even more careful about changes made not messing up the ABI.
Also, because Linux is just a kernel without a userland, a change to the Linux kernel that was permitted to break the ABI could hose all of the distros all at once requiring the rewrite of hundreds of little bits of software that are cobbled together to make the distros function as complete OSes.
There's more to it, but that's basically why Linus takes the stance that the kernel is to blame and not the developer. But, he undoubtedly doesn't consider it to be the kernel's fault if a developer does things that don't comply with the normal ABI specifications.
Re:linux has bugs? (Score:5, Informative)
The ABI has been changed upon occasion. If a struct passed to a syscall (or ioctl) has some spare option bits (that were reserved [and therefore zero], that can be the way to go (e.g. turning on the bit indicates that the program is aware of the new semantics).
Otherwise, a new syscall (or ioctl) number is assigned. For example, the stat syscall originally had a syscall number of 18. When the "struct stat" was modified [added some new fields and/or expanded the size of others], the syscall number was bumped to 106. Old programs that were not recompiled issued stat with 18 and worked unchanged. If you recompiled, you got syscall 106 and the new semantics.