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."
Thank you for being a friend
Traveled down the road and back again
Your heart is true, you're a pal and a cosmonaut.
And if you threw a party
Invited everyone you knew
You would see the biggest gift would be from me
And the card attached would say, thank you for being a friend.
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.
Power Management has worked well on Windows for 15+ years. I'm still waiting for Linux's first year, so problem on Linux are with the kernel and/or the drivers.
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
Unfortunately, the article's referring to the "misinterpretation" passively, not saying directly who the author is asserting misinterpreted the spec, but I think from context it seems to be saying "misinterpreted by Linux", as opposed to "misinterpreted by lots of cheapo USB devices". It's bad that Linux does that, but it's certainly easier to fix in one place in Linux than going out to lots of vendors putting out equipment with very low profit margins and hope they'll all do the right thing.
I was also a bit confused as to when the article was referring to microseconds (s) vs. milliseconds (ms); I found it surprising that it seemed to be saying that most of the devices responded in under a microsecond, while others were over 10ms.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I don't know how relevant this new info is to the problem, but there's an update over at the Sarah Sharp's G+ page:
"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."
Captcha: corrects (I hope I'm not wrong.)
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.
She's too hot to be a programmer. This is clearly a front or shill by some middle-aged neckbeard.
I want to delete my account but Slashdot doesn't allow it.
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
stop being cheap and get a mac
Unless the USB is on. It does not wake in time. Craptastic.
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 “'esume 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."'
Wow, ever heard of something called "comma"? Let me fix that for you.
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 “'esume 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."'
See? Much easier to understand now. Other than that, I'm guessing that "esume" is a typo, and the quotation marks are all messed up too.
I have toggle switches and neon bulbs for an interface.
That is why my laptop sd-card reader is not working when I close the lid... until reboot. F!*$&%" usb...
Tomorrow is another day...
When not rambling about feminism.
See, a non-geek would know that you have to wait for a while before you ask the same girl out again after a failure to connect the first time.
Table-ized A.I.
Normally one could write the USB spec (lets say X spec) in a high level language (that specifies behavior, say HLL) as a reference implementation that could be taken by the OS (any OS) to derive the driver. This spec should be provided by the X standards body (could b even a company) . Moreover it could interface to Y spec in the same high level language and still generate a X:Y composite driver or even create two drivers at kernel level that interface with some OS specific way. The standards body could verify X or X:Y for correct operation and publish it along with the PDF spec. The problem is that many people believe that the knowledge of C or some kernel internals are a form of qualification when we live in 2013. The real qualification is to create the HLL to kernel interface translator. Science is lacking from software in many many circumstances. Companies, selfish programmers f@^(ing money are to blame. But the problem is that OSes far better than commercial ones fail because of lack of drivers. Or equivalently by the lack of mapping the spec to their kernel interface in a hand-written time consuming error prone way due to complexity. The big thing is how to write the kernel (or the microkernel) to support apps known as drivers .... among others.
We have functional, logic and functional logic languages. But we still live in caves imposed by companies and incompetent programmers that act like priests in ancient Egypt and companies that cheat on their customers. The above article shows a big symptom of a deep problem in CS. It is lack of professionalism, lack of scientific method and lack of freedom. The HW companies should only sell hardware accompanied with documentation. They should not be allowed to give drivers for an OS which poses a competitive advantage to a company. It should be illegal. This is not about OSS, its about common sense. However the UEFI secure boot and recent NSA story say something different. It says that there are no government entities willing to pose limits on the power of companies. Instead they fuel them.
The paradox arising is that in 2013 many develop like in 70s. It is a form of autism, it is a kind of slavery, it is a sign of decay.
Please, somebody fix this fast. Otherwise 2014 may not be the year of Linux on the desktop with these crappy USB problems. End users shouldn't have to patch and recompile their kernel IMO.
Maybe all you need is the right protective sleeve that fits the laptop in this positon. Like two sleeves sewed together or something. Or something like a plastic box with a handle ? Could be included: a Teensy based USB device that sends mouse events every 30 seconds to prevent computer from going to sleep. See ? Problem "solved".
You might as well try to tell the Sun not to set tonight.
And on the Eighth Day, Man created God.
Far to many companies are prepared to buy chips with documentation under NDA. I would expect engineers who specify these chips to be sacked by a sensible manufacturer.
Sent from my ASR33 using ASCII
However the rules changes about breaking applications:
-Security. If there needs a security bug to be fixed (null pointer checks and so on) all bets about compability are off.
-open standards. If some standard like posix says a function should return X and linux returns Y, THen there is the choice to stay on the linux island and keep returning X or change the ABI to be compliant to some other unix.
And if you use the wrong language to some maintainer (since you are an engineer, not a politician....), or happen to do something in a subsystem that has an inactive maintainer you patches will stay silently in some unknown patch queue.
pulling an usb from linux without 'ejecting' it first always corrupts my usb drives under linux. but never ever under windows.
Try pm-suspend-hybrid, this will initiate a normal hibernate: copy ram to disk as usual, but at the end it won't shutdown, but go into suspend. Result: If you come back, its instant on; but if the power ran out or was unplugged, your state is still saved and you return from hibernation.
People still unplug their stuff or let the batteries run out so don't expect that scenario until a memory technology that keeps its state without power (such as mram) becomes the norm.
Artix
Your Linux, your init.
Why does it matter if you need to sign an NDA when buying chips?
I mean you get all the documentation anyway, you just cant share it.
You cannot share the real functionality of the chip registers by documenting them in a working Linux (GPLv2) driver.
My Samsung notebook showed the same behaviour running Linux Mint (I don't touch MS stuff, and haven't for 11 years or so). The solution I found was to turn off suspend in BIOS - then the OS puts the notebook to sleep on lid shut, and to wake it up just hit (or in my case 'slide') the power button. Still two steps, but I find it easier and quicker rather than waggling the lid up and down. On another note, my wife's Acer notebook suspend works perfectly running Ubuntu.
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.
I switched from FreeBSD to OS X about ten years ago and sleeping/waking has always worked properly since.
I've been filing bug reports against usbcore for violating this USB spec for nearly 8 months, only to have them angrily dismissed as being "incorrectly interpreting the USB standard."
So, now I get to say it:
I INFORMED YOU THUSLY
and
FUCK YOU.
few reasons, some NDA do not allow you to share any work derived from information in the datasheets. ie no open source. Another problem Ive encountered is the fact that many chips are not designed by the company selling them, companies buy the orig company to gain their IP alone, and dont care about the actual chipset anymore.
The saa7160 was orig designed by Phillips, then NXP took it over, they then sold it to Triden Micro, they are now bankrupt and in receivership. So the datasheets are lost forever, anyone that signed an NDA in the past do not have the right to distribute them, and there is no way to get a person to get a datasheet.
The CX24132/CX24117 were orig designed by Conexant, then sold the NXP which promptly stopped production, NXP only releases datasheets to products they sell to encourage sales (often they only release them along with the purchase order). Those datasheets are lost forever as well.
NDA's have many downfalls, its not as cosy as you imply
UDL
I have a Dell XPS, and I use Kubuntu 12.04. I use suspend to RAM everyday, rebooting only on kernel updates. So, just to make clear: the problem is on chipo devices, and this affects not only Linux.
(stupid oversight. the last 15 or so years, cable and connector designers have been pretty idiotic. don't get me started on that rant..)
I'll do that rant since I run a company that manufactures cables and cable assemblies. I can't speak to the software (I'm not a software guy) but the hardware on USB cables is less than impressive. They designed it to have a cheap controller but at the expense of needlessly complicated and expensive cables. That would have been ok if the cables themselves were well designed but they're pretty flawed designed in my opinion.
The USB connectors are keyed, presumably for cost and safety reasons. Now that isn't an entirely bad idea since you obviously don't want a connector to plug in the wrong way. But they could have designed it so that you didn't have to worry about orientation at all. Seems like everytime I try to insert a USB cable it invariably is upside down. While I'm not a huge fan of Apple's Lightning connector, the fact that I don't have to fuss with orientation when inserting is a terrific feature. I shudder to think how many many hours have been wasted by trying to insert USB cables upside down. It wouldn't be hard to have a wiring topology that figures out the orientation and behaves accordingly.
Many USB cables use different connectors on each end. This was done to mechanically prevent two powered devices from causing problems to each other. While simple it really is kind of a bandaid fix that needlessly increases the price of every USB cable. The devices should have enough smarts to handle that rather than using an unnecessary and costly second connector on every single cable. So now we have at least six different standard USB connectors when there should be at most two and probably just one.
USB cables are almost exactly the same width as the 8P8C (commonly called RJ45) ethernet connectors so as pointed out before you can insert on into that socket. They easily could have designed it to a different width than another super common connector on PCs.
USB cables are not physically robust. I've seen quite a few destroyed even without rough handling. The connectors simply aren't designed to be as durable as it should be.
I'm pleased someone has finally diagnosed (and presumably will fix) this.
As presented, the cause actually sounds quite simple so I'm surprised how long its taken to get to it (several years) given how widespread Linux is and how many corporates are paying people to make Linux better.
Non-free hardware documentation is generally a problem but in this case all of the USB specs are available for free.
I am becoming gerund, destroyer of verbs.
Anyone desiring to use Linux will be required to print out the entire Linux source code (on an Epson dot matrix printer), read every page, and then initial it to confirm their understanding. This will be mailed in to the FSF to track compliance.
If there are any bugs found then everyone who signed that page gets their license revoked.
I am sure with this fool proof plan the Linux userbase will double in no time!
Often you don't have a choice. Mobile SoCs, image sensors, and networking are all NDA'd up, to give a few examples.
Although this stuff is way over my head, I admire Sarah for all of her hard work in such a cut-throat industry. Being a woman, I can't imagine the extra pressure she has to put up with.
If she spent more time understand the spec that governs the code she is supposed to maintain and less time tending to her weeping vag on LKML it might not have been a problem.