Bug 135960 - irq 9: nobody cared! (screaming interrupt?) - acpi_irq
irq 9: nobody cared! (screaming interrupt?) - acpi_irq
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-15 17:56 EDT by yeech
Modified: 2015-01-04 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-02 20:13:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Information requested by len brown (20.04 KB, text/plain)
2004-11-18 10:37 EST, yeech
no flags Details
Contents of an acpidmp > acpidmp.txt (66.27 KB, text/plain)
2004-11-19 09:16 EST, yeech
no flags Details
Additional information regarding acpi behavior and configuration (32.74 KB, text/plain)
2004-11-19 11:14 EST, yeech
no flags Details

  None (edit)
Description yeech 2004-10-15 17:56:08 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041012

Description of problem:
The kernel boots with the message:

Oct 15 11:50:39 aacnyelrsh kernel: ACPI: Subsystem revision 20040816
Oct 15 11:50:39 aacnyelrsh kernel: irq 9: nobody cared! (screaming
interrupt?)
Oct 15 11:50:39 aacnyelrsh kernel: irq 9: Please try booting with
acpi=off and report a bug
Oct 15 11:50:39 aacnyelrsh kernel: Stack pointer is garbage, not
printing trace
Oct 15 11:50:39 aacnyelrsh kernel: handlers:
Oct 15 11:50:39 aacnyelrsh kernel: [<021f3d63>] (acpi_irq+0x0/0x14)
Oct 15 11:50:39 aacnyelrsh kernel: Disabling IRQ #9
Oct 15 11:50:39 aacnyelrsh kernel: ACPI: Interpreter enabled

The system is an HP d220m, generic P4 2.4GHZ with an intel chipset.



Version-Release number of selected component (if applicable):
2.6.8-1.610 and others

How reproducible:
Always

Steps to Reproduce:
1. boot system
2.
3.
    

Actual Results:  The system runs fine although I believe that I have
encountered problems with custom kernels derived from the 2.6.8-1
(Redhat) sources. Note: this is not a custom kernel. The custom
kernels often hang without output to messages or any other visible
evidence.

Expected Results:  No message.

Additional info:

I updated the bios once but I believe that there may be another
version on HP's web site. I will provide a complete copy of
/var/log/messages if asked.

This is the start of a boot, as if you wouldn't know:

