Bug 1186

please attach acpidmp, lspci, dmesg, and /proc/interrupts. thanks a lot!

Created attachment 842 [details]
acpidump on 2.6.0-test3-bk2

Created attachment 843 [details]
lspci -v on 2.6.0-test3-bk2

Created attachment 844 [details]
/proc/interrupts on 2.6.0-test3-bk2

Created attachment 845 [details]
dmesg on 2.6.0-test3-bk2

Created attachment 846 [details]
dmesg on 2.6.0-test3-bk3

Created attachment 847 [details]
/proc/interrupts on 2.6.0-test3-bk3

Created attachment 848 [details]
lspci -v on 2.6.0-test3-bk3

all are attached.  If anything else is needed, please let me know.

does access to any USB port cause hang? can netcard work? can you verify if 
USB can work with acpi=off, and attach the dmesg and /proc/interrupts? Thanks 
a lot.

If I plug a USB device into the machine, it locks up hard. So yes, any USB access
causes the crash.

And no, sorry, I can't get nmi_watchdog to work on this box, so I can't see
where the kernel is hung at.

acpi=off never worked in the past.  I can try it again tomorrow if you _really_
think that it will help out.

Could you please explain "In kernel 2.6.0-test3-bk3 ACPI PCI interrupt routing
logic changed which causes any USB accesses on my machine to lock up the kernel."
Did you mean some kernel works before?

Is it possible to setup a serial console to catch dmesg when plugging a USB
mouse and pulling out a USB mouse ? (Please turn USB debug option and ACPI debug
option ON ). Thanks a lot!

I mean that 2.6.0-test3-bk2 works, and that 2.6.0-test3-bk3 does not work.  I
did not submit _any_ USB changes into that kernel release (and if you look at
the diff, you will see that there are no usb changes there.)

I do not have a serial port on this machine, and I do not have nmi_watchdog
support either, so sorry, I can not catch an oops message.

And if I plug a USB device into the machine, it hangs, I don't have to unplug
it.  There are no USB debug messages printed.  I am assuming that this is
because the USB interrupt comes in to the wrong vector.

And no CONFIG_USB_DEBUG doesn't show anything either :(

Created attachment 903 [details]
Using orginal active irq to set up PCI Interrupt Link 

I hope it could address your problem. Thanks a lot.

Ugh, I have already posted on the linux-acpi and lkml mailing lists that the
patch just posted there works for me.

I would not suggest you add any more #ifdefs to the acpi code as with the patch
you have just proposed.

So please just forward on the patch from Andrew de Quincey to Linus and Marcelo.

*** Bug 1286 has been marked as a duplicate of this bug. ***

*** Bug 1257 has been marked as a duplicate of this bug. ***

The patch from Andrew de Quincy is 
available now in these bitkeeper trees: 
 
http://linux-acpi.bkbits.net/linux-acpi-test-2.4.22 
http://linux-acpi.bkbits.net/linux-acpi-test-2.4.23 
http://linux-acpi.bkbits.net/linux-acpi-test-2.6.0 
 
It is also available as a plain pach "acpi_pci_link_allocate" here: 
 
ftp.kernel.org:/pub/linux/kernel/people/lenb/acpi/patches/test/* 
 
 
 
 

this fix is available in... 
2.6.0-test6+ 
2.4.3-pre5 
 

Created attachment 1354 [details]
proposed pci_link.c patch

Unfortunately the previous patch for this issue had some side-effects
on other systems.  Please test the attached pci_link.c patch
and gather the dmesg, /proc/interrupts, and if USB works or not.

If the patch fails to boot, please try booting it with cmdline
"acpi_irq_static".

thanks,
-Len

http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.4.22/20031118062400-pci_link.patch 
 
We didn't have to change our policy of leaving active PIC-mode interrupts alone after all. 
(though we did add a cmdline to re-program them, and we did change 
 our policy in APIC mode). 
 
So I'm re-closing this one.