usb-uhci locks up on boot half the time

Ok, in test10, for every 2 out of 5 boots, this particular workstation locks up hard as it reaches the following:

usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.242 $ time 15:53:47 Nov 8 2000 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 9 usb-uhci.c: Detected 2 ports
<locks here, hard reset required>

In test11, it locks up two lines earlier, right after 'enabled'

The normal sequence is:

usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.242 $ time 15:53:47 Nov 8 2000 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 9 usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hid
usb.c: registered new driver dc2xx
usb.c: registered new driver dsbr100
usb.c: registered new driver usb-storage

It's a pII 300, not overclocked, ASUS P3BF motherboard.

00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
Subsystem: Asustek Computer, Inc.: Unknown device 7190
Flags: bus master, medium devsel, latency 64
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
Flags: bus master, 66Mhz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: cb800000-cdefffff Prefetchable memory behind bridge: cff00000-cfffffff

00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
Flags: bus master, medium devsel, latency 0

00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master])
Flags: bus master, medium devsel, latency 32
I/O ports at b800 [size=16]

00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at b400 [size=32]

00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
Flags: medium devsel

00:09.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14)
Subsystem: Diamond Multimedia Systems FirePort 40 Dual SCSI
Controller

        Flags: bus master, medium devsel, latency 144, IRQ 9
        I/O ports at b000 [size=256]
        Memory at cb000000 (32-bit, non-prefetchable) [size=256]
        Memory at ca800000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=64K]

00:09.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14)
Subsystem: Diamond Multimedia Systems FirePort 40 Dual SCSI
Controller

        Flags: bus master, medium devsel, latency 144, IRQ 9
        I/O ports at a800 [size=256]
        Memory at ca000000 (32-bit, non-prefetchable) [size=256]
        Memory at c9800000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=64K]

00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 11)

        Flags: bus master, medium devsel, latency 32, IRQ 5
        I/O ports at a400 [size=128]
        Memory at c9000000 (32-bit, non-prefetchable) [size=128]

00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II]
Subsystem: Matrox Graphics, Inc.: Unknown device 051b
Flags: medium devsel, IRQ 10
Memory at ce000000 (32-bit, prefetchable) [disabled] [size=16M] Memory at c8800000 (32-bit, non-prefetchable) [disabled]
[size=16K]

        Memory at c8000000 (32-bit, non-prefetchable) [disabled]

[size=8M]
Expansion ROM at cdff0000 [disabled] [size=64K]

00:0c.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
Subsystem: Voyetra Technologies: Unknown device 6003
Flags: bus master, slow devsel, latency 32, IRQ 11 Memory at c7800000 (32-bit, non-prefetchable) [size=4K] Memory at c7000000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [40] Power Management version 2

00:0d.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at a000 [size=64]
Expansion ROM at <unassigned> [disabled] [size=64K]

01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c)
Subsystem: ATI Technologies Inc: Unknown device 4742
Flags: bus master, stepping, medium devsel, latency 64, IRQ 11 Memory at cc000000 (32-bit, non-prefetchable) [size=16M] I/O ports at d800 [size=256]
Memory at cb800000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at cffe0000 [disabled] [size=128K]
Capabilities: [50] AGP version 1.0

# cat /proc/interrupts
           CPU0
  0:      37974          XT-PIC  timer
  1:         16          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:        735          XT-PIC  eth0
  8:          0          XT-PIC  rtc
  9:       6135          XT-PIC  sym53c8xx, sym53c8xx, usb-uhci, acpi
 13:          0          XT-PIC  fpu
 15:         61          XT-PIC  ide1
NMI:          0
ERR:          0

# grep "^CONFIG.*USB" /boot/config
CONFIG_VIDEO_CPIA_USB=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_UHCI=y
CONFIG_USB_DC2XX=y
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_DSBR=y
CONFIG_USB_HID=y

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

DF> Ok, in test10, for every 2 out of 5 boots, this particular DF> workstation locks up hard as it reaches the following:

I have a similar problem. My work around is to, by hand, modprobe usbmouse, wait, modprobe usb-uhci...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Apply the kernel debugger patch[*], select "APIC and IO-APIC support on uniprocessors" then "NMI watchdog active for uniprocessors". Compile, install, reboot. When the machine hangs, NMI should drop into kdb after 5 seconds, 'bt' gives a backtrace.

ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.5-2.4.0-test10.gz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I just recompiled using the JE driver and it doesn't lock up on boot.

