NetBSD Problem Report #42884

From martijnb@atlas.ipv6.stack.nl  Thu Feb 25 20:53:10 2010
Return-Path: <martijnb@atlas.ipv6.stack.nl>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 4FFCC63B11D
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 25 Feb 2010 20:53:10 +0000 (UTC)
Message-Id: <20100225205236.4B6DA388D2@atlas.ipv6.stack.nl>
Date: Thu, 25 Feb 2010 21:52:36 +0100 (CET)
From: martijn.van.buul@gmail.com
Reply-To: martijn.van.buul@gmail.com
To: gnats-bugs@gnats.NetBSD.org
Subject: USB hubs not fully functional
X-Send-Pr-Version: 3.95

>Number:         42884
>Category:       kern
>Synopsis:       USB hubs don't recognise device connects/disconnects
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 25 20:55:00 +0000 2010
>Last-Modified:  Mon Mar 01 11:45:01 +0000 2010
>Originator:     martijn.van.buul@gmail.com
>Release:        NetBSD 5.99.24
>Organization:

>Environment:


System: NetBSD atlas.ipv6.stack.nl 5.99.24 NetBSD 5.99.24 (GENERIC) #0: Sat Feb 13 11:57:38 CET 2010 martijnb@atlas:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	This problem also occurs on NetBSD 5.0.1 and 5.0.2.

	External USB hubs (not root-hubs) seem to be partially broken. They
	do not recognise device connects and disconnect; only devices 
	connected when the hub itself is connected are recognised. I have
	tried 3 different hubs, of different make and models, with both single
	and multiple transaction translators, and they all
	have the same behaviour. Both USB1 and USB2 devices are affected.

	Upon connection of an unpopulated hub everything looks OK:

uhub9 at uhub5 port 1: vendor 0x04b4 product 0x6560, class 9/0, rev 2.00/0.09, addr 2
uhub9: multiple transaction translators
uhub9: 4 ports with 4 removable, self powered

	However, connecting a device doesn't register. One of the hubs I 
	tried has a "link activity" indicator of some sorts; it doesn't
	light up. Disconnecting it, and reconnecting it with a device 
	(in this case: a mouse) already connecting results in the
	detection of said mouse:

uhub9: detached
uhub9: at uhub5 port 1 (addr 2) disconnected
uhub9 at uhub5 port 2: vendor 0x04b4 product 0x6560, class 9/0, rev 2.00/0.09, addr 2
uhub9: multiple transaction translators
uhub9: 4 ports with 4 removable, self powered
uhidev3 at uhub9 port 2 configuration 1 interface 0
uhidev3: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 3, iclass 3/1
ums1 at uhidev3: 3 buttons and Z dir
wsmouse1 at ums1 mux 0

	Now the aforementioned "link led" *does* light up, and the mouse 
	seems to work OK. Unplugging the mouse doesn't result in a driver 
	detach though; reconnecting it leaves it dead. The mouse doesn't
	get detached until the entire hub gets unplugged:

wsmouse1: detached
ums1: detached
uhidev3: detached
uhidev3: at uhub9 port 2 (addr 3) disconnected
uhub9: detached
uhub9: at uhub5 port 2 (addr 2) disconnected

	Root hubs seem to work fine. Unfortunately, I don't have a USB1 
	hub at hand; if required I can see if I can find one. The machine
	has a Asus M2A74-AM motherboard, with an AMD 740G chipset. Relevant 
	parts of dmesg:

ohci0 at pci0 dev 18 function 0: vendor 0x1002 product 0x4397 (rev. 0x00)
ohci0: interrupting at ioapic0 pin 16
ohci0: OHCI version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
ohci1 at pci0 dev 18 function 1: vendor 0x1002 product 0x4398 (rev. 0x00)
ohci1: interrupting at ioapic0 pin 16
ohci1: OHCI version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
ehci0 at pci0 dev 18 function 2: vendor 0x1002 product 0x4396 (rev. 0x00)
ehci0: applying AMD SB600/SB700 USB freeze workaround
ehci0: interrupting at ioapic0 pin 17
ehci0: dropped intr workaround enabled
ehci0: BIOS has given up ownership
ehci0: EHCI version 1.0
ehci0: companion controllers, 3 ports each: ohci0 ohci1
usb2 at ehci0: USB revision 2.0
ohci2 at pci0 dev 19 function 0: vendor 0x1002 product 0x4397 (rev. 0x00)
ohci2: interrupting at ioapic0 pin 18
ohci2: OHCI version 1.0, legacy support
usb3 at ohci2: USB revision 1.0
ohci3 at pci0 dev 19 function 1: vendor 0x1002 product 0x4398 (rev. 0x00)
ohci3: interrupting at ioapic0 pin 18
ohci3: OHCI version 1.0, legacy support
usb4 at ohci3: USB revision 1.0
ehci1 at pci0 dev 19 function 2: vendor 0x1002 product 0x4396 (rev. 0x00)
ehci1: applying AMD SB600/SB700 USB freeze workaround
ehci1: interrupting at ioapic0 pin 19
ehci1: dropped intr workaround enabled
ehci1: BIOS has given up ownership
ehci1: EHCI version 1.0
ehci1: companion controllers, 3 ports each: ohci2 ohci3
usb5 at ehci1: USB revision 2.0
[..]
ohci4 at pci0 dev 20 function 5: vendor 0x1002 product 0x4399 (rev. 0x00)
ohci4: interrupting at ioapic0 pin 18
ohci4: OHCI version 1.0, legacy support
usb6 at ohci4: USB revision 1.0
[..]
uhub0 at usb0: vendor 0x1002 OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
uhub1 at usb1: vendor 0x1002 OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
uhub2 at usb2: vendor 0x1002 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: 6 ports with 6 removable, self powered
uhub3 at usb3: vendor 0x1002 OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 3 ports with 3 removable, self powered
uhub4 at usb4: vendor 0x1002 OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub4: 3 ports with 3 removable, self powered
uhub5 at usb5: vendor 0x1002 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub5: 6 ports with 6 removable, self powered
uhub6 at usb6: vendor 0x1002 OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub6: 2 ports with 2 removable, self powered

