NetBSD Problem Report #21547

Received: (qmail 22580 invoked by uid 605); 12 May 2003 06:21:52 -0000
Message-Id: <200305120621.h4C6LmDB004136@guava.araneus.fi>
Date: Sun, 11 May 2003 23:21:48 -0700 (PDT)
From: gson@gson.org
Sender: gnats-bugs-owner@netbsd.org
Reply-To: gson@gson.org
To: gnats-bugs@gnats.netbsd.org
Subject: Reading short block from ugen device can lock up USB
X-Send-Pr-Version: 3.95

>Number:         21547
>Category:       kern
>Synopsis:       Reading short block from ugen device can lock up USB
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 12 06:22:00 +0000 2003
>Closed-Date:    
>Last-Modified:  Wed Jan 04 06:30:48 +0000 2023
>Originator:     Andreas Gustafsson
>Release:        NetBSD 1.6L
>Organization:
>Environment:
System: NetBSD guava.araneus.fi 1.6L NetBSD 1.6L (GUAVAMP) #0: Sun Jan 12 16:57:58 PST 2003 gson@guava.araneus.fi:/usr/src/sys/arch/i386/compile/GUAVAMP i386
Architecture: i386
Machine: i386
>Description:

I am trying to test an experimental USB device under NetBSD.  The
device periodically sends 64-byte packets over a bulk endpoint
(endpoint 1).  Reading the packets using "dd if=/dev/ugen0.01 bs=64
count=1" works fine.

If I specify a smaller block size like "dd if=/dev/ugen0.01 bs=63
count=1", I get an I/O error after a five-second timeout.  The I/O
error itself is expected, but the error also has the unexpected and
more serious effect of making any subsequent attempt to use USB fail,
even after unplugging the USB device.  No matter what I try to plug
into the USB port (after unplugging the device with which the I/O
error occurred), I get

  usbd_new_device: addr=2, getting first desc failed
  uhub_explore: usb_new_device failed, error=TIMEOUT
  uhub0: device problem, disabling port 1

The machine has two USB ports, and they both stop working.  The only
way to clear up the problem is to reboot.

The dmesg output for the host USB hardware is as follows:

  uhci0 at pci0 dev 7 function 2: VIA Technologies VT83C572 USB Controller (rev. 0x06)
  uhci0: interrupting at irq 11
  usb0 at uhci0: USB revision 1.0
  uhub0 at usb0
  uhub0: VIA Technologies UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
  uhub0: 2 ports with 2 removable, self powered

>How-To-Repeat:

See above.  Although the USB device in question is not available
commercially, the issue may be reproducible using other bulk devices,
or if necessary, I can make the device available to anyone who is
serious about looking into the issue.

>Fix:
>Release-Note:
>Audit-Trail:

From: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: kern/21547: Reading short block from ugen device can lock up USB
Date: Mon, 12 May 2003 20:05:17 -0700 (PDT)

 A bit more info...

 The problem does not occur on an i386 running NetBSD 1.6P with

   ohci0 at pci0 dev 7 function 4:
   Advanced Micro Devices AMD756 USB Host Controller (rev. 0x06)

 It also does not occur on an i386 running NetBSD 1.6B with

   uhci0 at pci0 dev 7 function 2:
   Intel 82371AB USB Host Controller (PIIX4) (rev. 0x01)

 Therefore, I suspect this is specifically an issue with the VIA
 VT83C572.  It could be the same bug as kern/11018.
 -- 
 Andreas Gustafsson, gson@gson.org
Responsible-Changed-From-To: kern-bug-people->mycroft 
Responsible-Changed-By: mycroft 
Responsible-Changed-When: Sat Jun 26 20:13:14 UTC 2004 
Responsible-Changed-Why:  
. 
State-Changed-From-To: open->feedback 
State-Changed-By: mycroft 
State-Changed-When: Wed Jul 7 21:27:10 UTC 2004 
State-Changed-Why:  
Please try the failing case with -current with ohcidebug=15 (decimal) and send 
me the output for analysis. 

From: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@gnats.netbsd.org
Cc: mycroft@netbsd.org
Subject: Re: kern/21547
Date: Thu, 8 Jul 2004 14:22:54 +0300 (EEST)

 mycroft@netbsd.org writes:
 > Please try the failing case with -current with ohcidebug=15 (decimal) and send
 > me the output for analysis.

 I think you mean uhcidebug=15 - the controller exhibiting the lockups
 is an uhci, not an ohci.

 Unfortunately, I don't have access to the necessary hardware right now
 because I'm in the middle of a transatlantic move, but I do have
 some other information I can give you.

 First of all, I ran some tests of my own with an elevated uhcidebug
 level shortly after filing the PR.  These tests showed that the uchi
 reports a "babble" condition shortly before the lockup.  This does
 make some sense, since the device is in fact sending a longer packet
 than the driver is lead to expect based on the length argument to the
 read() on the ugen device.

 I wonder if the fact that a user process can cause such a low-level
 USB protocol error shouldn't be considered a bug in the ugen and/or
 uhci driver - perhaps the driver should always give the uhci a buffer
 large enough for the maximum USB packet size regardless of the length
 passed to read()?

 In any case, that is a separate issue from the fact that when a babble
 condition *does* occur, the controller locks up.  Since filing the PR,
 I have corresponded with Alan Stern <stern@rowland.harvard.edu> who
 tells me that there is a known bug in the VIA uhci implementation
 where a babble condition which will cause the controller to stop.
 Supposedly, setting bit 0x40 in byte 0x40 of the controller's PCI
 configuration space should cause it not to do that.  Quoting Alan:

 > This bit is always supposed to be turned on by default,
 > but some chipset/BIOS combinations don't do so.  The original reason for
 > making the controller stop is obscure; it may have been a
 > misinterpretation of section 8.7.4 in the USB specification -- people at
 > VIA may use the word "port" to refer to an entire controller.
 >
 > Having said that, I've gotten reports from other people that setting this
 > configuration bit does not prevent their controllers from shutting down
 > after a babble.  It may depend on the revision number of the chip; I just
 > don't know.
 >
 > Once the controller has stopped, the only way to get it going again is the
 > HCRESET bit in the USBCMD register.  Unforunately this will also cause a
 > logical disconnect on all the ports, but there's no other choice.

 -- 
 Andreas Gustafsson, gson@gson.org
Responsible-Changed-From-To: mycroft->kern-bug-people
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Sun, 03 Sep 2006 01:14:31 +0000
Responsible-Changed-Why:
Back to role account, mycroft doesn't have commit access any longer.


State-Changed-From-To: feedback->open
State-Changed-By: gson@NetBSD.org
State-Changed-When: Wed, 14 May 2008 12:36:45 +0000
State-Changed-Why:
Feedback was provided.


State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 31 Dec 2022 04:48:48 +0000
State-Changed-Why:
how does this look compared to 2004? it's been a while and vast numbers
of fixes have gone into the usb code...


From: Andreas Gustafsson <gson@gson.org>
To: dholland@NetBSD.org
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/21547 (Reading short block from ugen device can lock up USB)
Date: Tue, 3 Jan 2023 17:41:05 +0200

 dholland@NetBSD.org wrote:
 > how does this look compared to 2004? it's been a while and vast numbers
 > of fixes have gone into the usb code...

 Sadly, the bug is still there.  I no longer have the PC that it
 originally affected, but my main USB test machine contains multiple
 PCI cards with different USB controller chips, and one of them happens
 to be the affected VIA VT83C572.  I booted a NetBSD-current/amd64
 kernel built from CVS source date 2023.01.03.00.00.45, and it still
 behaves as reported in the original PR.

 To be precise, this card has four ports and two UHCI companion
 controllers each shared by two ports, and a short read on one of the
 ports causes that port and the one sharing the same UCHI companion
 controller to lock up, but the other two ports remain functional until
 a short read is done on one of them, too.

 The bug is of little practical significance at this point as the
 VT83C572 is thoroughly obsolete by now, but in any case, the offer I
 made in the original PR to ship a USB device suitable for reproducing
 the bug to anyone serious about looking into it still stands.
 VT83C572 USB controller PCI cards can still be found on eBay.
 -- 
 Andreas Gustafsson, gson@gson.org

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Wed, 04 Jan 2023 06:30:48 +0000
State-Changed-Why:
time doesn't fix everything.

(sigh)


>Unformatted:

Home	PR Database Search