-d

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

If you have the time, could you please do the debugging steps that Keith Owens just listed. It might enable us to determine what is wrong with the usb-uhci.o driver (the JE driver doesn't work with all devices right now, so we are still dependent on usb-uhci.o).

thanks,

greg k-h

greg@(kroah|wirex).com
http://immunix.org/~greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I am going thru the steps atm. The JE driver also hangs.

More information. I have an external USB 4 port hub, in which I have one logitech mouse at the moment. I can cold boot and reboot to my heart's delight fine. But if I unplug/plug in the mouse and reboot, it will hang. Note, I have to unplug and plug back in the mouse to get it recognized by the system before I can use it.

So we're probably looking at something other than the uhci/je driver.

-d

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Thanks for doing this.

Is the external hub a externally powered hub, or self powered hub (does it get it's power from a plug in the wall, or from the USB bus)? Self powered hubs are notoriously flaky and have been known to do evil things to the USB bus.

thanks,

greg k-h

greg@(kroah|wirex).com
http://immunix.org/~greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

np.

Either. Currently bus (self) powered. This hub has worked fine on my other computers without any adverse affect.

I've stepped through w/ kdb and found some more info. I'm not experience enough with kdb to provide more details, my apologies.

usb_uhci():2952
start_uhci():2896
pci_write_config_word():

[kdb output trimmed]
pci_write_config_word+0x29: call *%eax
pci_conf1_write_config_word: pushl %ebp

  +0x1:   movl   %esp,%ebp
  +0x3:   pushl  %esi
  +0x4:   pushl  %ebx
  +0x5:   movl   0x8(%ebp),%edx
  +0x8:   movl   0xc(%ebp),%ecx
  +0xb:   movl   0x10(%ebp),%esi
  +0xe:   movl   0x10(%edx),%eax
  +0x11:   movzbl 0x3c(%eax),%ebx
  +0x15:   movl   0x20(%edx),%eax
  +0x18:   shll   $0x10,%ebx
  +0x1b:   shll   $0x8,%eax
  +0x1e:   movl   $0xcf8,%edx
  +0x23:   orl    $0x80000000,%eax
  +0x28:   orl    %eax,%ebx
  +0x2a:   movl   %ecx,%eax
  +0x2c:   andb   $0xfc,%al
  +0x2e:   orl    %eax,%ebx
  +0x30:   movl   %ebx,%eax
  +0x32:   outl   %eax,(%dx)
  +0x32:   outl   %eax,(%dx)
  +0x33:   movl   %ecx,%edx
  +0x35:   movl   %esi,%eax
  +0x37:   andl   $0x2,%edx
  +0x3a:   orl    $0xcfc,%edx
  +0x40:   outw   %ax,(%dx)

And here is where it hangs.

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

More data:

kdb> bp pci_conf1_write_config_word+0x3a
Instruction(i) BP #1 at 0xc01100f2 (pci_conf1_write_config_word+0x3a)
is enabled globally adjust 1
kdb> go
Instruction(i) breakpoint #1 at 0xc01100f2 (adjusted)
0xc01100f2 pci_conf1_write_config_word+0x3a: orl $0xcfc,%edx

Entering kdb (current=0xcfff4000, pid 1) due to Breakpoint @ 0xc01100f2 kdb> ss
0xc01100f2 pci_conf1_write_config_word+0x3a: orl $0xcfc,%edx
SS trap at 0xc01100f8 (pci_conf1_write_config_word+0x40)
0xc01100f8 pci_conf1_write_config_word+0x40: outw %ax,(%dx)
kdb> rd
eax = 0x00002000 ebx = 0x800022c0 ecx = 0x000000c0 edx = 0x00000cfc esi = 0x00002000 edi = 0xc144c800 esp = 0xcfff5f68 eip = 0xc01100f8 ebp = 0xcfff5f70 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00000006 xds = 0xcfff0018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xcfff5f34

-d

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Sigh. That's not the real hang position. I needed to step slower.

kdb> ss
0xc01100f8 pci_conf1_write_config_word+0x40: outw %ax,(%dx)
SS trap at 0xc01100fa (pci_conf1_write_config_word+0x42)
0xc01100fa pci_conf1_write_config_word+0x42: popl %ebx
kdb> ss
0xc01100fa pci_conf1_write_config_word+0x42: popl %ebx
SS trap at 0xc01100fb (pci_conf1_write_config_word+0x43)
0xc01100fb pci_conf1_write_config_word+0x43: xorl %eax,%eax
kdb> ss
0xc01100fb pci_conf1_write_config_word+0x43: xorl %eax,%eax
SS trap at 0xc01100fd (pci_conf1_write_config_word+0x45)
0xc01100fd pci_conf1_write_config_word+0x45: popl %esi
kdb> ss
0xc01100fd pci_conf1_write_config_word+0x45: popl %esi
SS trap at 0xc01100fe (pci_conf1_write_config_word+0x46)
0xc01100fe pci_conf1_write_config_word+0x46: movl %ebp,%esp
kdb> ss
0xc01100fe pci_conf1_write_config_word+0x46: movl %ebp,%esp
SS trap at 0xc0110100 (pci_conf1_write_config_word+0x48)
0xc0110100 pci_conf1_write_config_word+0x48: popl %ebp
kdb> ss
0xc0110100 pci_conf1_write_config_word+0x48: popl %ebp
SS trap at 0xc0110101 (pci_conf1_write_config_word+0x49)
0xc0110101 pci_conf1_write_config_word+0x49: ret
kdb> ss
0xc0110101 pci_conf1_write_config_word+0x49: ret
SS trap at 0xc020c7af (pci_write_config_word+0x2b)
0xc020c7af pci_write_config_word+0x2b: pushl %ebx
kdb> ss
0xc020c7af pci_write_config_word+0x2b: pushl %ebx
SS trap at 0xc020c7b0 (pci_write_config_word+0x2c)
0xc020c7b0 pci_write_config_word+0x2c: popf
kdb> ss
0xc020c7b0 pci_write_config_word+0x2c: popf

Here is where it hung this time. Register dump below.

usb-uhci.c: $Revision: 1.242 $ time 20:13:32 Nov 8 2000 usb-uhci.c: High bandwidth mode enabled Instruction(i) breakpoint #0 at 0xc03f5a8c (adjusted)
0xc03f5a8c start_uhci: pushl %ebp

Entering kdb (current=0xcfff4000, pid 1) due to Breakpoint @ 0xc03f5a8c kdb> bp pci_write_config_word+0x2c
Instruction(i) BP #1 at 0xc020c7b0 (pci_write_config_word+0x2c)
is enabled globally adjust 1
kdb> g
Instruction(i) breakpoint #1 at 0xc020c7b0 (adjusted)
0xc020c7b0 pci_write_config_word+0x2c: popf

Entering kdb (current=0xcfff4000, pid 1) due to Breakpoint @ 0xc020c7b0 kdb> rd
eax = 0x00000000 ebx = 0x00000256 ecx = 0x000000c0 edx = 0x00000cfc esi = 0x000000c0 edi = 0xc144c800 esp = 0xcfff5f74 eip = 0xc020c7b0 ebp = 0xcfff5f90 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00000046 xds = 0xc1440018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xcfff5f40

0xc020c7aa pci_write_config_word+0x26:   movl   0x10(%edx),%eax
0xc020c7ad pci_write_config_word+0x29:   call   *%eax
0xc020c7af pci_write_config_word+0x2b:   pushl  %ebx
0xc020c7b0 pci_write_config_word+0x2c:   popf
0xc020c7b1 pci_write_config_word+0x2d:   jmp    0xc020c7bc
pci_write_config_word+0x38
0xc020c7b3 pci_write_config_word+0x2f:   nop
0xc020c7b4 pci_write_config_word+0x30:   movl   $0x87,%eax
0xc020c7b9 pci_write_config_word+0x35:   leal   0x0(%esi),%esi
0xc020c7bc pci_write_config_word+0x38:   leal   0xfffffff4(%ebp),%esp

I'm going to have to drop this debug shortly and return to my regular work :(

-d

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard