USBEHCI.SYS bug with high-bandwidth interrupt endpoints

From: Aaron (hank_gurdjieff_at_yahoo.com)
Date: 10/25/04 

Date: 25 Oct 2004 10:37:18 -0700

A few weeks ago, I was investigating USB 2.0 high-bandwidth interrupt
transfers. According to the USB 2.0 specification, section 5.9, an
interrupt endpoint is capable of transmitting 24.5 MB/s by specifying
three transactions per microframe with a maximum packet size of 1024
bytes in the endpoint descriptor. Despite the fact that my interrupt
endpoint was specifying three transactions per microframe in the
wMaxPacketSize field, I was only ever seeing one transaction per
microframe with my USB analyzer. This was further confirmed by my
performance test, which was returning 8 MB/s, that is, the fastest
rate that can be achieved with a packet size of 1K and a bInterval
value corresponding to 125 microseconds.

What appears to be happening, as I will describe, is that the
Microsoft USB driver is disregarding the multiplier bits for interrupt
endpoints. I understand this is not a problem with isochronous
endpoints, which also enjoy the same benefit. I am pleased to report,
however, that I have discovered a workaround to get three transactions
per microframe and thus the full 24.5 MB/s throughput I originally
desired. It is not for the faint of heart, however. I was lucky enough
to have access to SoftICE, which helped me to discover the workaround
and makes the procedure easy, but currently the procedure is manual.
It could potentially be automated, but would be more involved.

(For reference, my host is a Dell-branded 2.5GHz P4 running Microsoft
XP Service Pack 1a and the target device is a Cypress FX2 development
board. The host controller is an Intel 82801DB/DBM.)

After plugging in my device, I used the 'usb -schedule' command in
SoftICE to view the periodic frame list structure of the EHCI
controller to which my device was attached. Each of the periodic frame
list entries pointed to a QH (queue head) structure, which is expected
behaviour per the EHCI specification for interrupt transfers. Each of
the entires in the periodic frame list pointed to the very same QH
structure; that is, each of the pointers pointed to the same block of
memory. However, the multiplier field (DWORD 2, bits 31:30) of the QH
structure did not reflect what I had set on the device's interrupt
endpoint descriptor. The multiplier bits were indicating one
transaction per microframe (00b), when they should have indicated
three transactions per microframe (10b).

Fortunately, SoftICE displays the address of the QH structure. Since
all the periodic frame list entries pointed to the same address, I
used the 'phys' command in SoftICE to translate the linear address of
the QH structure to a virtual address where it resided in system RAM.
With this address, I could open up a data window and manually change
the two bits in question from 00b to 10b. Now issuing the 'usb
-schedule' command showed the multiplier field to be 3 instead of 1.

When I returned to Windows and ran my performance test, success!--very
close to 24.5 MB/s. The USB analyzer showed three transactions per
microframe, except in those cases where the host NAKed one of the data
frames (in which case the USB specification says that the host will
not reattempt the transfer until the beginning of the next
microframe). It appears that these bits not getting set correctly is a
Microsoft bug, probaby in USBEHCI.SYS, though I am grasping at straws
here. I tried to set some conditional breakpoints in USBEHCI.SYS and
saw parts of the QH structure being initialized, but never did
conclusively find out where Microsoft is or is not setting those bits
(though I did see accesses to the DWORD in question).

I hope this helps other people attempting to use high-bandwidth
interrupt transfers with Windows. If this is in fact a bug in
USBEHCI, I would definitely appreciate seeing a KB article on it. I
searched MSDN high and low while trying to get it to work and found
nothing.

Relevant Pages

  • Re: assessing winusb potential
    ... So it appears in the USB interrupt handler that there is an event for ... My device writes data to the IN endpoint. ... USB hardware sends the data. ... endpoint and what is the significance of the IN data interrupt. ...
    (microsoft.public.development.device.drivers)
  • Re: assessing winusb potential
    ... So it appears in the USB interrupt handler that there is an event ... sent by the host. ... My device writes data to the IN endpoint. ... USB hardware sends the data. ...
    (microsoft.public.development.device.drivers)
  • Re: USB 2.0 High Bandwidth Iso
    ... I am having an issue with a USB 2.0 high-bandwidth iso endpoint. ... meaning 1024 bytes with 3 transfers per microframe. ... consume 3 such packets. ...
    (microsoft.public.development.device.drivers)
  • Re: EZ-USB and VIA host controller
    ... endpoint 0x01 packet size = 1024, ... The FX2 only supports bulk and interrupt for endpoint 1 ... bytes at a time), and for interrupt, the packet size is 64. ... A bulk pipe on USB 2.0 MUST have a max packet size of 512. ...
    (microsoft.public.development.device.drivers)
  • Re: Once more VIA VT6212 USB Chip Problem
    ... I checked the interrupt init and I can see they are all set. ... I tried my image on this board and USB works fine!! ... Bus 0, Device 1, Function 0 ... is found for following PCI Device ...
    (microsoft.public.windowsce.platbuilder)
Loading