>How-To-Repeat:
	Connect or disconnect a USB device to a USB port on a non-root hub.
>Fix:

>Release-Note:

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/42884: USB hubs don't recognise device
	connects/disconnects
Date: Sun, 28 Feb 2010 22:01:09 +0000

 Not sent to gnats.

 ------

 From: Ignatios Souvatzis <is@netbsd.org>
 To: netbsd-bugs@netbsd.org
 Subject: pr 42884
 Date: Fri, 26 Feb 2010 16:26:49 +0100

 I tested the scenario with a USB hub we're Using as a cable regenarator
 for a printer at the wrong side of the room.

 I don't see any anomalies, with both i386 and amd64, with NetBSD 5.0.2,
 using a mouse as test object.

 	-is


 From: dieter roelants <dieter.NetBSD@pandora.be>
 To: netbsd-bugs@netbsd.org
 Subject: Re: port-amd64/42884
 Date: Fri, 26 Feb 2010 21:47:37 +0100

 On Fri, 26 Feb 2010 16:26:49 +0100
 Ignatios Souvatzis <is@netbsd.org> wrote:

 > I tested the scenario with a USB hub we're Using as a cable
 > regenarator for a printer at the wrong side of the room.
 > 
 > I don't see any anomalies, with both i386 and amd64, with NetBSD
 > 5.0.2, using a mouse as test object.
 > 
 > 	-is
 > 

 It works on my system (amd64 5.99.24) too. It has uhci, not ohci, maybe
 that's related.

 ehci0 at pci0 dev 29 function 7: Intel 82801GB/GR USB EHCI Controller
 (rev. 0x01) ehci0: interrupting at ioapic0 pin 20
 ehci0: EHCI version 1.0
 ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2 uhci3
 usb4 at ehci0: USB revision 2.0
 uhub4 at usb4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
 uhub4: 8 ports with 8 removable, self powered
 uhub5 at uhub4 port 2: Standard Microsystems product 0x2504, class 9/0,
 rev 2.00/0.01, addr 2 uhub5: multiple transaction translators
 uhub5: 4 ports with 4 removable, self powered
 uhub6 at uhub5 port 2: ALCOR Generic USB Hub, class 9/0, rev 1.10/3.12,
 addr 3 uhub6: 4 ports with 4 removable, self powered

 this is after boot:
 uhidev5 at uhub5 port 4 configuration 1 interface 0
 uhidev5: NOVATEK USB Keypad, rev 1.00/1.00, addr 7, iclass 3/1
 ukbd2 at uhidev5
 wskbd2 at ukbd2 mux 1
 uhidev6 at uhub5 port 4 configuration 1 interface 1
 uhidev6: NOVATEK USB Keypad, rev 1.00/1.00, addr 7, iclass 3/1
 uhidev6: 1 report ids
 uhid1 at uhidev6 reportid 1: input=3, output=1, feature=0
 wskbd2: detached
 ukbd2: detached
 uhidev5: detached
 uhidev5: at uhub5 port 4 (addr 7) disconnected
 uhid1: detached
 uhidev6: detached
 uhidev6: at uhub5 port 4 (addr 7) disconnected

 and (replugging my mouse):
 wsmouse0: detached
 ums0: detached
 uhidev2: detached
 uhidev2: at uhub6 port 2 (addr 5) disconnected
 uhidev2 at uhub6 port 2 configuration 1 interface 0
 uhidev2: Logitech USB Trackball, rev 1.10/14.00, addr 5, iclass 3/1
 ums0 at uhidev2: 5 buttons
 wsmouse0 at ums0 mux 0

 dieter

Responsible-Changed-From-To: port-amd64-maintainer->kern-bug-people
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Sun, 28 Feb 2010 23:48:12 +0000
Responsible-Changed-Why:
not amd64-specific until proven otherwise


From: martijnb@stack.nl (Martijn van Buul)
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-amd64/42884: USB hubs don't recognise device
 connects/disconnects
Date: Mon, 1 Mar 2010 12:40:43 +0100

 In the mean time, I've tried to localise the problem by installing a PCI
 USB controller. However, that didn't work at all; the attachment failed
 with a "Cannot map memory space", even with the various _FIXUP options
 enabled. There might be deeper issues.

 That said, the on-board USB controller works just fine under Linux. The
 addon card didn't work on windows or Linux either.

 -- 
 Martijn van Buul - pino@dohd.org 

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.