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'."
>>>>> "DF" == David Ford <[email protected]> writes:
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...
On Wed, 08 Nov 2000 16:35:36 -0800,
David Ford <[email protected]> wrote:
>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>
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
I just recompiled using the JE driver and it doesn't lock up on boot.
-d
Georg Nikodym wrote:
> >>>>> "DF" == David Ford <[email protected]> writes:
>
> 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...
--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."
On Wed, Nov 08, 2000 at 05:27:29PM -0800, David Ford wrote:
> I just recompiled using the JE driver and it doesn't lock up on boot.
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
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
Greg KH wrote:
> 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).
--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."
On Wed, Nov 08, 2000 at 08:19:13PM -0800, David Ford wrote:
> I am going thru the steps atm. The JE driver also hangs.
Thanks for doing this.
> 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.
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
> The NMI oopser for UP only trips in when the cpu is spinning. If the
> cpu is in a halt state then NMI does not run. But in a halt state you
> should be able to activate kdb via the pause key. The only time you
> cannot get kdb via pause is if interrupts are disabled (but then the
> cpu should be spinning and NMI should kick in) or if the cpu or
> motherboard is totally wedged.
just a quick followup while i'm working at it. the hardware is totally
hung, nothing gets to it, keyboard, serial, or nmi.
being there are a lot of usb functions, does anyone have some suggested
breakpoints?
-d
--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."
Greg KH wrote:
> On Wed, Nov 08, 2000 at 08:19:13PM -0800, David Ford wrote:
> > I am going thru the steps atm. The JE driver also hangs.
>
> Thanks for doing this.
np.
> > 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.
>
> 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.
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'."
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 ®s = 0xcfff5f34
-d
--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."
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 ®s = 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'."
> From: David Ford [mailto:[email protected]]
>
[snip]
> > 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
> > evil things to the USB bus.
>
> Either. Currently bus (self) powered. This hub has worked
> fine on my other
> computers without any adverse affect.
Bus-powered != self-powered.
Self-powered means that it has its own power cord.
Bus-powered means that it gets its power from the USB cable.
Unlike Greg, I would have said that bus-powered hubs
can be a problem -- especially when you plug too many
devices into them that need lots of power. What we saw
at the USB PlugFest was hubs just shutting down when
we did this. :(
~Randy
On Thu, Nov 09, 2000 at 09:06:31AM -0800, Dunlap, Randy wrote:
>
> Bus-powered != self-powered.
>
> Self-powered means that it has its own power cord.
>
> Bus-powered means that it gets its power from the USB cable.
You're right, I used the wrong terms (but used the correct
descriptions). I meant that "bus-powered" hubs are flaky and have
problems, like Randy said.
Sorry any confusion this might have caused.
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
"Dunlap, Randy" wrote:
> > Either. Currently bus (self) powered. This hub has worked
> > fine on my other
> > computers without any adverse affect.
>
> Bus-powered != self-powered.
It had been a long day. I really do know the distinction :)
It is currently bus powered and I've only once had it self powered
several months ago. It is an SIIG 4 port hub, I hadn't seen any
complaints about it doing a web search when I looked, so I purchased it.
I have found that after unplug/plug the mouse and reboot, If I unplug
the hub then the boot will continue fine, if I unplug the just the mouse
(which is plugged into the hub), the machine will indeed hang. If I
reset the power on the hub and plug it back in it will still hang.
I must reset the power on the motherboard.
The oddity is that kdb shows the machine to lock up on the popf in
pci_conf_write_word()+0x2c. I never did get around to digging up this
routine and looking at the code, but I suspect this is a final return
from the routine. I'm rather confused however, I have no idea why a
flags pop would hang the hardware.
-d
--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."
In article <[email protected]>, David Ford <[email protected]> wrote:
>
>The oddity is that kdb shows the machine to lock up on the popf in
>pci_conf_write_word()+0x2c. I never did get around to digging up this
>routine and looking at the code, but I suspect this is a final return
>from the routine. I'm rather confused however, I have no idea why a
>flags pop would hang the hardware.
Educated guess: it enables interrupts, after it has done something to
the hardware that causes an infinite stream of them.
Linus
David Ford <[email protected]> writes:
> The oddity is that kdb shows the machine to lock up on the popf in
> pci_conf_write_word()+0x2c. I never did get around to digging up this
> routine and looking at the code, but I suspect this is a final return
> from the routine. I'm rather confused however, I have no idea why a
> flags pop would hang the hardware.
I've got a machine here that locks solid every time with -test10. It
locks up towards the end of start_uhci, where it calls:
----
/* disable legacy emulation */
pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
----
Now, disabling this call seems to make the system work perfectly. The
machine is a Celeron 500 / Asus P3B-F (I think, it's at the office).
Also -test8 works, I haven't tried any of the test11-pre* versions yet.
Any things I should try to test? (Please CC me, as I don't have the
time to follow linux-kernel as closely as I would like at the moment.)
-Harald
--
Harald Nordg?rd-Hansen, Linpro AS <>< http://www.linpro.no/~hnh/
PB. 375, N-1601 Fredrikstad, Norway Phone/Fax: +47 6935 2424/25