kern/37884: nvidia ehci umass

[jakllsch%kollasch.net@localhost]

>Number:         37884
>Category:       kern
>Synopsis:       some umass devices stall on nvidia ehci controller
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 27 16:10:00 +0000 2008
>Originator:     Jonathan A. Kollasch
>Release:        NetBSD 4.99.31
>Organization:
        
>Environment:
System: NetBSD wormulon.kollasch.net 4.99.31 NetBSD 4.99.31 (WORMULON) #27: Sat 
Jan 5 20:17:13 UTC 2008 
root%wormulon.kollasch.net@localhost:/usr/src/sys/arch/amd64/compile/WORMULON 
amd64
Architecture: x86_64
Machine: amd64
>Description:

Either Nvidia EHCI controllers, or our ehci(4), has a quirk in it that
causes some umass devices to stall forever.

>How-To-Repeat:

Attach almost any USB 2.0 Flash Drive to a nvidia EHCI controller.
Try to use a file system on it.  Watch it permanantly stall.

USB 2.0 to IDE/SATA bridges (when used with real hard drives)
do not exhibit this issue, at least not with easily repeatable
chances.  When I used a PL-2507 USB 2.0 <-> PATA umass bridge
with a UDMA/66 CompactFlash card, it stalled too.

Depending on the method of access to the device, processes
accessing the device stall in biowait (cp) or physio (dd) states.

This has occured for me on a nforce3 board,
as well as a nforce4 board.

In the same boxes a NEC or VIA EHCI add-on card works fine.

Also, the nvidia OHCI does not exhibit this issue,
but USB 1.1 is slower than a glacier.

>Fix:

I wish I knew.

Maybe a race condition?