uhci.c Fix for an UHCI error -EILSEQ on a VIA Controller during BULK IN transfer

uhci.c Fix for an UHCI error -EILSEQ on a VIA Controller during BULK IN transfer

[Karsten Wiese]

hi Maintainers,

I'm developing a driver for the tascam us428 audio/midi controller. it works 
on intel USB BX440 Host controller, but has problems with one VIA USB 
Controller (others unknown).
kernel is 2.4.21. module is uhci. (usb-uhci behaves similarly.)

the error shows up like this:
uhci.c: uhci_result_interrupt/bulk() failed with status 440000
[cf7a50c0] link (0f7a5092) element (02ecf1e0)
  0: [c2ecf1e0] link (00000001) e0 IOC Stalled CRC/Timeo Length=7ff MaxLen=3f 
DT0 EndPt=6 Dev=2, PID=69(IN) (buf=0e01cc54)

the FIX is to initialise status in uhci_submit_bulk() like this:
/* 3 errors if there is a timeout else 0; 
   UHCI Spec says: 0 == unlimited errors
   VIA-chip 1106:3038 needs 0 for urbs that should not timeout!
   */
status = TD_CTRL_ACTIVE | ((urb->timeout ? 3 : 0) << TD_CTRL_C_ERR_SHIFT);

the urb in question should stay in the queue until the extern midi device 
submits an event.
It seams intels HC ignores the spec, while Via's obeys here?

Please apply the fix in uhci.c, usb-uhci.c and for 2.6!

thanks, karsten

some details:

lspci -n for the VIA Board:
00:00.0 Class 0600: 1106:0691 (rev c4)
00:01.0 Class 0604: 1106:8598
00:07.0 Class 0601: 1106:0686 (rev 40)
00:07.1 Class 0101: 1106:0571 (rev 06)
00:07.2 Class 0c03: 1106:3038 (rev 1a)
00:07.3 Class 0c03: 1106:3038 (rev 1a)
00:07.4 Class 0680: 1106:3057 (rev 40)
00:07.5 Class 0401: 1106:3058 (rev 50)
00:09.0 Class 0100: 1000:000f (rev 03)
00:0a.0 Class 0200: 8086:1229 (rev 08)
01:00.0 Class 0300: 1002:4c42 (rev dc)

lspci -v for the VIA Board:
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] 
(rev c4)
        Flags: bus master, medium devsel, latency 8
        Memory at e0000000 (32-bit, prefetchable) [size=32M]
        Capabilities: <available only to root>

00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x 
AGP] (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: e2000000-e3ffffff
        Capabilities: <available only to root>

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 
40)
        Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
        Flags: bus master, stepping, medium devsel, latency 0
        Capabilities: <available only to root>

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus 
Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
        Subsystem: VIA Technologies, Inc. VT8235 Bus Master ATA133/100/66/33 
IDE
        Flags: bus master, medium devsel, latency 32
        I/O ports at d000 [size=16]
        Capabilities: <available only to root>

00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 
[UHCI])
        Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
        Flags: bus master, medium devsel, latency 32, IRQ 5
        I/O ports at d400 [size=32]
        Capabilities: <available only to root>

00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 
[UHCI])
        Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
        Flags: bus master, medium devsel, latency 32, IRQ 5
        I/O ports at d800 [size=32]
        Capabilities: <available only to root>

00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
        Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
        Flags: medium devsel, IRQ 9
        Capabilities: <available only to root>

00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 
Audio Controller (rev 50)
        Subsystem: VIA Technologies, Inc. VT82C686 AC97 Audio Controller
        Flags: medium devsel, IRQ 10
        I/O ports at dc00 [size=256]
        I/O ports at e000 [size=4]
        I/O ports at e400 [size=4]
        Capabilities: <available only to root>

00:09.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 03)
        Flags: bus master, medium devsel, latency 134, IRQ 11
        I/O ports at e800 [size=256]
        Memory at e4202000 (32-bit, non-prefetchable) [size=256]
        Memory at e4201000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=64K]

00:0a.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
        Subsystem: Intel Corp. EtherExpress PRO/100+ Management Adapter
        Flags: bus master, medium devsel, latency 32, IRQ 10
        Memory at e4200000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at ec00 [size=64]
        Memory at e4000000 (32-bit, non-prefetchable) [size=1M]
        Expansion ROM at <unassigned> [disabled] [size=1M]
        Capabilities: <available only to root>

