NetBSD Problem Report #23819
Received: (qmail 5757 invoked by uid 605); 21 Dec 2003 12:10:04 -0000
Message-Id: <20031221121000.7F86811155@narn.netbsd.org>
Date: Sun, 21 Dec 2003 12:10:00 +0000 (UTC)
From: rkr@olib.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: rkr@olib.org
To: gnats-bugs@gnats.NetBSD.org
Subject: USB controller occasionally (randomly) dies.
X-Send-Pr-Version: www-1.0
>Number: 23819
>Category: kern
>Synopsis: USB controller occasionally (randomly) dies.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Dec 21 12:11:00 +0000 2003
>Closed-Date:
>Last-Modified: Mon Oct 18 04:26:00 +0000 2004
>Originator: Richard Rauch
>Release: NetBSD/amd64-current, and NetBSD/i386-1.6
>Organization:
n/a
>Environment:
NetBSD socrates 1.6ZG NetBSD 1.6ZG (GENERIC) #6: Thu Dec 18 20:28:19 CST 2003 r
oot@socrates:/usr/netbsd/current/src/sys/arch/amd64/compile/obj.amd64/GENERIC amd64
>Description:
Periodically, I have had the USB controller die on me without warning. It occurs at random intervals. On an AMD64 machine it happens frequently enough (and I rely on a USB pointer device enough) that uptimes over a day are painful. The only cure is to reset the machine.
On an i386, it is not so bad, but still happens from time to time (*far* less often; weeks or more can go by). I do not know that the two failures are related, but thought that I'd mention it anyway.
The amd64 fails with the message "usbd_setup_pipe: failed to start endpoint, ...", in src/sys/dev/usb/usb_subr.c:usbd_setup_pipe().
Because of these problems, I am on a text console using lynx to file this PR, so I cannot provide full dmesg output readily. However, the USB device is an "ohci" for the AMD64 (there are ohci0 and ohci1; uhub0 is on the former, and to that uhidev0---the trackball---attaches).
For the i386, it is similar (ohci again; usb0, usb1; uhub0 at usb0; all devices on uhub0; it is *not* running GENERIC, but rather a custom kernel from standard 1.6 kernel sources.)
The error with the i386 is so rare that I do not know offhand whether it is accompanied by any console error messages. Sorry. Unlike the AMD64 box, the i386 box does not have a non-USB keyboard, so when its USB dies, it is useless for local access and generally gets reset.
>How-To-Repeat:
Use one of these two machines for a while until the USB subsystem dies.
Sorry, I can't be more specific; the behavior is random. I cannot firmly associate it to busy activity on the USB ports or to system load, or to lots of activity.
For the AMD64, it would help if I knew why a "pipe" has to be set up for a USB device in the middle of normal USB use. Then I might be able to think of some pattern that eludes me.
>Fix:
No solution known.
>Release-Note:
>Audit-Trail:
From: Lennart Augustsson <lennart@augustsson.net>
To: rkr@olib.org
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Sun, 21 Dec 2003 13:21:01 +0100
> The amd64 fails with the message "usbd_setup_pipe: failed to start endpoint, ...",
Could you provide the crucial continuation of that message which
tells why it failed?
-- Lennart
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Sun, 21 Dec 2003 06:25:10 -0600
On Sun, Dec 21, 2003 at 01:21:01PM +0100, Lennart Augustsson wrote:
> >The amd64 fails with the message "usbd_setup_pipe: failed to start
> >endpoint, ...",
> Could you provide the crucial continuation of that message which
> tells why it failed?
Not offhand, since I have rebooted since the failure. My memory is
that it didn't say much, but I'll file a follow-up the next time that
the error occurs. Perhaps later today, probably in a couple of days
at the latest.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Lennart Augustsson <lennart@augustsson.net>
To: Richard Rauch <rkr@olib.org>
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Sun, 21 Dec 2003 15:37:00 +0100
Does it say anything before the usbd_setup_pipe message?
That routine is only entered when you open a device.
So for some reason it must have been opened. Did you disconnect it?
Or switch between virtual consoles?
-- Lennart
Richard Rauch wrote:
> On Sun, Dec 21, 2003 at 01:21:01PM +0100, Lennart Augustsson wrote:
>
>>>The amd64 fails with the message "usbd_setup_pipe: failed to start
>>>endpoint, ...",
>>
>>Could you provide the crucial continuation of that message which
>>tells why it failed?
>
>
> Not offhand, since I have rebooted since the failure. My memory is
> that it didn't say much, but I'll file a follow-up the next time that
> the error occurs. Perhaps later today, probably in a couple of days
> at the latest.
>
>
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Sun, 21 Dec 2003 09:30:08 -0600
On Sun, Dec 21, 2003 at 03:37:00PM +0100, Lennart Augustsson wrote:
> Does it say anything before the usbd_setup_pipe message?
> That routine is only entered when you open a device.
No. And this happens after X has been running for some time. The
only USB device is my trackball.
The message appears concommitant with the USB controller dying.
The sequence is: Normal boot. Start X (via "startx"), and after
a random interval from minutes to many hours, it suddenly dies.
Everything else is okay, and I can exit X via ctrl-alt-backspace.
Another piece of information (from memory; I'll try to confirm
the next time it happens): Reading /dev/wsmouse (which X is using)
after the error will result in nothing (I cannot tell if it opens
or not; I assume that it does). Opening /dev/wsmouse0 I believe
gave an error message. The former, at least, may not be a surprise.
> So for some reason it must have been opened. Did you disconnect it?
> Or switch between virtual consoles?
No. Just moving the mouse around, generally. E.g., positioning a
new window in twm, or (the last time) selecting from a drop-box of
options on an HTML form. I know that sometimes it happens while I
am moving the mouse. I do not know if there are any exceptions to
that.
This is why I said I was confused why it was calling this
"setup" function. I wouldn't think that there would be a need to
set up a pipe of some sort in the middle of operations.
It *is* remotely possible that the message came up after the mouse
froze, followed by exiting X and restarting X. If that is the case,
then there is no message whatsoever for the controller dying.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Sun, 21 Dec 2003 11:18:47 -0600
On Sun, Dec 21, 2003 at 03:37:00PM +0100, Lennart Augustsson wrote:
> Does it say anything before the usbd_setup_pipe message?
The message was TIMEOUT. The whole dmesg follows. Everything but the last
line is "normal" for this system. Then I ran X. Then after a while, the USB
froze (it may be significant that it usually happens when I'm running X
applications over the rtk0 LAN---e.g., a graphical web-browser living on a
machine connected to the Internet).
The USB message does not appear until I *restart* X. (The USB controller
remains dead. Also, plugging and unplugging the trackball or plugging into
a different port does not do any good.)
od /dev/wsmouse just sits there
od /dev/wsmouse0 "od: /dev/wsmouse0: Input/output error"
od /dev/wsmouse1 "od: /dev/wsmouse1: Device not configured"
Full dmesg:
NetBSD 1.6ZG (GENERIC) #6: Thu Dec 18 20:28:19 CST 2003
root@socrates:/usr/netbsd/current/src/sys/arch/amd64/compile/obj.amd64/GENERIC
total memory = 511 MB
avail memory = 457 MB
using 6144 buffers containing 26292 KB of memory
mainbus0 (root)
mainbus0: Intel MP Specification (Version 1.4) (OEM00000 PROD00000000)
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 64 Processor 3200+, 1994.98 MHz
cpu0: features: e7dbfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features: e7dbfbff<PGE,MCA,CMOV,PAT,PSE36,MPC,NOX,MMXX,MMX>
cpu0: features: e7dbfbff<FXSR,SSE,SSE2,LONG,3DNOW2,3DNOW>
cpu0: I-cache 64 KB 64b/line 2-way, D-cache 64 KB 64b/line 2-way
cpu0: L2 cache 1 MB 64b/line 16-way
cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: calibrating local timer
cpu0: apic clock running at 199 MHz
cpu0: 16 page colors
mpbios: bus 0 is type PCI
mpbios: bus 1 is type PCI
mpbios: bus 2 is type PCI
mpbios: bus 3 is type ISA
ioapic0 at mainbus0 apid 2 (I/O APIC)
ioapic0: pa 0xfec00000, version 11, 24 pins
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0
pchb0: Nvidia Corporation nForce3 Host-PCI bridge (rev. 0xa4)
pcib0 at pci0 dev 1 function 0
pcib0: Nvidia Corporation nForce3 PCI-ISA bridge (rev. 0xa6)
Nvidia Corporation nForce3 SMBus controller (SMBus serial bus, revision 0xa4) at pci0 dev 1 function 1 not configured
ohci0 at pci0 dev 2 function 0: Nvidia Corporation nForce3 USB Host Controller (rev. 0xa5)
pci_intr_map: bus 0 dev 2 func 0 pin 1; line 9
pci_intr_map: no MP mapping found
ohci0: interrupting at irq 9
ohci0: OHCI version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Nvidia Corporat OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1 at pci0 dev 2 function 1: Nvidia Corporation nForce3 USB Host Controller (rev. 0xa5)
pci_intr_map: bus 0 dev 2 func 1 pin 2; line 9
pci_intr_map: no MP mapping found
ohci1: interrupting at irq 9
ohci1: OHCI version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Nvidia Corporat OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
Nvidia Corporation nForce3 USB2 Host Controller (USB serial bus, interface 0x20, revision 0xa2) at pci0 dev 2 function 2 not configured
auich0 at pci0 dev 6 function 0: nForce3 MCP-T AC-97 Audio
auich0: interrupting at ioapic0 pin 11 (irq 11)
auich0: ac97: Avance Logic unknown (0x414c4780) codec; 20 bit DAC, 18 bit ADC, no 3D stereo
auich0: ac97: ext id 9c7<AC97_23,LDAC,SDAC,CDAC,SPDIF,DRA,VRA>
pciide0 at pci0 dev 8 function 0
pciide0: Nvidia Corporation nForce3 ATA133 IDE (rev. 0xa5)
pciide0: bus-master DMA support present, but unused (no driver support)
pciide0: primary channel configured to compatibility mode
pciide0: primary channel interrupting at ioapic0 pin 14 (irq 14)
atabus0 at pciide0 channel 0
pciide0: secondary channel configured to compatibility mode
pciide0: secondary channel interrupting at ioapic0 pin 15 (irq 15)
atabus1 at pciide0 channel 1
ppb0 at pci0 dev 10 function 0: Nvidia Corporation nforce3 PCI-PCI bridge (rev. 0xa2)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled
fxp0 at pci1 dev 7 function 0: i82558 Ethernet, rev 5
fxp0: interrupting at ioapic0 pin 19 (irq 5)
fxp0: Ethernet address 00:03:47:72:7f:87
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rtk0 at pci1 dev 8 function 0: RealTek 8139 10/100BaseTX
rtk0: interrupting at ioapic0 pin 11 (irq 11)
rtk0: Ethernet address 00:90:47:05:bc:75
ukphy0 at rtk0 phy 7: Generic IEEE 802.3u media interface
ukphy0: OUI 0x000000, model 0x0000, rev. 0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Realtek Semiconductor 8169 10/100/1000 Ethernet (ethernet network, revision 0x10) at pci1 dev 11 function 0 not configured
Integrated Technology Express, Inc. product 0x8212 (RAID mass storage, revision 0x11) at pci1 dev 12 function 0 not configured
Texas Instruments TSB43AA23 OHCI IEEE 1394 Host Controller (Firewire serial bus, interface 0x10) at pci1 dev 14 function 0 not configured
ppb1 at pci0 dev 11 function 0: Nvidia Corporation product 0x00d2 (rev. 0xa4)
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled
vga0 at pci2 dev 0 function 0: ATI Technologies Radeon 9200SE (rev. 0x01)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
pchb1 at pci0 dev 24 function 0
pchb1: Advanced Micro Devices AMD64 HyperTransport configuration (rev. 0x00)
pchb2 at pci0 dev 24 function 1
pchb2: Advanced Micro Devices AMD64 Address Map configuration (rev. 0x00)
pchb3 at pci0 dev 24 function 2
pchb3: Advanced Micro Devices AMD64 DRAM configuration (rev. 0x00)
pchb4 at pci0 dev 24 function 3
pchb4: Advanced Micro Devices AMD64 Miscellaneous configuration (rev. 0x00)
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
lpt0 at isa0 port 0x378-0x37b irq 7
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
ioapic0: enabling
auich0: measured ac97 link rate at 16036 Hz, will use 48000 Hz
audio0 at auich0: full duplex, mmap, independent
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
Kernelized RAIDframe activated
uhidev0 at uhub0 port 3 configuration 1 interface 0
uhidev0: Microsoft Microsoft Trackball OpticalM-., rev 1.10/1.21, addr 2, iclass 3/1
ums0 at uhidev0: 5 buttons and Z dir.
wsmouse0 at ums0 mux 0
wd0 at atabus0 drive 0: <WDC WD400BB-75DKA0>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 38146 MB, 77504 cyl, 16 head, 63 sec, 512 bytes/sect x 78125000 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
atapibus0 at atabus1: 2 targets
cd0 at atapibus0 drive 1: <LG DVD-ROM DRD-8160B, , 1.01> cdrom removable
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
boot device: wd0
root on wd0a dumps on wd0b
WARNING: invalid time in clock chip
WARNING: CHECK AND RESET THE DATE!
root file system type: ffs
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x50, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
fxp0: device timeout
fxp0: device timeout
usbd_setup_pipe: failed to start endpoint, TIMEOUT
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Lennart Augustsson <lennart@augustsson.net>
To: Richard Rauch <rkr@olib.org>
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Sun, 21 Dec 2003 23:20:49 +0100
Judging from your description it sounds like the interrupts stop
working. That would make the mouse die, and when you try to restart
there would be no response from the device and you'd get that TIMEOUT.
The OHCI controller interrupts at irq 11, just as rtk0. I wonder if
that's a problem. Is there any way to test with a different network
irq?
-- Lennart
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Sun, 21 Dec 2003 22:21:42 -0600
On Sun, Dec 21, 2003 at 11:20:49PM +0100, Lennart Augustsson wrote:
> Judging from your description it sounds like the interrupts stop
> working. That would make the mouse die, and when you try to restart
> there would be no response from the device and you'd get that TIMEOUT.
>
> The OHCI controller interrupts at irq 11, just as rtk0. I wonder if
> that's a problem. Is there any way to test with a different network
> irq?
I don't know. I haven't manually assigned interrupts to anything
since a brief (and unpleasant) contact with old ISA PCs a long, long
time ago.
Is this something that I can change by a kernel config, or do I just
have to hope to find something useful in BIOS?
If it comes to it, I could give myself a non-NFS homedir and boot without
the card at all. But since lossage has generally been while running
an X program over the network, that might not tell you anything
useful (unless it did lockup without a network interface).
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: "Charles M. Hannum" <abuse@spamalicious.com>
To: rkr@olib.org
Cc: gnats-bugs@gnats.NetBSD.org, augustss@netbsd.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Wed, 7 Jul 2004 21:26:54 +0000
The fact that you're getting messages from usbd_setup_pipe() at all indicates
that something is opening a USB device at the time. Are you swapping the
mouse around, or changing VTs, or something? And how are you determining
that the console message is at the same time (as opposed to, say, switching
consoles when the mouse is wedged, and getting the message due to *that*)?
From: Richard Rauch <rkr@olib.org>
To: "Charles M. Hannum" <abuse@spamalicious.com>
Cc: gnats-bugs@gnats.NetBSD.org, augustss@netbsd.org
Subject: Re: kern/23819: USB controller occasionally (randomly) dies.
Date: Wed, 7 Jul 2004 18:30:00 -0500
On Wed, Jul 07, 2004 at 09:26:54PM +0000, Charles M. Hannum wrote:
> The fact that you're getting messages from usbd_setup_pipe() at all indicates
> that something is opening a USB device at the time. Are you swapping the
> mouse around, or changing VTs, or something? And how are you determining
> that the console message is at the same time (as opposed to, say, switching
> consoles when the mouse is wedged, and getting the message due to *that*)?
I believe that I was able to make the problem go away by turning
off IOAPIC. (Alternately, swapping around PCI cards could cause
me to lose other functionality and keep USB, I think.)
I believe that I was able to generate the usbd_setup_pipe() messages
by trying to restart X. I think. It is possible that after the
mouse died, I unplugged the mouse (trackball) and plugged it back
in, causing those messages. But I am fairly certain that the mouse
"died" before I would have tried any such thing.
I'm sorry, but my memory has faded over the past 7 months. I've had a
workaround and have had other things on my mind.
Perhaps I will be able to take the AMD64 down for a day and play
with this to see if I can be sure what I might have done to force
those messages.
If there's anything you'd like me to check, besides trying to pin
down when those messages get written, let me know. The AMD64 is
not a spare toy, so I won't want to keep taking it down if I can
help it.
Thanks for the followup.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Matthew Orgass <darkstar@city-net.com>
To: gnats-bugs@netbsd.org
Cc: Richard Rauch <rkr@olib.org>, Lennart Augustsson <lennart@augustsson.net>,
"Charles M. Hannum" <abuse@spamalicious.com>,
Michael <macallan18@earthlink.net>
Subject: kern/23819 (USB dies)
Date: Sat, 16 Oct 2004 23:00:07 -0400 (EDT)
I just started hitting what might be a related problem. I am seeing the
problem when starting X. I have not yet seen the controller die while X
is running, only when X starts (though I have not been using it long).
When it happens, the screen stays black in video mode for usually ten
seconds or so (but sometimes less) and when it continues the usb
controller is dead. This is 2.0_BETA with uhci/ehci, XFree86 4.4.0, and a
Matrox G400 card. After it dies, plugging it into a port on a different
controller works. The dead controller does not work again until after a
reboot. I will try to look into this soon, but wanted to send this info
out now in case it helps anyone else. I am ccing Michael because of
http://mail-index.netbsd.org/port-macppc/2004/10/07/0002.html which also
seems likely to be related (at least to the PR).
Immediately before seeing the problem I added an "IBM Travel Keyboard
with UltraNav" device. I also fairly recently upgraded XFree86 from a
quite a bit older version, although I belive I used it sufficiently often
since then that the IBM keyboard is almost certainly the cause (I don't
recall exactly when I did the upgrade). I have seen all three controllers
die, so it does not seem to be a particular interrupt conflict. All three
are shared interrupts, two with the cardbus controller (no card inserted)
and one with the network card (usually not enabled until after X starts).
It looks like the problem will always happen when either mouse on the IBM
keyobard is touched before X starts (but this does not cause problems with
my other USB mouse).
The following devices are currently reported (output of usbdevs -v):
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA
Technologies(0x1106), rev 1.00
port 1 powered
port 2 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA
Technologies(0x1106), rev 1.00
port 1 powered
port 2 addr 2: full speed, self powered, config 1, TUSB2046 hub(0x2046),
Texas Instruments(0x0451), rev 1.25
port 1 powered
port 2 addr 3: full speed, power 40 mA, config 1, USB 1.1 2 port
downstream low-power hub(0x3016), Lite-On Tech(0x04b3), rev 1.26
port 1 powered
port 2 powered
port 3 addr 4: low speed, power 70 mA, config 1, IBM USB Travel
Keyboard with UltraNav(0x3019), Lite-On Tech(0x04b3), rev 1.16
port 4 addr 5: low speed, power 100 mA, config 1, Composite TouchPad /
TrackPoint(0x0009), Synaptics Inc.(0x06cb), rev 0.20
port 3 addr 6: full speed, power 100 mA, config 1, iMic USB audio
system(0x07af), Griffin Technology, Inc(0x077d), rev 0.05
port 4 addr 7: low speed, power 26 mA, config 1, N42(0xc000),
Logitech(0x046d), rev 4.01
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA
Technologies(0x1106), rev 1.00
port 1 powered
port 2 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), VIA
Technologie(0x1106), rev 1.00
port 1 powered
port 2 powered
port 3 powered
port 4 powered
port 5 powered
port 6 powered
And my dmesg:
NetBSD 2.0_BETA (JOVE) #18: Fri Jul 9 16:42:36 EDT 2004
root@jove.city-net.com:/usr/irobj/sys/arch/i386/compile/JOVE
total memory = 511 MB
avail memory = 484 MB
BIOS32 rev. 0 found at 0xfbce0
mainbus0 (root)
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD Athlon XP 2400+ (686-class), 1999.79 MHz, id 0x681
cpu0: features c3c3fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features c3c3fbff<PGE,MCA,CMOV,PAT,PSE36,MMXX,MMX>
cpu0: features c3c3fbff<FXSR,SSE,3DNOW2,3DNOW>
cpu0: I-cache 64 KB 64b/line 2-way, D-cache 64 KB 64b/line 2-way
cpu0: L2 cache 256 KB 64b/line 16-way
cpu0: ITLB 16 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries 4-way
cpu0: 8 page colors
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0
pchb0: VIA Technologies product 0x3116 (rev. 0x00)
agp0 at pchb0: aperture at 0xd0000000, size 0x10000000
ppb0 at pci0 dev 1 function 0: VIA Technologies VT8633 (Apollo Pro 266) CPU-AGP Bridge (rev. 0x00)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled
vga1 at pci1 dev 0 function 0: Matrox MGA G400 AGP (rev. 0x04)
wsdisplay0 at vga1 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
cbb0 at pci0 dev 6 function 0: Ricoh 5C476 PCI-CardBus bridge (rev. 0x80)
cbb1 at pci0 dev 6 function 1: Ricoh 5C476 PCI-CardBus bridge (rev. 0x80)
uhci0 at pci0 dev 16 function 0: VIA Technologies VT83C572 USB Controller (rev. 0x80)
uhci0: interrupting at irq 15
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
uhci1 at pci0 dev 16 function 1: VIA Technologies VT83C572 USB Controller (rev. 0x80)
uhci1: interrupting at irq 10
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: VIA Technologies UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2: VIA Technologies VT83C572 USB Controller (rev. 0x80)
uhci2: interrupting at irq 11
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: VIA Technologies UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 16 function 3: VIA Technologies VT8237 EHCI USB Controller (rev. 0x82)
ehci0: interrupting at irq 5
ehci0: EHCI version 1.0
ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2
usb3 at ehci0: USB revision 2.0
uhub3 at usb3
uhub3: VIA Technologie EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
pcib0 at pci0 dev 17 function 0
pcib0: VIA Technologies VT8235 (Apollo KT400) PCI-ISA Bridge (rev. 0x00)
viaide0 at pci0 dev 17 function 1
viaide0: VIA Technologies VT8235 ATA133 controller
viaide0: bus-master DMA support present
viaide0: primary channel configured to compatibility mode
viaide0: primary channel interrupting at irq 14
atabus0 at viaide0 channel 0
viaide0: secondary channel configured to compatibility mode
viaide0: secondary channel ignored (disabled)
auvia0 at pci0 dev 17 function 5: VIA VT8235 AC'97 (rev 0x50)
auvia0: interrupting at irq 11
auvia0: ac97: Avance Logic ALC650 codec; 20 bit DAC, 18 bit ADC, Realtek 3D
auvia0: ac97: ext id 5c7<AC97_22,LDAC,SDAC,CDAC,SPDIF,DRA,VRA>
audio0 at auvia0: full duplex, mmap, independent
vr0 at pci0 dev 18 function 0: VIA VT6102 (Rhine II) 10/100 Ethernet
vr0: interrupting at irq 15
vr0: Ethernet address: 00:0c:76:42:2a:18
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface
ukphy0: OUI 0x0002c6, model 0x0032, rev. 8
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
cbb0: interrupting at irq 10
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 2 device 0
pcmcia0 at cardslot0
cbb1: interrupting at irq 11
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 3 device 0
pcmcia1 at cardslot1
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsprobe: reset error 5
lm0 at isa0 port 0x290-0x297: W83697HF
npx0 at isa0 port 0xf0-0xff: using exception 16
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
apm0 at mainbus0: Power Management spec V1.2 (slowidle)
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
ehci0: handing over full speed device on port 6 to uhci2
uhub3: port 6, device disappeared after reset
uhub4 at uhub2 port 2
uhub4: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 2
uhub4: 4 ports with 4 removable, self powered
wd0 at atabus0 drive 0: <ST380021A>
wd0: drive supports 16-sector PIO transfers, LBA addressing
wd0: 76319 MB, 155061 cyl, 16 head, 63 sec, 512 bytes/sect x 156301488 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA data transfers)
boot device: wd0
root on wd0a dumps on wd0b
init: copying out path `/sbin/init' 11
uhub5 at uhub4 port 2
uhub5: Lite-On Tech USB 1.1 2 port downstream low-power hub, class 9/0, rev 1.10/1.26, addr 3
uhub5: 4 ports with 2 removable, bus powered
uhidev0 at uhub5 port 3 configuration 1 interface 0
uhidev0: Lite-On Tech IBM USB Travel Keyboard with UltraNav, rev 1.10/1.16, addr 4, iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub5 port 3 configuration 1 interface 1
uhidev1: Lite-On Tech IBM USB Travel Keyboard with UltraNav, rev 1.10/1.16, addr 4, iclass 3/0
uhidev1: 3 report ids
uhid0 at uhidev1 reportid 2: input=1, output=0, feature=0
uhid1 at uhidev1 reportid 3: input=3, output=0, feature=0
uhidev2 at uhub5 port 4 configuration 1 interface 0
uhidev2: Synaptics Inc. Composite TouchPad / TrackPoint, rev 1.10/0.20, addr 5, iclass 3/1
ums0 at uhidev2: 3 buttons
wsmouse0 at ums0 mux 0
uhidev3 at uhub5 port 4 configuration 1 interface 1
uhidev3: Synaptics Inc. Composite TouchPad / TrackPoint, rev 1.10/0.20, addr 5, iclass 3/1
ums1 at uhidev3: 3 buttons
wsmouse1 at ums1 mux 0
uaudio0 at uhub4 port 3 configuration 1 interface 0: Griffin Technology, Inc iMic USB audio system, rev 1.10/0.05, addr 6
uaudio0: ignored input endpoint of type adaptive
uaudio0: ignored input endpoint of type adaptive
uaudio0: ignored input endpoint of type adaptive
uaudio0: audio rev 1.00
uaudio0: 14 mixer controls
audio1 at uaudio0: full duplex, independent
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x25, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
uhidev4 at uhub4 port 4 configuration 1 interface 0
uhidev4: Logitech N42, rev 1.00/4.01, addr 7, iclass 3/1
ums2 at uhidev4: 2 buttons
wsmouse2 at ums2 mux 0
usbd_setup_pipe: failed to start endpoint, TIMEOUT
usbd_setup_pipe: failed to start endpoint, TIMEOUT
usbd_setup_pipe: failed to start endpoint, TIMEOUT
uhub4: at uhub2 port 2 (addr 2) disconnected
uhub5: at uhub4 port 2 (addr 3) disconnected
uhidev0: at uhub5 port 3 (addr 4) disconnected
wskbd1: disconnecting from wsdisplay0
wskbd1 detached
ukbd0 detached
uhidev0 detached
uhidev1: at uhub5 port 3 (addr 4) disconnected
uhid0 detached
uhid1 detached
uhidev1 detached
uhidev2: at uhub5 port 4 (addr 5) disconnected
wsmouse0 detached
ums0 detached
uhidev2 detached
uhidev3: at uhub5 port 4 (addr 5) disconnected
wsmouse1 detached
ums1 detached
uhidev3 detached
uhub5 detached
uaudio0: at uhub4 port 3 (addr 6) disconnected
audio1 detached
uaudio0 detached
uhidev4: at uhub4 port 4 (addr 7) disconnected
wsmouse2 detached
ums2 detached
uhidev4 detached
uhub4 detached
ehci0: handing over full speed device on port 4 to uhci1
uhub3: port 4, device disappeared after reset
uhub4 at uhub1 port 2
uhub4: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 2
uhub4: 4 ports with 4 removable, self powered
uhub5 at uhub4 port 2
uhub5: Lite-On Tech USB 1.1 2 port downstream low-power hub, class 9/0, rev 1.10/1.26, addr 3
uhub5: 4 ports with 2 removable, bus powered
uhidev0 at uhub5 port 3 configuration 1 interface 0
uhidev0: Lite-On Tech IBM USB Travel Keyboard with UltraNav, rev 1.10/1.16, addr 4, iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub5 port 3 configuration 1 interface 1
uhidev1: Lite-On Tech IBM USB Travel Keyboard with UltraNav, rev 1.10/1.16, addr 4, iclass 3/0
uhidev1: 3 report ids
uhid0 at uhidev1 reportid 2: input=1, output=0, feature=0
uhid1 at uhidev1 reportid 3: input=3, output=0, feature=0
uhidev2 at uhub5 port 4 configuration 1 interface 0
uhidev2: Synaptics Inc. Composite TouchPad / TrackPoint, rev 1.10/0.20, addr 5, iclass 3/1
ums0 at uhidev2: 3 buttons
wsmouse0 at ums0 mux 0
uhidev3 at uhub5 port 4 configuration 1 interface 1
uhidev3: Synaptics Inc. Composite TouchPad / TrackPoint, rev 1.10/0.20, addr 5, iclass 3/1
ums1 at uhidev3: 3 buttons
wsmouse1 at ums1 mux 0
uaudio0 at uhub4 port 3 configuration 1 interface 0: Griffin Technology, Inc iMic USB audio system, rev 1.10/0.05, addr 6
uaudio0: ignored input endpoint of type adaptive
uaudio0: ignored input endpoint of type adaptive
uaudio0: ignored input endpoint of type adaptive
uaudio0: audio rev 1.00
uaudio0: 14 mixer controls
audio1 at uaudio0: full duplex, independent
uhidev4 at uhub4 port 4 configuration 1 interface 0
uhidev4: Logitech N42, rev 1.00/4.01, addr 7, iclass 3/1
ums2 at uhidev4: 2 buttons
wsmouse2 at ums2 mux 0
When trying to reinsert the hub into a controller that died I get the
following:
ehci0: handing over full speed device on port 4 to uhci1
uhub3: port 4, device disappeared after reset
Those messages also appears when the port works. After a short delay, I
get:
usb_new_device: set address 2 failed
uhub_explore: usb_new_device failed, error=SET_ADDR_FAILED
uhub1: device problem, disabling port 2
Then after waiting a bit longer, I unplug the device and got:
uhub1: port error, restarting port 2
I have a few custom USB patches in this kernel, but I don't think any of
them should be related. I'll try a plain kernel first when I update. I
also currently have USB_DEBUG defined.
Matthew Orgass
darkstar@city-net.com
From: Matthew Orgass <darkstar@city-net.com>
To: gnats-bugs@netbsd.org
Cc: Richard Rauch <rkr@olib.org>, Lennart Augustsson <lennart@augustsson.net>,
"Charles M. Hannum" <abuse@spamalicious.com>,
Michael <macallan18@earthlink.net>
Subject: Re: kern/23819 (USB dies)
Date: Mon, 18 Oct 2004 00:28:42 -0400 (EDT)
It looks like my problem is different from this PR. The device
apparently babbles, possibly due to the chip bug described in:
http://mail-index.netbsd.org/tech-kern/2002/11/27/0018.html
The babble may then trigger the VIA HC bug described in kern/21547 (this
is also the same via chip of kern/11018, but a later revision), where
babble causes the controller to shut down. uhci turns BABBLE, STALL into
USBD_IOERROR, which shuts down the pipe. The clear stall then times out,
as do all further transfers on that controller.
Matthew Orgass
darkstar@city-net.com
>Unformatted:
(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.