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."

Comments

A bug in Linux?

[Anonymous Coward]

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

[Anonymous Coward]

"Update: Looks like this is an xHCI specific issue, and probably not the cause of the USB device disconnects under EHCI. "

linux has bugs?

[Anonymous Coward]

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.

Re:linux has bugs?

[TheGavster]

It's true. Linus has been quite vocal about whose fault it is when a kernel change breaks an application...

Re:linux has bugs?

[Anonymous Coward]

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?

[hedwards]

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.

Maybe not all the disconnects?

[AdamHaun]

Sarah's Google+ post has an update:

Update: Looks like this is an xHCI specific issue, and probably not the cause of the USB device disconnects under EHCI. To everyone who commented with other USB issues (none of which really sounded related), please email the linux-usb mailing list with a description of your issue.

Re:not surprising, since there are few docs

[dltaylor]

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.

Re:Welcome to EE

[Ignacio]

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.

Dear Linux kernel, i'll be ready when my disk is done spinning up. kthanksbye

Dear USB hard drive, that's fine, but don't go and disconnect from the USB bus in the meantime. Forever waiting, Linux kernel.