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."
Re:linux has bugs? (Score:5, Insightful)
It's true. Linus has been quite vocal [lkml.org] about whose fault it is when a kernel change breaks an application...
Resume? What's that? (Score:5, Insightful)
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.
Welcome to EE (Score:5, Insightful)
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.
It explains a lot! (Score:4, Insightful)
Re:linux has bugs? (Score:4, Insightful)
Im not a software dev, but I have never agreed with this:
If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs.
What happens when some program has been using a privilege escalation bug to get around sudo, and it breaks when the kernel is patched to fix the vulnerability? Is that still "a kernel bug", should they not patch it? It seems to me that, yes, you try not to break applications, but this is why you have an official, supported API, and if bad developers want to rely on buggy kernel behavior for their programs, you have to choose between either screwing them, or screwing everyone else.
If anyone can enlighten me as to why thats wrong, Id appreciate it.
Re:Misinterpretation *By Linux* (Score:5, Insightful)
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.
Re:linux has bugs? (Score:5, Insightful)
For all practical purposes there's no way, I repeat, no way to "heat the whole apartment block" to eradicate bed bugs.
So you don't know what you are talking about.
If anyone can enlighten me as to why thats wrong, Id appreciate it.
1. syscall returns -EFOO when to report condition A
2. hmm, someone notices that -EFOO is too generic. That syscall should return the more specific -ECOND_A_ERROR instead. They change it.
3. ALL SOFTWARE suddenly works *different* and perhaps does not work at all on the modified kernel that uses that syscall vs.older kernel.
Kapish??
Do not change API internals. Fixing undocumented features (ie. bugs, like overflows) is one thing. Modifying documented and established API on a whim is a bad bad bad thing.
If you want to modify it like that, you do the following,
1. syscall returns -EFOO when to report condition A
2. hmm, someone notices that -EFOO is too generic. That syscall should return the more specific -ECOND_A_ERROR instead. SO MAKE A NEW SYSCALL THAT RETURNS CORRECT! Leave old one as deprecated for removal in some years.
3. ALL SOFTWARE continues to work.
If #2 is too much effort for reward, then do nothing. But above all, do not break userland with kernel changes. Ever.
Re:linux has bugs? (Score:3, Insightful)
Re:So I can close my laptop now? (Score:5, Insightful)
Because most laptops generally have terrible pointing devices. If they have touchpads, they're usually far too tiny to be useful (Apple ones excluded - why can't others put big ass touchpads on their laptops?)
The rubber trackpoint ones are nice for PCs, though the rubber tips wear down way too quickly and you end up with a slippery lump in short order.
And practically all are pathetic at scrolling. Unless it's an Apple trackpad where the double finger scroll works (once you fix the ()#@% scroll direction).
Life's just generally easier with an external pointing device.
Re:not surprising (Score:3, Insightful)
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.
Re:linux has bugs? (Score:4, Insightful)
Yet you still choose it as the base OS to run your appliance on. Presumably it's still better than any of the alternatives.
All software has bugs. I'm sure plenty of device drivers written in brightly lit offices by people with smart haircuts and shiny shoes have some absolutely horrific code too. I doubt which floor you work on has any significant effect.