Where my kernel patches live until they're accepted into the mainline kernel... or die of old age.

September 26, 2006

Previous versions of patches may be found on the old patch page.

USB patches

The ehci scheduler

summary

A new bandwidth scheduler for EHCI (USB 2.0) controllers. This patch addresses 'cannot submit datapipe: error -28' (out of bandwidth), at least some number of 'error -71' (protocol error) and various performance/correctness problems with EHCI USB 2.0 controllers, USB 2.0 hubs when plugged into an EHCI controller, and USB 1.1 devices plugged into USB 2.0 hubs.

This is a different patch than the "improved transaction translator support" patch offered in the 2.6.18 kernel. These two schedulers are mutually exclusive; the 2.6.18 version of my patch removes the mainline 'improvements' because it eliminates all the old mainline scheduler code. Just so you know.

download

bugs

Please report bugs to xiphmont@gmail.com. This patch adds a runtime module option ['modprobe ehci-sched sched_verbose=1'] which dumps a ton of debugging information to the syslog (use this only for debugging; do not use it on a production machine as it will cause isoch loss of sync conditions). If possible, send a copy of this log along with a bug report.

warnings

This is bleeding edge code that has not yet been reviewed in detail by the kernel team and has not yet seen wide testing. Although it addresses several performance and capability problems in the EHCI driver, it is a large, complex patch that is certainly full of new bugs that haven't been found yet. Do not trust this code in unsupervised production as yet. Keep it away from pets and children.

This code also fixes overrun/underrun detection, which existed in the old scheduler but was non-functional due to bugs. Unfortunately, this triggers a preexisting bug in the USB audio driver. Applications such as sox, xmms, and 'play' (a script that actually calls sox) will often abort immediately with 'error -45'.

See the next patch for a fix for usbaudio.

detailed background

Back in the day, I used two eMagic eight-channel capture/playback devices on a PowerBook running Linux to make field recordings. One nice thing about old PowerBooks was that although they only had USB 1.1 ports, each was on an fully independent controller. So, even though each eMagic box required the full bandwidth of a single USB 1.1 bus, I could use two on the same machine because the PowerBook had two full controllers.

After five years, I retired the PowerBook and replaced it with a ThinkPad with two USB 2.0 ports. I didn't think this would be a problem-- after all, USB 2.0 supports 480Mbps while USB 1.1 only supported 12Mbps; using two eMagic boxes on the ThinkPad, I thought, would not be a problem. Wrong, wrong, wrong.

USB 2.0 allows use of USB 1.0 (low speed) and USB 1.1 (full speed) devices as part of a USB 2.0 (high speed) system in two ways:

  1. A USB 2.0 host controller is paired with a USB 1.1 compliant 'companion controller'; when plugging a FS (full speed) or LS (low speed) device directly into a USB 2.0 controller it hands them off to the companion. In this case, the device is actually driven by a UHCI or OHCI controller, even though it's plugged into a 'USB 2.0' port.
  2. FS/LS devices may also be plugged into a USB 2.0 hub; this situation uses what is called a 'Transaction Translator' (TT) in the hub to translate USB 2.0 transactions into USB 1.1 transactions on that port. This is where most of the complication occurs; USB passes the responsibility for budgeting and driving the translation machinery on the USB 2.0 controller, and EHCI USB controllers pass the responsibility on the software driver.
When I plug an eMagic device directly into the ThinkPad, it is assigned to the USB 1.1 companion controller. The ThinkPad has two USB 2.0 ports but only one companion controller shared between them, so I could only use one eMagic device at a time.

So what about a hub? USB 2.0 hubs come in two flavors; single-TT and multi-TT. Most hubs are single-TT, which means one translator is shared between all the ports; the 12Mbps of full-speed bandwidth is shared between all devices plugged into it. Multi-TT hubs (such as the Belkin TetraHub model F5U231, which is highly recommended) have a seperate TT for each port which means you can have 480Mbps to/from the hub, as well as full 12Mbps to/from each USB 1.1 device plugged into it. Perfect! Now, I thought, I can have *four* of these wonderful little sampling boxes running on one USB 2.0 bus! Unfortunately, I was wrong again.

Because EHCI is rather overcomplicated, writing a good scheduler is no simple task. Even though EHCI support in Linux is now several years old, the scheduler [as of Linux 2.6.17] is still mostly a placeholder waiting to be filled in. It is incapable of using either 2.0 or 1.1 bandwidth effectively although you notice it more with 1.1 devices because they're generally pushing bandwidth limits harder. It was enough for keyboards, mice and 'bulk' devices, and if you were lucky, it could barely handle some simple stereo audio devices.

Most of the problems in the EHCI scheduler up until now have to do with managing the Transaction Translator mechanism; This is why, for example, multichannel USB audio devices (which are usually USB 1.1 devices) work when plugged directly into a computer but not when plugged into a USB 2.0 hub. When you plug a device into an EHCI controller and get a an 'error -28' when trying to use it, the EHCI scheduler is what's at fault.

USB audio playback fix

download

Please report bugs to xiphmont@gmail.com.

summary

The new ehci bandwidth scheduler (above) now correctly reports schedule sync errors to the USB audio driver; unfortunately, this trips a previously hidden bug in USB audio playback setup. Usbaudio pushes out a packet of silence during device preparation before real audio begins to flow. If there is a long delay between playback hardware preparation and actual playback, usbaudio will see a harmless loss of sync error (which couldn't happen before as the loss of sync detection was broken), causing usbaudio to abort playback just as it's starting. This bug is the source of 'error -45: unknown'.

The patch corrects the handling of -EL2NSYNC during playback startup. You definitely want this patch if you're using the ehci-scheduler patch above.

warnings

This patch is only useful when used with the new ehci-scheduler patch above.

Although this is a small patch and almost certainly harmless, it has not yet been reviewed in detail by the kernel team. Do not trust this code in unsupervised production as yet. Do not use this patch around power tools or high voltage equipment.

SGIO block layer patch (fixes SG_DXFER_TO_FROM_DEVICE handling for ATAPI drives)

download

Please report bugs to xiphmont@gmail.com.

summary

The SG_IO interface is the most recent uniform interface for sending raw commands to SCSI/MMC devices, which include SCSI and ATAPI cdrom drives. Inside the kernel, SG_IO is seperately implemented for SCSI and ATAPI block layers; unfortunately, there's an error in the block layer that mis-interprets the SG_DXFER_TO_FROM_DEVICE value as a write operation when it is actually a read operation. This will cause reads using the SG_DXFER_TO_FROM_DEVICE directive to fail on ATAPI (IDE) cdrom drives. SCSI cdrom drives are not affected by this bug.

warnings

None; this patch is safe to apply to 2.6.16, 2.6.17 and pre-2.6.18 kernels. As this patch is likely to be adopted by the kernel maintainers soon, check to see if this patch has already been applied to recent kernel downloads (use patch --dry-run to check).

Monty <xiphmont@gmail.com>