Distribution: Ubuntu 8.04 Hardware Environment: HP Compaq 6910p laptop Problem Description: A couple if minutes after boot IRQ 19 is disabled. A similar issue on a different hardware version of this laptop was described at bug 10916. This problem is still valid as of v2.6.27-rc3-414-gb09c3e3.
Created attachment 17290 [details] dmesg -s64000 for 2.6.27-rc3
Created attachment 17291 [details] dmesg -s64000 for 2.6.27-rc3 with noapic
Created attachment 17292 [details] lsmod
Created attachment 17293 [details] acpidump
Created attachment 17294 [details] lspci -vxxx
Created attachment 17295 [details] /proc/interrupts
please attach the content of "/proc/interrupts" when boot with noapic.
Created attachment 17296 [details] /proc/interrupts with noapic
Will you please try to add the boot option of "irqpoll" and attach the content of "/proc/interrupts" twice?(The time interval is about 10s). Please attach the output of "lspci -vxxx " rather than "lspci -vxx". Thanks.
Created attachment 17297 [details] proper lspci -vxxx
Created attachment 17298 [details] /proc/interrupts with irqpoll (first)
Created attachment 17299 [details] /proc/interrupts with irqpoll (after 10 seconds)
Created attachment 17300 [details] Get the info using ./test 0xfed90000 0x4000 result Will you please use the attach tool to get the required info? ./test 0xfed900000 0x4000 result How to use this tool is described in the file of readme. Thanks.
Created attachment 17301 [details] ./test 0xfed90000 0x4000 result
Created attachment 17390 [details] try the debug patch Will you please try the debug patch and add the boot option of "irqpoll"? After the system is booted, please wait for about three minutes and attach the output of dmesg. Thanks.
Created attachment 17401 [details] dmesg with irqpoll for v2.6.27-rc4-123-gd3ee1b4 with the debug patch
Created attachment 17413 [details] try the debug patch Thanks for the test. From the dmesg in comment #16 there exist the following messages: >ahci IRQ(219) is misrouted to IRQ 0 >i8042 IRQ(12) is misrouted to IRQ 0 >i8042 IRQ(1) is misrouted to IRQ 0 It seems weird and not what we expected. At the same time the above info is printed only ten times. Maybe it is not enough. Will you please try the debug patch and do the test as mentioned in comment #15 again? Thanks
Created attachment 17427 [details] /var/log/messages with the debug patch I'm attaching /var/log/messages to include all of the messages - dmesg buffer is too small.
Created attachment 17433 [details] try the updated debug patch Thanks for the test. From the dmesg in comment #16 there exist the following messages: >ahci IRQ(219) is misrouted to IRQ 0 >i8042 IRQ(12) is misrouted to IRQ 0 >i8042 IRQ(1) is misrouted to IRQ 0 It seems that quilt a lot of device IRQs are misrouted to IRQ 0. But from the problem description we can know that the misrouted IRQ is 19. It seems confusing. Will you please try the debug patch and do the test as mentioned in comment #15 again? Thanks
I removed the "print_irq_count" check and waited a bit longer. Is this what you're looking for? uhci_hcd:usb2 IRQ(16) is misrouted to IRQ 19 I got 8 such messages during 1 hour test. Full logs are over 120 MB, so I'm not attaching them here (but I keep a copy, if needed).
Hi, Piotr hanks for the test. The following message is what I am looking for. >uhci_hcd:usb2 IRQ(16) is misrouted to IRQ 19 But from the /proc/interrupts in comment #6 the uhci_hcd:usb2 is routed to IRQ 17. It seems confusing. And from the log in comment #18 it seems that so many device IRQs are misrouted to IRQ 0. I can't understand it. Maybe it is related with the following info in lspci-vxxx. >02:06.4 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev ff) (prog-if ff) > !!! Unknown header type 7f 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Will you please check whether the some PCI devices can be disabled in BIOS option? (For example: CardBus, SD/MMC) If they can be disabled, please try to disable them and see whether the problem still exists. Please use the attached patch in comment #19 and attach the output of dmesg. (The check of print_irq_count is still added). Thanks.
As there is no response for more than one month, the bug will be rejected . If the problem still exists, please reopen it again and do the test as mentioned in comment #21. Thanks.
Sorry for not answering earlier. I did some tests a couple of weeks ago, but disabling devices in BIOS didn't help. However, it seems that current Ubuntu kernel (based on 2.6.27.2) works correctly. Even 2 hours after boot IRQ 19 is still alive. SD/MMC card reader that was affected by this issue now works fine. Anyway, thanks for help :)