Monty's kernel Patch Page
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.
The ehci scheduler
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.
- Improved use of periodic bandwidth for low, full and high speed transfers
- FSTN and sITD frame spanning support
- Lower worst-case per-submission CPU usage; all scheduling decisions are made up-front when an endpoint is started
- Reliable underrun detection (present but broken in old scheduler)
- Delayed periodic schedule shutdown; reduces the liklihood and severity of underruns
- Guaranteed bandwidth to isochronous streams once stream is started; spurious ENOSPC no longer possible.
- Strict overlapped transaction ordering
Please report bugs to email@example.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.
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
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.
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
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:
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.
- 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.
- 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.
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
Please report bugs to firstname.lastname@example.org.
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
This patch is only useful when used with the new ehci-scheduler patch
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)
Please report bugs to email@example.com.
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.
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).