Oct 15 11:50:39 aacnyelrsh syslogd 1.4.1: restart.
Oct 15 11:50:39 aacnyelrsh syslog: syslogd startup succeeded
Oct 15 11:50:39 aacnyelrsh syslog: klogd startup succeeded
Oct 15 11:50:39 aacnyelrsh kernel: klogd 1.4.1, log source =
/proc/kmsg started.
Oct 15 11:50:39 aacnyelrsh kernel: Linux version 2.6.8-1.624
(bhcompile@tweety.build.redhat.com) (gcc version 3.4.2 20041006 (Red
Hat 3.4.2-5)) #1 Thu Oct 14 20:56:31 EDT 2004
Oct 15 11:50:39 aacnyelrsh kernel: BIOS-provided physical RAM map:
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 0000000000000000 -
000000000009fc00 (usable)
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 000000000009fc00 -
00000000000a0000 (reserved)
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 00000000000f0000 -
0000000000100000 (reserved)
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 0000000000100000 -
000000001f7f0000 (usable)
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 000000001f7f0000 -
000000001f7f8000 (ACPI data)
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 000000001f7f8000 -
000000001f800000 (ACPI NVS)
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 00000000fec00000 -
00000000fec01000 (reserved)
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 00000000fee00000 -
00000000fee01000 (reserved)
Oct 15 11:50:39 aacnyelrsh kernel:  BIOS-e820: 00000000fff00000 -
0000000100000000 (reserved)
Oct 15 11:50:39 aacnyelrsh kernel: 0MB HIGHMEM available.
Oct 15 11:50:39 aacnyelrsh kernel: 503MB LOWMEM available.
Oct 15 11:50:39 aacnyelrsh kernel: zapping low mappings.
Oct 15 11:50:39 aacnyelrsh portmap: portmap startup succeeded
Oct 15 11:50:39 aacnyelrsh kernel: DMI 2.3 present.
Oct 15 11:50:39 aacnyelrsh kernel: ACPI: PM-Timer IO Port: 0x808
Oct 15 11:50:39 aacnyelrsh kernel: Built 1 zonelists
Oct 15 11:50:39 aacnyelrsh kernel: Kernel command line: ro
root=LABEL=/ rhgb quiet
Oct 15 11:50:39 aacnyelrsh kernel: mapped 4G/4G trampoline to ffff4000.
Oct 15 11:50:39 aacnyelrsh kernel: Initializing CPU#0
Oct 15 11:50:39 aacnyelrsh kernel: CPU 0 irqstacks, hard=023d6000
soft=023d5000
Oct 15 11:50:39 aacnyelrsh kernel: PID hash table entries: 2048
(order: 11, 32768 bytes)
Oct 15 11:50:39 aacnyelrsh kernel: Detected 2399.994 MHz processor.
Oct 15 11:50:39 aacnyelrsh kernel: Using tsc for high-res timesource
Oct 15 11:50:39 aacnyelrsh kernel: Console: colour VGA+ 80x25
Oct 15 11:50:39 aacnyelrsh kernel: Dentry cache hash table entries:
65536 (order: 6, 262144 bytes)
Oct 15 11:50:39 aacnyelrsh kernel: Inode-cache hash table entries:
32768 (order: 5, 131072 bytes)
Oct 15 11:50:39 aacnyelrsh kernel: Memory: 507140k/516032k available
(2068k kernel code, 8184k reserved, 651k data, 144k init, 0k highmem)
Oct 15 11:50:39 aacnyelrsh kernel: Security Scaffold v1.0.0 initialized
Oct 15 11:50:39 aacnyelrsh kernel: SELinux:  Initializing.
Oct 15 11:50:39 aacnyelrsh kernel: SELinux:  Starting in permissive mode
Oct 15 11:50:39 aacnyelrsh kernel: There is already a security
framework initialized, register_security failed.
Oct 15 11:50:39 aacnyelrsh kernel: selinux_register_security: 
Registering secondary module capability
Oct 15 11:50:39 aacnyelrsh kernel: Capability LSM initialized as secondary
Oct 15 11:50:39 aacnyelrsh kernel: Mount-cache hash table entries: 512
(order: 0, 4096 bytes)
Oct 15 11:50:39 aacnyelrsh kernel: CPU: Trace cache: 12K uops, L1 D
cache: 8K
Oct 15 11:50:39 aacnyelrsh kernel: CPU: L2 cache: 512K
Oct 15 11:50:39 aacnyelrsh kernel: Intel machine check architecture
supported.
Oct 15 11:50:39 aacnyelrsh kernel: Intel machine check reporting
enabled on CPU#0.
Oct 15 11:50:39 aacnyelrsh kernel: CPU0: Intel P4/Xeon Extended MCE
MSRs (12) available
Oct 15 11:50:39 aacnyelrsh kernel: CPU: Intel(R) Pentium(R) 4 CPU
2.40GHz stepping 07
Oct 15 11:50:39 aacnyelrsh kernel: Enabling fast FPU save and
restore... done.
Oct 15 11:50:39 aacnyelrsh kernel: Enabling unmasked SIMD FPU
exception support... done.
Oct 15 11:50:39 aacnyelrsh kernel: Checking 'hlt' instruction... OK.
Oct 15 11:50:39 aacnyelrsh kernel: ACPI: IRQ9 SCI: Edge set to Level
Trigger.
Oct 15 11:50:39 aacnyelrsh kernel: checking if image is initramfs... it is
Oct 15 11:50:39 aacnyelrsh kernel: Freeing initrd memory: 395k freed
Oct 15 11:50:39 aacnyelrsh kernel: NET: Registered protocol family 16
Oct 15 11:50:39 aacnyelrsh kernel: PCI: PCI BIOS revision 2.10 entry
at 0xfdb61, last bus=3
Oct 15 11:50:39 aacnyelrsh kernel: PCI: Using configuration type 1
Oct 15 11:50:39 aacnyelrsh kernel: mtrr: v2.0 (20020519)
Comment 1 Len Brown 2004-11-18 00:54:30 EST
Have all kernels you've tried failed this way, or just this one?
It would be interesting to know if the FC3 kernel or
vanilla 2.6.9 kernel do this too.

Please verify that the system is running the latest BIOS.
Please attach the complete dmesg -64000 showing the failure.
Please show the /proc/interrupts of the failed boot.

Please attach the output from lspci -vv
Please attach the output from acpidmp, avaiable in /usr/sbin, or
in pmtools: 
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
Comment 2 yeech 2004-11-18 10:37:01 EST
Created attachment 106962 [details]
Information requested by len brown

I have not provided a dump of the acpi information. I am trying to build
acpidmp now.
Comment 3 Len Brown 2004-11-18 16:09:24 EST
Hmm, the ACPI SCI is alone on IRQ9 but it screams.
There are two ways this can happen.  One is if it really
is alone and we've mis-configured the polarity.
The other is if another device is pulling on the interrupt line.

With IRQ9 disabled, you'll get no ACPI interrupts.
You can test this by killing acpid, and
# cat /proc/acpi/event
to watch for acpi events.

> ACPI: IRQ9 SCI: Edge set to Level Trigger.