01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage LT Pro AGP-133 
(rev dc) (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc Rage LT Pro AGP 2X
        Flags: bus master, stepping, medium devsel, latency 32, IRQ 5
        Memory at e2000000 (32-bit, non-prefetchable) [size=16M]
        I/O ports at c000 [size=256]
        Memory at e3020000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: <available only to root>




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: uhci.c Fix for an UHCI error -EILSEQ on a VIA Controller during BULK IN transfer

[Alan Stern]

On Fri, 22 Aug 2003, Karsten Wiese wrote:

> hi Maintainers,
> 
> I'm developing a driver for the tascam us428 audio/midi controller. it works 
> on intel USB BX440 Host controller, but has problems with one VIA USB 
> Controller (others unknown).
> kernel is 2.4.21. module is uhci. (usb-uhci behaves similarly.)
> 
> the error shows up like this:
> uhci.c: uhci_result_interrupt/bulk() failed with status 440000
> [cf7a50c0] link (0f7a5092) element (02ecf1e0)
>   0: [c2ecf1e0] link (00000001) e0 IOC Stalled CRC/Timeo Length=7ff MaxLen=3f 
> DT0 EndPt=6 Dev=2, PID=69(IN) (buf=0e01cc54)
> 
> the FIX is to initialise status in uhci_submit_bulk() like this:
> /* 3 errors if there is a timeout else 0; 
>    UHCI Spec says: 0 == unlimited errors
>    VIA-chip 1106:3038 needs 0 for urbs that should not timeout!
>    */
> status = TD_CTRL_ACTIVE | ((urb->timeout ? 3 : 0) << TD_CTRL_C_ERR_SHIFT);
> 
> the urb in question should stay in the queue until the extern midi device 
> submits an event.
> It seams intels HC ignores the spec, while Via's obeys here?
> 
> Please apply the fix in uhci.c, usb-uhci.c and for 2.6!

This proposed change is incorrect.

In general urb->timeout is almost never set.  It's only supported by the
UHCI drivers, so device drivers can't rely on it.  Nevertheless,
practically every TD needs to have the 3-error limit, not unlimited
errors.

A properly working HC will not decrease the error count if the device 
replies correctly (with a NAK if no data is available).  Only if the 
device fails to reply at all, or sends an illegal reply, will the error 
count be decremented.

The error message shown above has CRC/Timeout set for an IN packet.  This 
means that the HC either thinks the device didn't reply at all -- not even 
with a NAK -- or sent data with an invalid checksum.  If that's what 
actually happened then the HC is right to call it an error.  If that's not 
what happened then the VIA UHCI chip has a serious flaw, one that the 
driver can't compensate for.

Note that urb->timeout means something completely different from the UHCI
Timeout error.  urb->timeout puts a limit on long the device may continue
to NAK -- typically on the order of seconds.  The UHCI timeout is a limit
on how long the device can delay before returning a handshake token -- its
value is given in the USB specification, on the order of a few
microseconds.

Alan Stern



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: uhci.c Fix for an UHCI error -EILSEQ on a VIA Controller during BULK IN transfer

[Johannes Erdfelt]

On Fri, Aug 22, 2003, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 22 Aug 2003, Karsten Wiese wrote:
> 
> > hi Maintainers,
> > 
> > I'm developing a driver for the tascam us428 audio/midi controller. it works 
> > on intel USB BX440 Host controller, but has problems with one VIA USB 
> > Controller (others unknown).
> > kernel is 2.4.21. module is uhci. (usb-uhci behaves similarly.)
> > 
> > the error shows up like this:
> > uhci.c: uhci_result_interrupt/bulk() failed with status 440000
> > [cf7a50c0] link (0f7a5092) element (02ecf1e0)
> >   0: [c2ecf1e0] link (00000001) e0 IOC Stalled CRC/Timeo Length=7ff MaxLen=3f 
> > DT0 EndPt=6 Dev=2, PID=69(IN) (buf=0e01cc54)
> > 
> > the FIX is to initialise status in uhci_submit_bulk() like this:
> > /* 3 errors if there is a timeout else 0; 
> >    UHCI Spec says: 0 == unlimited errors
> >    VIA-chip 1106:3038 needs 0 for urbs that should not timeout!
> >    */
> > status = TD_CTRL_ACTIVE | ((urb->timeout ? 3 : 0) << TD_CTRL_C_ERR_SHIFT);
> > 
> > the urb in question should stay in the queue until the extern midi device 
> > submits an event.
> > It seams intels HC ignores the spec, while Via's obeys here?
> > 
> > Please apply the fix in uhci.c, usb-uhci.c and for 2.6!
> 
> This proposed change is incorrect.
> 
> In general urb->timeout is almost never set.  It's only supported by the
> UHCI drivers, so device drivers can't rely on it.  Nevertheless,
> practically every TD needs to have the 3-error limit, not unlimited
> errors.
> 
> A properly working HC will not decrease the error count if the device 
> replies correctly (with a NAK if no data is available).  Only if the 
> device fails to reply at all, or sends an illegal reply, will the error 
> count be decremented.
> 
> The error message shown above has CRC/Timeout set for an IN packet.  This 
> means that the HC either thinks the device didn't reply at all -- not even 
> with a NAK -- or sent data with an invalid checksum.  If that's what 
> actually happened then the HC is right to call it an error.  If that's not 
> what happened then the VIA UHCI chip has a serious flaw, one that the 
> driver can't compensate for.
> 
> Note that urb->timeout means something completely different from the UHCI
> Timeout error.  urb->timeout puts a limit on long the device may continue
> to NAK -- typically on the order of seconds.  The UHCI timeout is a limit
> on how long the device can delay before returning a handshake token -- its
> value is given in the USB specification, on the order of a few
> microseconds.

I agree with your analysis.

What I am curious about is why this does fix the problem for Karsten? He
only has problems with VIA and not Intel.

It could be some sort of weird device compability issue with VIA
chipsets, but I can't imagine what the problem really could be.

I hate that UHCI doesn't differentiate between a CRC error and a
timeout. I'd be curious to know what the actual problem is to see if we
could develop a workaround.

Karsten, you wouldn't happen to have a USB bus analyzer, would you?

JE



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel