Has there been any progress with this?

Are you able to test 2.6.13-rc4?

Thanks.

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

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.

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.

PS my keyboard is PS/2, so i have no other devices on USB bus.

OK, thanks.

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

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.

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 

But 2.6.12.x worked correctly, did it not?

How can this be a hardware problem?

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.

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.

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.

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.

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?

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.

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 ?).

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().

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

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).

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

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()?

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. :-)

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)

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()?

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. 

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.

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)

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.

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.

Created attachment 5987 [details]
v2.6.12.3 kernel log

Minicom seems to append to files that already exist.  Log messages split out.

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.

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.

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?

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.

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?

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

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?

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... ????

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.

Fran

Does 2.6.14 solve everybody's problems?  Or does ACPI still need more work?

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

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.

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
 

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.