Discovered problems in Linux kernel connections to USB devices

Because of a faulty coordination between the hardware and the USB stack in the energy management of the Linux kernel connections to USB devices are frequently interrupted. So far, the kernel developers have looked to blame the device manufacturers. The kernel hacker Sarah Sharp has discovered a serious bug in the Linux kernel. Thus, a faulty coordination between USB stack and equipment when leaving the sleep mode is responsible for the connection to USB devices are abruptly cut off when auto-suspend is enabled. A patch is in the works. The problem of indiscriminate terminations of connections to USB devices is there and other kernel hackers known for years, writes Sharp. However, they have "cheap, crappy and broken" to blame searched devices, so the manufacturers. The blacklists created for this purpose by the kernel developers have become too big someday. The white lists created later by the individual distributions were insufficiently maintained, and ultimately costly. Now, according to Sharp; it is turned out , that the devices were not always responsible for the disruption. According to USB specifications of roothub must send at least 20 milliseconds, the signal to wake up a device (TDRSMDN). Then the status of a device is placed in the hub to Active. Have access to the Linux kernel and software on a device that has yet to be made a break of 10 milliseconds (TRSMRCY). The TRSMRCY value is defined by the USB 2.0 specification, however, neither a read nor a maximum, but a minimum value. Although the xHCI driver of the Linux kernel, the kernel activates immediately hub daemon (khubd), is the changing status of a device, but only after 20 ms free (TDRSMDN). This means that a device can be longer in a Resume mode than that specified in TRSMRCY time. The software then attempts to 10 milliseconds to access the device, although it is still in sleep mode, which in turn can cause the USB device is disconnected or, for example, writes cannot be done. The error relates to devices that connect to the xHCI hub. Such problems with the EHCI hub and the USB stack of the Linux kernel does not exist. After Sharp's first analyzes some USB devices have a TRSMRCY-time of up to 17 milliseconds. 8 percent of the tested devices TRSMRCY-values are about 10 milliseconds. A first patch Sharp has already submitted. But it was still not a "real fix". Immediately they work on a better patch. But you see "light at the end of the tunnel" and that the problems would be resolved with the USB power management in the Linux kernel soon. If everything goes according to plan, the repairs should already be included in the next kernel version 3.11, which should appear early September 2013.