Try booting with these four combinations of cmdline parameters:
acpi_sci=edge acpi_sci=high
acpi_sci=edge acpi_sci=low
acpi_sci=level acpi_sci=high
acpi_sci=level acpi_sci=low

For each, report if IRQ9 is disabled during boot,
and then perform the power button test above
(press it a couple of times and you should see
 an event for each press)

This system has an MADT, which is where IOAPICs are enumerated.
What do you see when you boot the SMP kernel or a UP kernel
with IO-APIC support?

Please attach the output from acpidmp so I can take
a look at the MADT.  acpidmp is available in /usr/sbin
or in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils
The DSDT in acpidmp may also point out of any other
device thinks it owns IRQ9.

Finally, if you know of acpi-enabled kernels that did *not*
have this problem, that might help us isolate if this
is a generic problem or an FC3 specific problem.

Comment 4 yeech 2004-11-19 09:16:28 EST
Created attachment 107050 [details]
Contents of an acpidmp > acpidmp.txt
Comment 5 yeech 2004-11-19 11:14:09 EST
Created attachment 107061 [details]
Additional information regarding acpi behavior and configuration

The information is (grep -i acpi /var/log/messages, sorry) the result of
booting with the four configurations requested. None of the configurations
resulted in an acpi event (cat /proc/acpi/event, press power button
repeatedly).
Comment 6 Len Brown 2004-11-20 04:59:53 EST
thanks for testing the acpi_sci flags.  The fact that none of them 
worked suggests that it isn't an SCI configuration issue, but something 
else that is killing IRQ9. 
 
BTW. this system has an MADT and an APIC.  Does the 
SMP or Uniprocessor-IOAPIC-enabled kernel work properly 
in IOAPIC mode? 
 
 
Comment 7 Len Brown 2004-11-23 23:51:25 EST
same with the latest kernel.org snapshot?
(an interrupt bugfix went in yesterday)
Comment 8 Pawel Salek 2005-03-18 17:47:44 EST
I see same thing with 2.6.10-1.770_FC3 (hardware: HP dx2000). Pure boot (without
any extra options; original FC3 kernel) gives:
Mar 18 04:47:35 bio79-63 kernel: irq 9: nobody cared! (screaming interrupt?)
Mar 18 04:47:35 bio79-63 kernel: irq 9: Please try booting with acpi=off and
report a bug
Mar 18 04:47:35 bio79-63 kernel: Stack pointer is garbage, not printing trace
or (updated kernel to 2.6.10-1.770_FC3)
Mar 18 05:05:10 bio79-63 kernel: ACPI: Subsystem revision 20041105
Mar 18 05:05:10 bio79-63 kernel: irq 9: nobody cared (try booting with the
"irqpoll" option.
Mar 18 05:05:10 bio79-63 kernel:  [<c013e0a0>] __report_bad_irq+0x2b/0x68
Mar 18 05:05:10 bio79-63 kernel:  [<c013e169>] note_interrupt+0x73/0x96
Mar 18 05:05:10 bio79-63 kernel:  [<c013d6cc>] __do_IRQ+0x1bd/0x249
Mar 18 05:05:10 bio79-63 kernel:  [<c0104e04>] do_IRQ+0x5e/0x7a

Booting with acpi=off gives:
Mar 18 23:35:34 bio79-63 kernel: ACPI: Subsystem revision 20041105
Mar 18 23:35:34 bio79-63 kernel: ACPI: Interpreter disabled.
Mar 18 23:35:34 bio79-63 kernel: Linux Plug and Play Support v0.97 (c) Adam Belay
Mar 18 23:35:34 bio79-63 kernel: pnp: PnP ACPI: ACPI disable
Mar 18 23:35:34 bio79-63 kernel: usbcore: registered new driver usbfs
Mar 18 23:35:34 bio79-63 kernel: usbcore: registered new driver hub
Mar 18 23:35:34 bio79-63 kernel: PCI: Probing PCI hardware
Mar 18 23:35:34 bio79-63 kernel: PCI: Probing PCI hardware (bus 00)
Mar 18 23:35:34 bio79-63 kernel: PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Mar 18 23:35:34 bio79-63 kernel: PCI: Transparent bridge - 0000:00:1e.0
Mar 18 23:35:34 bio79-63 kernel: PCI: Using IRQ router PIIX/ICH [8086/24d0] at
0000:00:1f.0
Mar 18 23:35:34 bio79-63 kernel: PCI: IRQ 0 for device 0000:00:1f.1 doesn't
match PIRQ mask - try pci=usepirqmask
Comment 9 Reaz 2005-05-16 23:04:04 EDT
i do have quite the same problem.but after that i have update my bios the
problem disapear
Comment 10 Dave Jones 2005-07-15 13:46:56 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 11 Dave Jones 2005-10-02 20:13:25 EDT
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.

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