Bug 145530 - irq 169: nobody cared! (screaming interrupt?)
irq 169: nobody cared! (screaming interrupt?)
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Baron
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-19 09:39 EST by Pascal de Bruijn
Modified: 2013-03-06 00:58 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 12:05:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Pascal de Bruijn 2005-01-19 09:39:08 EST
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).
Comment 1 Suzanne Hillman 2005-01-19 17:25:36 EST
Could you check this with a more recent kernel to see if this has possibly
already been fixed? beta2 is from a bit ago.
Comment 2 Pascal de Bruijn 2005-01-20 11:34:26 EST
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!
Comment 3 Pascal de Bruijn 2005-01-21 09:33:53 EST
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

Comment 4 Pascal de Bruijn 2005-01-21 17:54:06 EST
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
Comment 5 Marcin Szweda 2005-05-27 07:13:01 EDT
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

Comment 6 Elliot Kendall 2005-10-26 10:52:31 EDT
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.
Comment 7 dan ginsberg 2005-11-17 15:26:52 EST
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 8 Len Brown 2006-01-18 02:52:30 EST
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 9 Len Brown 2006-01-18 02:55:59 EST
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 10 Len Brown 2006-01-18 03:03:47 EST
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 11 Len Brown 2006-01-18 03:09:12 EST
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.
Comment 14 Jiri Pallich 2012-06-20 12:05:33 EDT
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.

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