Bug 4944 - uhci_hcd hangs on intel 810 when attaching any USB device
Summary: uhci_hcd hangs on intel 810 when attaching any USB device
Status: REJECTED INSUFFICIENT_DATA
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Alan Stern
URL:
Keywords:
Depends on:
Blocks: USB
  Show dependency tree
 
Reported: 2005-07-26 05:40 UTC by Igor Rondarev
Modified: 2006-01-03 11:31 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.12.2
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Prevent UHCI auto-suspend (329 bytes, patch)
2005-07-29 14:09 UTC, Alan Stern
Details | Diff
Trace UHCI hang (1.45 KB, patch)
2005-08-01 12:05 UTC, Alan Stern
Details | Diff
Boot log from serial console (37.05 KB, text/plain)
2005-09-12 08:52 UTC, Mark Broadbent
Details
Kernel boot messages from v2.6.12.3 (184.44 KB, text/plain)
2005-09-13 02:09 UTC, Mark Broadbent
Details
Kernel boot messages from v2.6.13.1 (1) (126.59 KB, text/plain)
2005-09-13 02:12 UTC, Mark Broadbent
Details
Kernel boot messages from v2.6.13.1 (2) (94.10 KB, text/plain)
2005-09-13 02:14 UTC, Mark Broadbent
Details
v2.6.12.3 kernel log (28.34 KB, text/plain)
2005-09-13 02:29 UTC, Mark Broadbent
Details
v2.6.13.1 - resume detect interrupt are broken - return 1 (33.17 KB, text/plain)
2005-09-13 02:31 UTC, Mark Broadbent
Details
v2.6.13.1 - any_ports_active - return 1 (32.98 KB, text/plain)
2005-09-13 02:32 UTC, Mark Broadbent
Details
Linux 2.6.14-rc2 boot logs (46.74 KB, text/plain)
2005-09-22 05:19 UTC, Mark Broadbent
Details

Description Igor Rondarev 2005-07-26 05:40:10 UTC
Distribution: Trustix Secure Linux 3.0 with 
recompiled 2.6.12.2 kernel (GCC 
Hardware Environment:
SOYO SY-7IWB 1.0 Motherboard
(Intel 810 chipset, Intel Celeron 433 Mendocino CPU)
192MB RAM
Software Environment:
Clean TSL 3.0 distribution with 2.6.12.2 kernel
Problem Description:
When a new USB 1.1 device attached (i've tested on USB mouse 
and USB flash drive), kernel immediately hangs at all without any log messages.
When i boot my system with USB mouse already attached, everything (Xorg+TWM,for 
example)works fine, so the problem have place only when some device is inserted 
in USB port for the first time after booting. It doesn't matter whether uhci_hcd 
is compiled as a module or a kernel built-in driver.

System configuration (with USB mouse attached before boot):
lspci -vvv:
00:00.0 Host bridge: Intel Corporation 82810 GMCH [Graphics Memory Controller 
Hub] (rev 03)
	Subsystem: Intel Corporation 82810 GMCH [Graphics Memory Controller Hub]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort+ >SERR- <PERR-
	Latency: 0

00:01.0 VGA compatible controller: Intel Corporation 82810 CGC [Chipset Graphics 
Controller] (rev 03) (prog-if 00 [VGA])
	Subsystem: Intel Corporation 82810 CGC [Chipset Graphics Controller]
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at e0000000 (32-bit, prefetchable) [disabled] [size=64M]
	Region 1: Memory at e4000000 (32-bit, non-prefetchable) [disabled] 
[size=512K]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,
D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if 00 
[Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: d8000000-dfffffff
	Prefetchable memory behind bridge: fff00000-000fffff
	Secondary status: 66Mhz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- 
<MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
	Latency: 0

00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80 
[Master])
	Subsystem: Intel Corporation 82801AA IDE
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
	Latency: 0
	Region 4: I/O ports at f000 [size=16]

00:1f.2 USB Controller: Intel Corporation 82801AA USB (rev 02) (prog-if 00 
[UHCI])
	Subsystem: Intel Corporation 82801AA USB
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin D routed to IRQ 15
	Region 4: I/O ports at d000 [size=32]

01:01.0 Ethernet controller: 3Com Corporation 3c900 10Mbps Combo [Boomerang]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
	Latency: 32 (750ns min, 2000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at c000 [size=64]
	Expansion ROM at dc000000 [disabled] [size=64K]

01:02.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01) (prog-if 00 
[VGA])
	Subsystem: S3 Inc. ViRGE/DX
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ ParErr- 
Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
	Latency: 32 (1000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at d8000000 (32-bit, non-prefetchable) [size=64M]

/proc/interrupts: (both kernel and BIOS have ACPI support disabled)
           CPU0       
  0:     143798          XT-PIC  timer
  1:        206          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:        163          XT-PIC  eth0
  8:          1          XT-PIC  rtc
 14:      55193          XT-PIC  ide0
 15:         25          XT-PIC  uhci_hcd:usb1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

(secondary IDE controller is also disabled, so USB uses IRQ 15)

dmesg (exactly after boot):
Linux version 2.6.12.2 (root@my.system) (gcc version 3.4.4 (Trustix)) #1 Wed Jul 
27 06:16:22 MSD 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000bf00000 (usable)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
191MB LOWMEM available.
On node 0 totalpages: 48896
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 44800 pages, LIFO batch:15
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
Allocating PCI resources starting at 0bf00000 (gap: 0bf00000:f3c00000)
Built 1 zonelists
Kernel command line: ro root=/dev/hda1
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (0117f000)
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 434.448 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 190288k/195584k available (1920k kernel code, 4848k reserved, 782k data, 
160k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 854.01 BogoMIPS (lpj=427008)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000 00000000 
00000000 00000000
CPU: After vendor identify, caps: 0183f9ff 00000000 00000000 00000000 00000000 
00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040 00000000 
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Celeron (Mendocino) stepping 05
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb2c0, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:01:02.0
PCI: Transparent bridge - 0000:00:1e.0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
Real Time Clock Driver v1.12
hw_random hardware driver 1.0.0 loaded
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Probing IDE interface ide0...
hda: FUJITSU M1623TAU, ATA DISK drive
hdb: HL-DT-ST CD-ROM GCR-8522B, ATAPI CD/DVD-ROM drive
Probing IDE interface ide1...
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide4...
Probing IDE interface ide5...
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 3324996 sectors (1702 MB) w/128KiB Cache, CHS=3298/16/63
hda: cache flushes not supported
 hda: hda1 hda2
hdb: ATAPI 52X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 160k freed
input: AT Translated Set 2 keyboard on isa0060/serio0
EXT3 FS on hda1, internal journal
Adding 124984k swap on /dev/hda2.  Priority:-1 extents:1
USB Universal Host Controller Interface driver v2.2
PCI: Setting latency timer of device 0000:00:1f.2 to 64
uhci_hcd 0000:00:1f.2: Intel Corporation 82801AA USB
uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1f.2: irq 15, io base 0x0000d000
uhci_hcd 0000:00:1f.2: detected 2 ports
usb usb1: default language 0x0409
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Intel Corporation 82801AA USB
usb usb1: Manufacturer: Linux 2.6.12.2 uhci_hcd
usb usb1: SerialNumber: 0000:00:1f.2
usb usb1: hotplug
usb usb1: adding 1-0:1.0 (config #1, interface 0)
usb 1-0:1.0: hotplug
hub 1-0:1.0: usb_probe_interface
hub 1-0:1.0: usb_probe_interface - got id
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
hub 1-0:1.0: standalone hub
hub 1-0:1.0: no power switching (usb 1.0)
hub 1-0:1.0: individual port over-current protection
hub 1-0:1.0: power on to power good time: 2ms
hub 1-0:1.0: local power source is good
hub 1-0:1.0: state 5 ports 2 chg 0000 evt 0000
uhci_hcd 0000:00:1f.2: port 1 portsc 01a3,00
hub 1-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
usb 1-1: new low speed USB device using uhci_hcd and address 2
usb 1-1: skipped 1 descriptor after interface
usb 1-1: new device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: hotplug
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
usb 1-1:1.0: hotplug
usbhid 1-1:1.0: usb_probe_interface
usbhid 1-1:1.0: usb_probe_interface - got id
input: USB HID v1.00 Mouse [0430:0100] on usb-0000:00:1f.2-1
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:01:01.0: 3Com PCI 3c900 Boomerang 10Mbps Combo at 0xc000. Vers LK1.1.19
eth0: Dropping NETIF_F_SG since no checksum feature.
NET: Registered protocol family 10
Disabled Privacy Extensions on device c036eac0(lo)
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present

dmesg (part of dmesg output when i disconnect mouse):

hub 1-0:1.0: state 5 ports 2 chg 0000 evt 0002
uhci_hcd 0000:00:1f.2: port 1 portsc 008a,00
hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
usb 1-1: USB disconnect, address 2
usb 1-1: usb_disable_device nuking all URBs
usb 1-1: unregistering interface 1-1:1.0
usb 1-1:1.0: hotplug
usb 1-1: unregistering device
usb 1-1: hotplug
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
uhci_hcd 0000:00:1f.2: suspend_hc

At this moment, if i try to connect it back to USB port, system hangs.
So, only possible variant to connect USB device when system is already booted is 
to `modprobe -r uhci_hcd`, attach device and then `modprobe -v uhci_hcd`

Steps to reproduce:
Boot a system with and without USB 1.1 devices connected
Attach some USB 1.1 device and see dmesg messages
Comment 1 Andrew Morton 2005-07-29 01:38:21 UTC
Has there been any progress with this?

Are you able to test 2.6.13-rc4?

Thanks.
Comment 2 Igor Rondarev 2005-07-29 02:47:45 UTC
As far as i can understand from prepatch description, i cannot use 2.6.13-rc4
at this moment because i'm using 2.6.12.2, not 2.6.12 kernel.
Seems 2.6.13 will come rather soon, so i'll wait for it and certainly
will try it.
Maybe i should post some additional system information here (not only dmesg and 
interrupts), is it necessary?
Thanks in advance!
Igor
Comment 3 Andrew Morton 2005-07-29 03:12:53 UTC
hm, why can't you use 2.6.13-rc4?  It's right here:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.13-rc4.tar.bz2
We'd really prefer that you check that this bug is fixed before we release
2.6.13: we don't want to be releasing a kernel with unresolved bugs.

The problem might be already fixed, so there isn't much point in doing
extra debugging work on an old kernel.  If the bug happens on 2.6.13-rc4
then please try to capture the output of alt-sysrq-T when it has hung.  You
should check that alt-sysrq-T works correctly before making it hang - you
might need to do `echo 1 > /proc/sysrq' first.

Thanks.

Comment 4 Igor Rondarev 2005-07-29 06:02:20 UTC
Unfortunately, 2.6.12+2.6.13-rc4 patch have the same problem, PC hangs
when i reattach USB mouse. Furthermore, Alt+SysRq+T works before hang (i can see
a lot of dmesg messages after it), but when PC hangs, it doesn't work at all.
What do you recommend to do now?
With best regards,
Igor.
Comment 5 Igor Rondarev 2005-07-29 06:03:30 UTC
PS my keyboard is PS/2, so i have no other devices on USB bus.
Comment 6 Andrew Morton 2005-07-29 11:13:15 UTC
OK, thanks.

Are you able to identify an earlier 2.6.x kernel which didn't have
this bug?

Comment 7 Alan Stern 2005-07-29 14:09:09 UTC
Created attachment 5411 [details]
Prevent UHCI auto-suspend

Someone else recently reported a hardware problem in which the entire computer
would hang whenever the UHCI controller resumed from a suspended state.  Maybe
the same sort of thing is happening to you.  The patch in the attachment (for
2.6.13-rc4) will prevent the driver from suspending the controller.  See if it
stops your problem.
Comment 8 Igor Rondarev 2005-07-31 23:52:34 UTC
And you are absolutely right! This patch fixes my problem too: now i don't
see dmesg "suspend_hc" message, and i can disconnect and reconnect USB devices
without any problems/hangs. Thanks a lot!
So the problem is really with suspending hc. Hmm, not exactly with suspending,
but with "wake-up"'ing hc. Wish you luck in solving this issue!
With best regards,
Igor 
Comment 9 Andrew Morton 2005-08-01 00:01:16 UTC
But 2.6.12.x worked correctly, did it not?

How can this be a hardware problem?
Comment 10 Igor Rondarev 2005-08-01 00:28:30 UTC
On my machine, i've used/tested following kernels:
2.6.11.12-6tr (native in TrustixSecureLinux 3.0 distribution)
2.6.11.?(don't remember, it was Knoppix 3.8.2 LiveCD)
2.6.12.2 (www.kernel.org)
2.6.12 (2.6.13-rc4 patched, www.kernel.org)
And all of them have this bug.
As for hardware, unfortunately i'm not a big expert in hardware. But if i 
can help you in tracing this bug, just tell me what to do.
Comment 11 Alan Stern 2005-08-01 12:05:18 UTC
Created attachment 5462 [details]
Trace UHCI hang

This patch may help track down exactly where the hang occurs.  (Or again, it
might not...  You'll have to try it and see.)

Be sure to remove the previous patch first; otherwise your system won't hang! 
When you try this patch, use a regular console screen (not an X window) so you
can see the kernel messages as they appear.  Plug in the mouse, and make a note
of the last few messages that show up before the system stops working.
Comment 12 Igor Rondarev 2005-08-02 05:22:00 UTC
Currently, syslog is responsible for redirecting kern.* to /dev/console on my 
machine, so i don't see any messages when PC hangs. I've have almost no 
experience in kernel message processing exept syslogging them, but as far as i 
can understand syslog damon just have no time to process messages when system 
hangs. So, how can i see kernel messages immediately and without syslog (when i 
have kern.* commented, i see no messages at all)? Maybe it's a silly question, 
but, as i said before, i just have no experience in such tasks.
Comment 13 Alan Stern 2005-08-02 07:43:57 UTC
In addition to the syslog daemon reading the kernel log messages, those messages
are all printed on the system console provided they have sufficiently high
priority.  The messages in my patch are logged at ERROR priority, which will
indeed be sufficiently high unless you have changed the default priority cutoff
for console message logging (the first number in /proc/sys/kernel/printk).  You
can always set the cutoff so that all messages are printed on the console by
doing "echo 9 >/proc/sysrq-trigger".

These messages will show up on a regular console screen regardless of the syslog
settings -- even if syslogd isn't running.
Comment 14 Igor Rondarev 2005-08-02 23:40:56 UTC
Ok, i've set 9 to sysrq-trigger, and i see messages when i disconnect USB 
device, but still nothing when i reconnect it (system hangs). Maybe i'll try
to trace it by myself, so i have a question:
in what order functions from uchi-hcd.c (and included uhci-hub.c and so on) are 
executed after receiving interrupt from USB controller when a new device is 
connected? maybe we shold add more breakpoint errors in source code?
Comment 15 Alan Stern 2005-08-03 07:20:04 UTC
I doubt that adding more breakpoints will help -- I suspect your system hangs
before the interrupt request is dispatched to the UHCI driver -- but go ahead
and try, I could be wrong.

When a device is plugged in to a suspended controller, the IRQ is first sent to
uhci_hcd.c:uhci_irq().  It's possible that a printk at the start of that routine
will show something useful.  The value of "status" will be of particular interest.

From there control passes to drivers/usb/core/hcd.c:usb_hcd_poll_rh_status(),
which calls uhci_hub.c:uhci_hub_status_data(), which calls uhci_hcd.c:wakeup_rh().

Another thing you can try is testing whether polling works better than
interrupts.  Add a "return 1;" statement at the start of
uhci_hcd.c:resume_detect_interrupts_are_broken().  That will allow the driver to
suspend the controller when no devices are plugged in, but will cause the driver
to poll for new devices instead of using interrupts.  If your problem occurs
during the early stages of interrupt handling, perhaps this will bypass it.
Comment 16 Fran 2005-08-06 06:09:57 UTC
I have the same problem, as described by the first person. Total system hang on
plug only happens when uhci_hcd is loaded (any USB device).
I had the problem on 2.6.0, 2.6.12, 2.6.13-rc4 (not tested other versions). No
such hang with 2.4 kernels.
The patch "Prevent UHCI auto-suspend" resolves the problem.
My motherboard : msi 6309 (v1), chipset via vt82x694x/vt82c686a.
I added printk() messages with very high priority in
uhci-hub.c:any_ports_active() and uhci-hub.c:uhci_hub_status_data() on patch
2.6.13-rc4 but can't see anything on plug (is printk() buffered ?).
Comment 17 Alan Stern 2005-08-06 09:21:48 UTC
printk's console output is not buffered.  But when you plug in a new device,
uhci-hcd first learns about it in the uhci_irq() routine.  That's where you
should monitor for activity.

You can also try doing that test I suggested in comment #15: move the "return
1;" statement from any_ports_active() to resume_detect_interrupts_are_broken().
Comment 18 Fran 2005-09-12 03:32:05 UTC
I have tested kernel 2.6.13, the problem is still here (but I don't know if it
was  supposed to be solved :-) ).
The "Prevent UHCI auto-suspend"-like solution still works fine (add return 1; in
the right function).

Fran
Comment 19 Alan Stern 2005-09-12 08:15:13 UTC
No, the problem is not supposed to have been solved yet.  I'm still waiting to
hear from someone whether it's necessary to prevent suspending at all or whether
it's sufficient to avoid the resume-detect interrupt (see comment #17).
Comment 20 Mark Broadbent 2005-09-12 08:52:33 UTC
Created attachment 5980 [details]
Boot log from serial console

I am having the same problems as described on a vanilla 2.6.13.1 kernel
compiled with gcc 3.3 (m/b is Intel 865).  I have attached a bootlog that has
the 'Trace UHCI hang' patch applied plus a one liner that outputs 'status' in
uhci_hcd.c:uhci_irq().

More information can be supplied on request
Comment 21 Alan Stern 2005-09-12 09:22:00 UTC
Mark, your log only shows that you booted with an external hub attached, with a
keyboard and a mouse plugged into the hub.  (And incidentally, why isn't the
mouse plugged into the keyboard instead of into the external hub?)  There's no
indication of any problem.  Did your system crash, and did this occur when you
plugged in another USB device?

It would help if you turn on CONFIG_USB_DEBUG.  Does the "Prevent UHCI
auto-suspend" patch fix the problem?  What happens if you move the "return 1;"
statement from the beginning of any_ports_active() to the beginning of
resume_detect_interrupts_are_broken()?
Comment 22 Mark Broadbent 2005-09-12 09:39:25 UTC
Sorry, I should have said that my computer freezes at the point the debug log
stops, there's usually a lot more USB output after this point (can be supplied
if required).  This occurs whilst the USB modules are being inserted at boot
time by udev (the keyboard and mouse are connected all the time, no
[dis]connecting is being done).  Also, this problem does not occur in 2.6.12.

USB debug is enabled, from my .config:
CONFIG_USB_DEBUG=y

As suggested in comment #15 I added the following patch to
uhci_hcd.c:resume_detect_interrupts_are_broken():

--- linux-2.6.13.orig/drivers/usb/host/uhci-hcd.c       2005-09-12
16:18:47.000000000 +0100
+++ linux-2.6.13/drivers/usb/host/uhci-hcd.c    2005-09-12 17:13:11.000000000 +0100
@@ -236,6 +236,7 @@
 static int resume_detect_interrupts_are_broken(struct uhci_hcd *uhci)
 {
        int port;
+       return 1;

        switch (to_pci_dev(uhci_dev(uhci))->vendor) {
            default:

However the PC freezes at the same point as in comment #20.

Lastly, to why is my mouse not plugged into my keyboard.  It is simply the
neatest and most convinient way to arrange the wires on my desk. :-)
Comment 23 Neil Watson 2005-09-12 09:53:28 UTC
Hi, I had the same symptoms.  Freeze on usb plug in.  Patching 2.6.13.1 with
"Prevent UHCI auto-suspend" prevented the freeze.

I have the Gigabyte GA-6VXC7-4X motherboard. I hope this is useful.

00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 10)
00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:0b.0 Ethernet controller: Accton Technology Corporation EN-1216 Ethernet
Adapter (rev 11)
00:0d.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 08)
01:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2 GTS/Pro]
(rev a3)
Comment 24 Alan Stern 2005-09-12 11:38:51 UTC
Mark:

"I should have said that my computer freezes at the point the debug log
stops, there's usually a lot more USB output after this point" -- if your
computer freezes, how can there be a lot more USB output?  Do you mean that in
2.6.12 the output would continue?

Your log did not include the debugging messages that CONFIG_USB_DEBUG would
generate.  Probably your logging was configured to ignore debug-level messages;
that is the default condition.  Try booting with the word "debug" on the boot
command line.

If you add the "return 1;" statement to the start of any_ports_active() instead,
does the computer still crash?

Neil:

What happens if you move the "return 1;" statement from the start of
any_ports_active() to the start of resume_detect_interrupts_are_broken()?
Comment 25 Neil Watson 2005-09-12 19:01:05 UTC
If I run with return 1 in any_ports_active() - no freeze

If I run with return 1 in resume_detect_interrupts_are_broken() - freeze

If I run with the trace UHCI hang patch (and without the return 1 statements) -
freeze (as expected).

Here is the logs from the /var/log/messages.  I ran the test multiple times.

Sep 13 01:51:11 aopen kernel: uhci_hcd 0000:00:07.2: wakeup_rh (auto-start)
Sep 13 01:51:11 aopen kernel: uhci_hcd 0000:00:07.2: start_rh A
Sep 13 01:51:11 aopen kernel: uhci_hcd 0000:00:07.2: start_rh B
Sep 13 01:51:11 aopen kernel: uhci_hcd 0000:00:07.2: start_rh C
Sep 13 01:51:11 aopen kernel: uhci_hcd 0000:00:07.2: start_rh D
Sep 13 01:51:11 aopen kernel: usb 1-1: new full speed USB device using uhci_hcd
and address 6
Sep 13 01:51:11 aopen kernel: drivers/usb/media/stv680.c: [stv680_probe:1377]
STV(i): STV0680 camera found.
Sep 13 01:51:11 aopen kernel: drivers/usb/media/stv680.c: [stv680_probe:1419]
STV(i): registered new video device: video0
Sep 13 01:55:41 aopen syslogd 1.4.1: restart.

Sep 13 02:02:22 aopen kernel: uhci_hcd 0000:00:07.2: Resume detect
Sep 13 02:02:22 aopen kernel: uhci_hcd 0000:00:07.2: wakeup_rh (auto-start)
Sep 13 02:02:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh A
Sep 13 02:02:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh B
Sep 13 02:02:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh C
Sep 13 02:02:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh D
Sep 13 02:03:52 aopen syslogd 1.4.1: restart.

Sep 13 02:07:39 aopen kernel: uhci_hcd 0000:00:07.2: Resume detect
Sep 13 02:07:39 aopen kernel: uhci_hcd 0000:00:07.2: wakeup_rh (auto-start)
Sep 13 02:07:39 aopen kernel: uhci_hcd 0000:00:07.2: start_rh A
Sep 13 02:07:39 aopen kernel: uhci_hcd 0000:00:07.2: start_rh B
Sep 13 02:07:39 aopen kernel: uhci_hcd 0000:00:07.2: start_rh C
Sep 13 02:07:39 aopen kernel: uhci_hcd 0000:00:07.2: start_rh D
Sep 13 02:07:39 aopen kernel: usb 1-2: new full speed USB device using uhci_hcd
and address 3
Sep 13 02:07:39 aopen kernel: drivers/usb/media/stv680.c: [stv680_probe:1377]
STV(i): STV0680 camera found.
Sep 13 02:07:39 aopen kernel: drivers/usb/media/stv680.c: [stv680_probe:1419]
STV(i): registered new video device: video0
Sep 13 02:09:01 aopen syslogd 1.4.1: restart.

Sep 13 02:11:22 aopen kernel: uhci_hcd 0000:00:07.2: Resume detect
Sep 13 02:11:22 aopen kernel: uhci_hcd 0000:00:07.2: wakeup_rh (auto-start)
Sep 13 02:11:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh A
Sep 13 02:11:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh B
Sep 13 02:11:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh C
Sep 13 02:11:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh D
Sep 13 02:12:44 aopen syslogd 1.4.1: restart.

Sep 13 02:15:13 aopen kernel: uhci_hcd 0000:00:07.2: Resume detect
Sep 13 02:15:13 aopen kernel: uhci_hcd 0000:00:07.2: wakeup_rh (auto-start)
Sep 13 02:15:13 aopen kernel: uhci_hcd 0000:00:07.2: start_rh A
Sep 13 02:15:13 aopen kernel: uhci_hcd 0000:00:07.2: start_rh B
Sep 13 02:15:13 aopen kernel: uhci_hcd 0000:00:07.2: start_rh C
Sep 13 02:15:13 aopen kernel: uhci_hcd 0000:00:07.2: start_rh D
Sep 13 02:15:14 aopen kernel: usb 1-2: new full speed USB device using uhci_hcd
and address 2
Sep 13 02:16:42 aopen syslogd 1.4.1: restart.

Sep 13 02:19:20 aopen kernel: uhci_hcd 0000:00:07.2: Resume detect
Sep 13 02:19:20 aopen kernel: uhci_hcd 0000:00:07.2: wakeup_rh (auto-start)
Sep 13 02:19:20 aopen kernel: uhci_hcd 0000:00:07.2: start_rh A
Sep 13 02:19:20 aopen kernel: uhci_hcd 0000:00:07.2: start_rh B
Sep 13 02:19:20 aopen kernel: uhci_hcd 0000:00:07.2: start_rh C
Sep 13 02:19:20 aopen kernel: uhci_hcd 0000:00:07.2: start_rh D
Sep 13 02:19:20 aopen kernel: usb 1-2: new full speed USB device using uhci_hcd
and address 2
Sep 13 02:20:37 aopen syslogd 1.4.1: restart.

Sep 13 02:35:23 aopen kernel: uhci_hcd 0000:00:07.2: Resume detect
Sep 13 02:35:23 aopen kernel: uhci_hcd 0000:00:07.2: wakeup_rh (auto-start)
Sep 13 02:35:23 aopen kernel: uhci_hcd 0000:00:07.2: start_rh A
Sep 13 02:35:23 aopen kernel: uhci_hcd 0000:00:07.2: start_rh B
Sep 13 02:35:23 aopen kernel: uhci_hcd 0000:00:07.2: start_rh C
Sep 13 02:35:23 aopen kernel: uhci_hcd 0000:00:07.2: start_rh D
Sep 13 02:35:23 aopen kernel: usb 1-1: new full speed USB device using uhci_hcd
and address 2
Sep 13 02:36:46 aopen syslogd 1.4.1: restart.



It is interesting to note that *sometimes* the digital camerea driver had time
to load and a gnome desktop dialog appear, asking if I wanted to "Import photos
from camera".  Of course I could not click on the dialog as the system was frozen. 
Comment 26 Mark Broadbent 2005-09-13 02:07:44 UTC
Alan:

If you add the "return 1;" statement to the start of any_ports_active() instead,
does the computer still crash?

The computers still freezes at the same point.  I am going to attach log traces
for 2.6.12.3 which boots and works for me and for 2.6.13 all with full USB debug
traces enabled.
Comment 27 Mark Broadbent 2005-09-13 02:09:33 UTC
Created attachment 5984 [details]
Kernel boot messages from v2.6.12.3

The kernel debug log with verbose USB messages enabled (this works for me)
Comment 28 Mark Broadbent 2005-09-13 02:12:44 UTC
Created attachment 5985 [details]
Kernel boot messages from v2.6.13.1 (1)

Verbose USB kernel debug messages enabled.  This kernel has a return 1 in
resume_detect_interrupts_are_broken as per comment #22.
Comment 29 Mark Broadbent 2005-09-13 02:14:18 UTC
Created attachment 5986 [details]
Kernel boot messages from v2.6.13.1 (2)

Verbose USB kernel debug messages enabled.  This kernel has a return 1 in
any_ports_active() as per comment #24.
Comment 30 Mark Broadbent 2005-09-13 02:29:09 UTC
Created attachment 5987 [details]
v2.6.12.3 kernel log

Minicom seems to append to files that already exist.  Log messages split out.
Comment 31 Mark Broadbent 2005-09-13 02:31:03 UTC
Created attachment 5988 [details]
v2.6.13.1 - resume detect interrupt are broken - return 1

Minicom seems to append to files that already exist.  Log messages split out.
Comment 32 Mark Broadbent 2005-09-13 02:32:06 UTC
Created attachment 5989 [details]
v2.6.13.1 - any_ports_active - return 1

Minicom seems to append to files that already exist.  Log messages split out.
Comment 33 Alan Stern 2005-09-15 13:47:30 UTC
Mark:

Your attachments 5988 and 5989 show some surprising differences, considering
that they are supposed to be from essentially the same kernel running on the
same computer.  The amount of HIGHMEM and the ACPI settings are different, plus
a few other things.  Do you have any explanation?

Also, you say that 5988 has the return statement in RD-interrupts-broken, so it
should crash, while 5989 has the return statement in any-ports-active, so it
should not crash.  And yet both logs end at the same spot, in the middle of the
EHCI driver startup.  That's before the boot sequence has finished and before
you had a chance to plug in any new devices.  Even the 5987 log, with 2.6.12,
doesn't show you plugging in a new device.

For testing purposes, it would be best if you boot with no USB devices attached,
and then a few seconds after all the boot-up activity is finished you plug in a
single device.  It would be simplest also if the single device was your mouse or
the hub without the keyboard or anything else attached -- that way it really
will be just a _single_ device.  And it goes without saying that the log should
show what happens when you plug it in.

Incidentally, it wouldn't be at all suprising if it turns out that the cause of
your problem is some component other than the UHCI driver.  Maybe I'll try to
figure out a way for you to use the 2.6.12 driver in the 2.6.13 kernel or vice
versa; that should be informative.


Neil:

Your log indicated that the crashes occurred shortly after plugging in the STV
camera.  It's possible the camera driver has a bug.  Do you have a different USB
device you can test with instead of the camera?  Or can you turn off hotplugging
before you attach the camera, so that its driver isn't loaded automatically?
Comment 34 Neil Watson 2005-09-16 12:21:36 UTC
I plugged in my mobile phone, my usb disk and they all cause the freeze.

Here is the log

Sep 16 20:11:22 aopen kernel: uhci_hcd 0000:00:07.2: Resume detect
Sep 16 20:11:22 aopen kernel: uhci_hcd 0000:00:07.2: wakeup_rh (auto-start)
Sep 16 20:11:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh A
Sep 16 20:11:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh B
Sep 16 20:11:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh C
Sep 16 20:11:22 aopen kernel: uhci_hcd 0000:00:07.2: start_rh D
Sep 16 20:11:23 aopen kernel: usb 1-1: new full speed USB device using uhci_hcd
and address 7
Sep 16 20:13:20 aopen syslogd 1.4.1: restart.
Comment 35 Alan Stern 2005-09-16 13:24:21 UTC
Neil:

Your report is truly weird.  I think your problem is different from Mark's,
because your computer doesn't freeze right away.  I have no idea what could be
causing it.

Here's something you can both try.  For this test it shouldn't matter whether
you have the "return 1;" statement in there or not, but you will need to have
Power Management (CONFIG_PM) and USB suspend support (CONFIG_USB_SUSPEND)
enabled in the kernel configuration.

Plug in, say, the USB disk at boot time, but don't mount it.  Make a note of its
bus number as reported in the system log.  For example, "usb 1-2: new full speed
USB device using uhci_hcd and address 7" would indicate bus number 1; it's the
number before the '-'.  (You can also see this value listed in
/proc/bus/usb/devices as the "Bus=" value on the "T:" line for the device.) 
Then do "cd /sys/bus/usb/devices/usbN/power", where N is the bus number.

Once there, type (as root):

    echo -n 3 >state

At this point your system log should indicate the UHCI controller was suspended.
 Then do

    echo -n 0 >state

This should cause the controller to resume.  See if that makes your system freeze.

Then repeat the entire experiment, but this time with no USB devices plugged in.
 (Use the same bus number as before.)  Does the same thing happen?
Comment 36 Neil Watson 2005-09-16 17:37:41 UTC
If I set acpi=force on the kernel command line then the usb freeze problem does
not exist.

I can still try out what you suggested of you wish

Here are all the ACPI entries in my log file.

Sep 17 01:23:09 aopen kernel:  BIOS-e820: 0000000017ff0000 - 0000000017ff8000
(ACPI data)
Sep 17 01:23:09 aopen kernel:  BIOS-e820: 0000000017ff8000 - 0000000018000000
(ACPI NVS)
Sep 17 01:23:09 aopen kernel: ACPI: BIOS age (2000) fails cutoff (2001),
acpi=force is required to enable ACPI
Sep 17 01:23:09 aopen kernel: ACPI: acpi=force override
Sep 17 01:23:09 aopen kernel: ACPI: PM-Timer IO Port: 0x5008
Sep 17 01:23:09 aopen kernel: Kernel command line: ro
root=/dev/VolGroup00/LogVol00 rhgb quiet acpi=force
Sep 17 01:23:11 aopen kernel: ACPI: setting ELCR to 0800 (from 0a20)
Sep 17 01:23:11 aopen kernel: ACPI: bus type pci registered
Sep 17 01:23:11 aopen kernel: ACPI: Subsystem revision 20050408
Sep 17 01:23:11 aopen kernel: ACPI: Interpreter enabled
Sep 17 01:23:12 aopen kernel: ACPI: Using PIC for interrupt routing
Sep 17 01:23:12 aopen kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Sep 17 01:23:12 aopen kernel: ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
Sep 17 01:23:12 aopen kernel: ACPI: Power Resource [URP1] (off)
Sep 17 01:23:13 aopen kernel: ACPI: Power Resource [URP2] (off)
Sep 17 01:23:13 aopen kernel: ACPI: Power Resource [FDDP] (off)
Sep 17 01:23:13 aopen kernel: ACPI: Power Resource [LPTP] (off)
Sep 17 01:23:13 aopen kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9
10 11 12 14 15)
Sep 17 01:23:13 aopen kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9
10 11 12 14 15)
Sep 17 01:23:13 aopen kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9
10 11 12 14 15) *0, disabled.
Sep 17 01:23:13 aopen kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9
10 *11 12 14 15)
Sep 17 01:23:13 aopen kernel: pnp: PnP ACPI init
Sep 17 01:23:13 aopen kernel: pnp: PnP ACPI: found 10 devices
Sep 17 01:23:13 aopen kernel: PCI: Using ACPI for IRQ routing
Sep 17 01:23:14 aopen kernel: apm: overridden by ACPI.
Sep 17 01:23:15 aopen kernel: ACPI: CPU0 (power states: C1[C1])
Sep 17 01:23:15 aopen kernel: ACPI: Processor [CPU1] (supports 8 throttling states)
Sep 17 01:23:15 aopen kernel: ACPI: Thermal Zone [THRM] (33 C)
Sep 17 01:23:19 aopen kernel: ACPI wakeup devices:
Sep 17 01:23:19 aopen kernel: ACPI: (supports S0 S1 S4 S5)
Sep 17 01:23:20 aopen kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
Sep 17 01:23:20 aopen kernel: ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKD]
-> GSI 11 (level, low) -> IRQ 11
Sep 17 01:23:20 aopen kernel: ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
Sep 17 01:23:20 aopen kernel: ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKB]
-> GSI 5 (level, low) -> IRQ 5
Sep 17 01:23:20 aopen kernel: ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD]
-> GSI 11 (level, low) -> IRQ 11
Sep 17 01:23:23 aopen kernel: ACPI: Power Button (FF) [PWRF]
Sep 17 01:23:23 aopen kernel: ACPI: Power Button (CM) [PWRB]
Sep 17 01:23:23 aopen kernel: ACPI: Sleep Button (CM) [SLPB]
Sep 17 01:23:23 aopen kernel: ibm_acpi: ec object not found
Comment 37 Alan Stern 2005-09-18 14:14:52 UTC
So Neil, it looks like you're suffering from a BIOS problem.  I wouldn't be
surprised if the same thing is happening with Mark and Francois, although it
would have to be a different kind of BIOS problem.

Mark, have you checked to see if there are any BIOS upgrades available for your
motherboard?
Comment 38 Fran 2005-09-21 15:06:16 UTC
I never used ACPI but APM. For these tests, I removed APM from kernel and
compiled with ACPI.

BIOS configuration :
ACPI Standby state=S1/POS
Power Management/APM=Enabled

kernel configuration :
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
# CONFIG_ACPI_SLEEP is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_VIDEO is not set
# CONFIG_ACPI_HOTKEY is not set
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_SERIAL_8250_ACPI is not set

*** crash if :

- no patch applied and kernel boot option acpi=off
/proc/interrupts :
           CPU0
  0:      18412          XT-PIC  timer
  1:        187          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  EMU10K1
 10:         30          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, eth1
 11:         31          XT-PIC  eth0
 12:        458          XT-PIC  i8042
 14:       2924          XT-PIC  ide0
 15:         12          XT-PIC  ide1
NMI:          0
ERR:          0

*** no crash in all other cases, i.e. if :

- no patch applied and kernel boot option acpi=force
/proc/interrupts :
           CPU0
  0:      15326          XT-PIC  timer
  1:        175          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi, EMU10K1
 10:         24          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, eth1
 11:         25          XT-PIC  eth0
 12:        582          XT-PIC  i8042
 14:       2920          XT-PIC  ide0
 15:         25          XT-PIC  ide1
NMI:          0
ERR:          0

- no patch applied and kernel boot option acpi=noirq
/proc/interrupts :
           CPU0
  0:      57739          XT-PIC  timer
  1:        303          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi, EMU10K1
 10:        108          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, eth1
 11:        110          XT-PIC  eth0
 12:        538          XT-PIC  i8042
 14:       3067          XT-PIC  ide0
 15:         12          XT-PIC  ide1
NMI:          0
ERR:          0

- no patch applied and kernel no acpi boot option
/proc/interrupts :
           CPU0
  0:      16388          XT-PIC  timer
  1:        249          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi, EMU10K1
 10:         26          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, eth1
 11:         27          XT-PIC  eth0
 12:        110          XT-PIC  i8042
 14:       2938          XT-PIC  ide0
 15:         12          XT-PIC  ide1
NMI:          0
ERR:          0

- "return 1;" in any_ports active applied and kernel boot option acpi=off
/proc/interrupts :
           CPU0
  0:      25912          XT-PIC  timer
  1:        305          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  EMU10K1
 10:         42          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, eth1
 11:         43          XT-PIC  eth0
 14:       2977          XT-PIC  ide0
 15:         12          XT-PIC  ide1
NMI:          0
ERR:          0

- "return 1;" in any_ports active applied and kernel boot option acpi=force
/proc/interrupts :
           CPU0
  0:      13608          XT-PIC  timer
  1:        179          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi, EMU10K1
 10:         20          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, eth1
 11:         21          XT-PIC  eth0
 12:        110          XT-PIC  i8042
 14:       2903          XT-PIC  ide0
 15:         12          XT-PIC  ide1
NMI:          0
ERR:          0

- "return 1;" in any_ports active applied and kernel boot option acpi=noirq
/proc/interrupts :
           CPU0
  0:      20458          XT-PIC  timer
  1:        379          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi, EMU10K1
 10:         34          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, eth1
 11:         35          XT-PIC  eth0
 12:        110          XT-PIC  i8042
 14:       2969          XT-PIC  ide0
 15:         12          XT-PIC  ide1
NMI:          0
ERR:          0

- "return 1;" in any_ports active applied and kernel no acpi boot option
/proc/interrupts :
           CPU0
  0:      42130          XT-PIC  timer
  1:        467          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi, EMU10K1
 10:        103          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, eth1
 11:       3818          XT-PIC  eth0
 12:       1906          XT-PIC  i8042
 14:       7424          XT-PIC  ide0
 15:         25          XT-PIC  ide1
NMI:          0
ERR:          0

hope this helps... please tell me if other tests are necessary.

By the way, I can't see comments after #37 on bugzilla webpage, but I got them
by mail... ????
Comment 39 Mark Broadbent 2005-09-22 05:19:12 UTC
Created attachment 6088 [details]
Linux 2.6.14-rc2 boot logs

Boot logs from v2.6.14-rc2 which boots successfully!

First one is normal bootup with USB hub attached after boot up has completed,
second is with the USB hub attached before boot up started.

BTW, the motherboard is an Intel 865 chipset not VIA.
Comment 40 Alan Stern 2005-09-22 07:57:56 UTC
Fran
Comment 41 Alan Stern 2005-10-31 12:47:27 UTC
Does 2.6.14 solve everybody's problems?  Or does ACPI still need more work?
Comment 42 Mark Broadbent 2005-11-01 01:02:03 UTC
2.614 doesn't solve my problem, however, I can solve the problem by disabling
'Legacy USB Support' in the BIOS.  This is being tracked by bug #5433.

Thanks
Comment 43 Fran 2005-11-01 01:07:57 UTC
Hello,

2.6.14 doesn't change anything, i.e. crashes if acpi=off and no modification
done to any_ports_active(). does not crash in other cases.
As I use ACPI now, it is not big problem as it was before, but I'm still OK to
help and test things.
Comment 44 RaffigeRaffe 2005-11-28 05:15:19 UTC
Hello,
I got the same problem on only one of two *i810* machines.
The one in trouble is a machine called "BookPC". It has a 
standard i810 chipset with indicates a revision 01.
===========  lspci output =============================
0000:00:00.0 Host bridge: Intel Corp. 82810 GMCH [Graphics Memory Controller
Hub] (rev 02)
0000:00:01.0 VGA compatible controller: Intel Corp. 82810 CGC [Chipset Graphics
Controller] (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801AB PCI Bridge (rev 01)
0000:00:1f.0 ISA bridge: Intel Corp. 82801AB ISA Bridge (LPC) (rev 01)
0000:00:1f.1 IDE interface: Intel Corp. 82801AB IDE (rev 01)
0000:00:1f.2 USB Controller: Intel Corp. 82801AB USB (rev 01)
0000:01:04.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip
compatible 10/100 Ethernet (rev 10)
0000:01:05.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
0000:01:05.1 Communication controller: C-Media Electronics Inc CM8738 (rev 10)
==============================================================================

On this machine the last working kernel is 2.6.8.2-16 from the official
Debian Sarge 3.1r0a ( magazine Linux+Distro, 3 DVDs ). 


With the other one, a HP e-vectra I don't have any trouble at all using a self
compiled official kernel 2.6.14. In that one, a i810e chipset is built in.

===========  lspci output =============================
00:00.0 Host bridge: Intel Corp. 82810E DC-133 GMCH [Graphics Memory Controller
Hub] (rev 03)
00:01.0 VGA compatible controller: Intel Corp. 82810E DC-133 CGC [Chipset
Graphics Controller] (rev 03)
00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02)
00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02)
00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801AA AC'97 Audio (rev 02)
01:02.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
==============================================================================

Hence both the kernel and the <.config file> have significantly changed from
2.6.8 to 2.6.14 it's not clear what is causing the problem. I'm trying to get
closer - but that will take it's time because my machines are not that fast.

I extracted the source and compiled ( same as for the 2.6.14 ! ) the i810fb
(framebuffer) agpgart ..., piix, ext2, ext3 and all needed ide modules as built 
in. This is simply because I want to boot without initrd and because the 
VGA/VESA support is broken in the graphic part of both i810 chip sets. 
Anyway, I don't think that this is the problem.

Hope I could help a little bit further.

best regards
/RalfS
 

Comment 45 Alan Stern 2006-01-03 11:31:55 UTC
Since there hasn't been any activity on this report for a couple of months, and
since the underlying problem apparently was caused by the motherboard firmware,
and since nobody seems to be bothered by it very much any more, I'm closing this
out.

If anyone still has similar problems, they should start a new bug report.

Note You need to log in before you can comment on or make changes to this bug.