From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: During boot I get this in my dmesg, the system works fine though: irq 169: nobody cared! (screaming interrupt?) irq 169: Please try booting with acpi=off and report a bug [<c010736a>] __report_bad_irq+0x3a/0x77 [<c01075d8>] note_interrupt+0xe1/0x10c [<c0107884>] do_IRQ+0x143/0x1ae [<c02bfa84>] common_interrupt+0x18/0x20 [<c0104018>] default_idle+0x0/0x2c [<c0104041>] default_idle+0x29/0x2c [<c010409d>] cpu_idle+0x26/0x3b [<c037a784>] start_kernel+0x194/0x198 handlers: [<c01c9b13>] (acpi_irq+0x0/0x14) Disabling IRQ #169 This happens at everyboot Version-Release number of selected component (if applicable): kernel 2.6.9-1.675 SMP How reproducible: Always Steps to Reproduce: 1. boot the machine Actual Results: I got the ACPI IRQ error message Expected Results: A dmesg without any ACPI IRQ errors. Additional info: I'm running RHEL4b2 on a ASUS P2L97-DS (Dual, SCSI). I has a Intel 440LX chipset. With an onboard Adaptec 7880 controller. I current have two Pentium II-ECC 300mhz processors in the machine. I have run many different kernels on this machine with ACPI enabled, without any issues (both 2.4, and 2.6 series, I don't remember which specifically).
Could you check this with a more recent kernel to see if this has possibly already been fixed? beta2 is from a bit ago.
Sorry, should have thought about that myself. I have just installed the following kernel: http://people.redhat.com/davej/kernels/RHEL4/RPMS.kernel/kernel-smp-2.6.9-5.EL.i686.rpm ----------------------------------------------------------------------------- Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot 0000:00:04.1 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... irq 169: nobody cared! (screaming interrupt?) irq 169: Please try booting with acpi=off and report a bug [<c0107316>] __report_bad_irq+0x3a/0x77 [<c010758d>] note_interrupt+0xea/0x115 [<c01077cb>] do_IRQ+0xd5/0x130 [<c02c6c60>] common_interrupt+0x18/0x20 [<c0104018>] default_idle+0x0/0x2c [<c0104041>] default_idle+0x29/0x2c [<c010409d>] cpu_idle+0x26/0x3b handlers: [<c01cd68f>] (acpi_irq+0x0/0x14) Disabling IRQ #169 Probing IDE interface ide1... hdc: ASUS CD-S520/A5, ATAPI CD/DVD-ROM drive Using cfq io scheduler ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide0... Probing IDE interface ide2... ide2: Wait for ready failed before probe ! Probing IDE interface ide3... ide3: Wait for ready failed before probe ! Probing IDE interface ide4... ide4: Wait for ready failed before probe ! Probing IDE interface ide5... ide5: Wait for ready failed before probe ! hdc: ATAPI 52X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 ----------------------------------------------------------------------------- The problem seems to remain!
I also did some extra checking, how that machine would fare with other kernels. I booted the Ubuntu Live CD, which uses a fairly vanilla 2.6.7 kernel with ACPI enabled, and I got the same problem, which suggests the problem is in the vanilla sources and not the redhat patches. Note that when booting the Ubuntu Live CD, I got the same problem except that the IRQ was different, it was IRQ #20! Regards, Pascal de Bruijn
I also tried to install Fedore Core 3, the kernel on the install CD kernel-smp-2.6.9-1.667 gave me again the same problems, after upgrading to kernel-smp-2.6.10-1.741 the message I got changed a little bit: irq 169: nobody cared (try booting with the "irqpoll" option. [<c0137349>] __report_bad_irq+0x2b/0x68 [<c0137412>] note_interrupt+0x73/0x99 [<c0136e4d>] __do_IRQ+0xee/0x11d [<c0105cbe>] do_IRQ+0x62/0x7e ======================= [<c010467e>] common_interrupt+0x1a/0x20 [<c011007b>] __acpi_map_table+0x7b/0x8f [<c01374f5>] probe_irq_on+0xbd/0x123 [<c020dd42>] autoconfig_irq+0x70/0x148 [<c020ef38>] serial8250_config_port+0x47/0x6d [<c020c97a>] uart_configure_port+0x4f/0x11b [<c020ccbb>] uart_add_one_port+0x8b/0xc5 [<c038cc43>] serial8250_register_ports+0x23/0x2f [<c038cded>] serial8250_init+0x81/0xa9 [<c0372819>] do_initcalls+0x49/0x8e [<c01004bd>] init+0x94/0x140 [<c0100429>] init+0x0/0x140 [<c01021f5>] kernel_thread_helper+0x5/0xb handlers: [<c01cadff>] (acpi_irq+0x0/0x14) Disabling IRQ #169 Next I tried booting with irqpoll as parameter, but the machine would not boot... The kernel will just hang... Regards, Pascal de Bruijn
This happends in all kernel releases of Fedora 3 on MSI Neo motherboard with Intel® 865PE Chipset and 3GHz PIV. On SMP it is IRQ #169, on standard kernel - IRQ #10. Result is in very slow disk IO. In /proc/interrupts there is large number thext to that IRQ: 169: 1000000 IO-APIC-level ide0, ide1 From dmesg: hdc: dma_timer_expiry: dma status == 0x64 hdc: DMA interrupt recovery hdc: lost interrupt irq 169: nobody cared! [<c013e804>] __report_bad_irq+0x24/0x7d [<c013e8e6>] note_interrupt+0x6b/0x95 [<c013e40d>] __do_IRQ+0x12c/0x13f [<c0106180>] do_IRQ+0x50/0x89 ======================= [<c01048f6>] common_interrupt+0x1a/0x20 handlers: [<c0258973>] (ide_intr+0x0/0x147) [<c0258973>] (ide_intr+0x0/0x147) Disabling IRQ #169 Kernel: 2.6.11-1.27_FC3smp
I am seeing a similar problem while trying to install RHEL4 AS U1 on a Dell Poweredge 4600 with the 2.6.9-11.EL kernel. tty4 shows the following output: <3>irq 7: nobody cared! (screaming interrupt?) <3>irq 7: Please try booting with acpi=off and report a bug <4> [<c0107e5b>] __report_bad_irq+0x31/0x77 <4> [<c0108319>] note_interrupt+0x191/0x1b7 <4> [<c01087af>] do_IRQ+0x19a/0x242 <4> [<c0303838>] common_interrupt+0x18/0x20 <4> [<c0107def>] handle_IRQ_event+0x1d/0x4f <4> [<c0108731>] do_IRQ+0x11c/0x242 <4> [<c0303838>] common_interrupt+0x18/0x20 <4> [<c02a007b>] sys_sendto+0x7/0xe2 <4> [<c0125f98>] __do_softirq+0x46/0x4d <4> ========================= <4> [<c010884e>] do_IRQ+0x239/0x242 <4> [<c0303838>] common_interrupt+0x18/0x20 <4> [<c010403b>] default_idle+0x23/0x26 <4> [<c010408c>] cpu_idle+0x1f/0x34 <4> [<c03a96b4>] start_kernel+0x20f/0x211 <3>handlers: <3>[<d09a445c>] (tg3_interrupt+0x0/0x19f [tg3]) <0>Disabling IRQ #7 Unlike the problem Pascal describes, this seems to be fatal. The installation hangs shortly after the start of the second phase ("Starting anaconda"). The prompt on tty2 hangs, but tty switching still works.
2.6.9-22.0.1.ELsmp (EL 4 kernel-smp ) irq 9: nobody cared! (screaming interrupt?) irq 9: Please try booting with acpi=off and report a bug [<c01074c2>] __report_bad_irq+0x3a/0x77 [<c0107739>] note_interrupt+0xea/0x115 [<c01079e5>] do_IRQ+0x143/0x1ae [<c02d1974>] common_interrupt+0x18/0x20 [<c016e834>] __d_lookup+0xfe/0x109 [<c01652af>] do_lookup+0x1f/0x8f [<c0165b27>] __link_path_walk+0x808/0xbb5 [<c014cffa>] do_no_page+0x6f/0x2f9 [<c0165f17>] link_path_walk+0x43/0xbe [<c02cf5cb>] __cond_resched+0x14/0x39 [<c01c191e>] direct_strncpy_from_user+0x3e/0x5d [<c01662ac>] path_lookup+0x14b/0x17f [<c0166983>] open_namei+0x99/0x579 [<c0159090>] filp_open+0x23/0x3c [<c02cf5cb>] __cond_resched+0x14/0x39 [<c01c191e>] direct_strncpy_from_user+0x3e/0x5d [<c01593a2>] sys_open+0x31/0x7d [<c02d0fb7>] syscall_call+0x7/0xb handlers: [<c01d7817>] (acpi_irq+0x0/0x14) Disabling IRQ #9 lspci 00:00.0 Host bridge: Intel Corp. E7501 Memory Controller Hub (rev 01) 00:02.0 PCI bridge: Intel Corp. E7500/E7501 Hub Interface B PCI-to-PCI Bridge (rev 01) 00:03.0 PCI bridge: Intel Corp. E7500/E7501 Hub Interface C PCI-to-PCI Bridge (rev 01) 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CA LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CA Ultra ATA Storage Controller (rev 02)00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 02) 01:01.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 10) 01:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 01:03.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 02) 02:04.0 Ethernet controller: Adaptec ANA620xx/ANA69011A (rev 03) 02:05.0 Ethernet controller: Adaptec ANA620xx/ANA69011A (rev 03) 02:06.0 Ethernet controller: Adaptec ANA620xx/ANA69011A (rev 03) 02:07.0 Ethernet controller: Adaptec ANA620xx/ANA69011A (rev 03) 03:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04) 03:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04) 03:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04) 03:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04) 04:03.0 RAID bus controller: 3ware Inc 3ware Inc 3ware 7xxx/8xxx-series PATA/SATA-RAID (rev 01) 05:03.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) 06:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04) 06:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04) 06:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04) 06:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04) 07:03.0 RAID bus controller: 3ware Inc 3ware Inc 3ware 7xxx/8xxx-series PATA/SATA-RAID (rev 01) 08:01.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 08:01.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) [root@jmp01 ~]# cat /proc/interrupts CPU0 CPU1 0: 505397 440164 IO-APIC-edge timer 3: 12 0 IO-APIC-edge serial 4: 11 0 IO-APIC-edge serial 8: 1 0 IO-APIC-edge rtc 9: 100000 0 IO-APIC-level acpi 14: 4043 3930 IO-APIC-edge ide0 169: 0 0 IO-APIC-level uhci_hcd 177: 2 0 IO-APIC-level eth3 193: 48 404 IO-APIC-level eth1 201: 12 439 IO-APIC-level eth2 209: 3521 1227 IO-APIC-level 3ware Storage Controller 217: 30 0 IO-APIC-level aic7xxx 225: 17 0 IO-APIC-level 3ware Storage Controller 233: 45802 0 IO-APIC-level eth0, eth4 NMI: 0 0 LOC: 945183 945204 ERR: 0 MIS: 0
Comment #7 is the ACPI interrupt itself: > 2.6.9-22.0.1.ELsmp (EL 4 kernel-smp ) > 9: 100000 0 IO-APIC-level acpi As there is nothing else on IRQ9, this means simply that ACPI events, such as your power button, will not work. You should be able to work around this failure by booting with "acpi_sci=high" or "acpi_sci=low" possibly with "acpi_sci=edge" or "acpi_sci=level" your dmesg may tell which, or you can just try them all and the one that works will give you no dmesg error and the power button will actually work.
comment #6 is a PIC mode issue > RHEL4 AS U1 on a Dell Poweredge 4600 with the 2.6.9-11.EL kernel booting with "acpi=off", or probably just "acpi=noirq" should be sufficient workarounds.
comment #1 - comment #4 are an acpi_irq failure in IRQ 169. > ASUS P2L97-DS Intel 440LX > [<c01c9b13>] (acpi_irq+0x0/0x14) > Disabling IRQ #169 It is unusual for ACPI to bind to an IRQ above 16. Is it possible to attach the output from dmesg -s64000 and acpidump found in pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ As this is the acpi_irq, you should be able to try the workaround in comment #8. If a combination works, then we're actually on the correct IRQ and the trigger/polarity are incorrect, but if none of the 4 combinations work, then acpi_irq is bound to the wrong IRQ.
comment #3 is different, here ide fails > MSI Neo motherboard with Intel 865PE > 169: 1000000 IO-APIC-level ide0, ide1 It is interesting that IDE thinks it should be a PCI interrupt when it is probably supposed to be an edge triggered legacy interrupt. Any difference with "acpi=off" or "acpi=noirq"? Need complete dmesg and /proc/interrupts from the failure, plus output from lspci -vv. If cmdline above fixes the issue, then need dmesg and /proc/interrupts from that too. Oh, and for a recent kernel such as 2.6.15 if possible.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.