Bug 140708 - kernel disabled irq 11
kernel disabled irq 11
Status: CLOSED DUPLICATE of bug 138822
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-24 07:52 EST by Bernd Bartmann
Modified: 2015-01-04 17:13 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:07:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages showing "irq 11: ... (screaming interrupt?)" twice (41.98 KB, text/plain)
2004-11-25 06:58 EST, Julian Blake
no flags Details

  None (edit)
Description Bernd Bartmann 2004-11-24 07:52:57 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:
Just found this in /var/log/messages:

Nov 24 13:27:38 spock gconfd (bart-2225): Beenden
Nov 24 13:27:40 spock gdm(pam_unix)[4872]: session closed for user bart
Nov 24 13:27:40 spock dbus: avc:  1 AV entries and 1/512 buckets used,
longest chain length 1 
Nov 24 13:27:42 spock kernel: irq 11: nobody cared! (screaming interrupt?)
Nov 24 13:27:42 spock kernel: irq 11: Please try booting with acpi=off
and report a bug
Nov 24 13:27:42 spock kernel: Stack pointer is garbage, not printing trace
Nov 24 13:27:42 spock kernel: handlers:
Nov 24 13:27:42 spock kernel: [<22843f33>] (ahc_linux_isr+0x0/0x2f3
[aic7xxx])
Nov 24 13:27:42 spock kernel: [<02282da7>] (usb_hcd_irq+0x0/0x4b)
Nov 24 13:27:42 spock kernel: [<02282da7>] (usb_hcd_irq+0x0/0x4b)
Nov 24 13:27:42 spock kernel: Disabling IRQ #11
Nov 24 13:27:42 spock kernel: agpgart: Found an AGP 2.0 compliant
device at 0000:00:00.0.
Nov 24 13:27:42 spock kernel: agpgart: Putting AGP V2 device at
0000:00:00.0 into 1x mode
Nov 24 13:27:42 spock kernel: agpgart: Putting AGP V2 device at
0000:01:00.0 into 1x mode
Nov 24 13:33:35 spock gpm[2751]: *** info [mice.c(1766)]: 
Nov 24 13:33:35 spock gpm[2751]: imps2: Auto-detected intellimouse PS/2
Nov 24 13:43:54 spock gpm[2751]: *** info [client.c(137)]: 
Nov 24 13:43:54 spock gpm[2751]: Connecting at fd 6
Nov 24 13:44:52 spock gpm[2751]: *** info [client.c(275)]: 
Nov 24 13:44:52 spock gpm[2751]: Request on 6 (console 1)
Nov 24 13:44:52 spock gpm[2751]: *** info [client.c(284)]: 
Nov 24 13:44:52 spock gpm[2751]: Closing

Here is /proc/interrupts:
           CPU0       
  0:  183377598          XT-PIC  timer
  1:      15432          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  ohci_hcd
  8:          3          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 10:    2475160          XT-PIC  SiS SI7012, ehci_hcd, ohci_hcd, eth0,
eth1
 11:     700000          XT-PIC  aic7xxx, uhci_hcd, uhci_hcd,
r128@pci:0000:01:00.0
 12:        742          XT-PIC  i8042
 14:    2355887          XT-PIC  ide0
 15:    2931477          XT-PIC  ide1
NMI:          0 
ERR:          0

There was no activity on the aic7xxx on this time. I've an usb + ps/s
mouse connected to the system. I've never seen such an error message
before. 

Version-Release number of selected component (if applicable):
kernel-2.6.9-1.681_FC3

How reproducible:
Sometimes

Steps to Reproduce:
1. don't know yet
2.
3.
    

Additional info:
Comment 1 Julian Blake 2004-11-25 06:30:23 EST
I see the same problem:

kernel: irq11: nobody cared! (screaming interrupt?)

but in my case it is eth0 (an Intel eepro100 network card) which is
sharing IRQ 11 with the ATI Rage 128 graphics card.  All subsequent
attempts to use the network fail with:

kernel: NETDEV WATCHDOG: eth0: transmit timed out

Changing the network driver from e100 to eepro100 does not alter this
behaviour.  The problem occurs a few seconds after logging out from a
GNOME session.
Comment 2 Julian Blake 2004-11-25 06:58:42 EST
Created attachment 107456 [details]
/var/log/messages showing "irq 11: ... (screaming interrupt?)" twice

Look for "screaming interrupt" and "NETDEV WATCHDOG".  IRQ11 is shared between
eth0 and r128.
Comment 3 Julian Blake 2004-11-25 08:39:23 EST
Booting with "acpi=off" does not change this behaviour.  I still get

"irq 11: ... (screaming interrupt?)"

after logging out from a GNOME session.  (My computer is so old that
ACPI is off by default.)
Comment 4 Julian Blake 2004-11-25 09:16:28 EST
The culprit seems to be the dri (direct rendering) module for r128.

After commenting out the line:

        Load  "dri"

in /etc/X11/xorg.conf, I no longer get IRQ 11 screaming interrupt after 
logging out from a GNOME session.
Comment 5 Julian Blake 2004-11-25 10:53:17 EST
See bug 138822 which deals with the r128 dri bug.

After installing xorg-x11*-6.8.1-19 packages from Rawhide, I can run 
r128 with dri and the IRQ 11 screaming interrupt problem has gone.
Comment 6 Jason 2005-01-01 22:28:48 EST
I have a new twist on the kernel disabling irq 11 for you...

when trying to install FC3 on any system with a Silicon Image 3112
SATA controller the install process gets only to the Initialising SCSI
controllers (sii3112 driver) and then comes up disabling IRQ11 and
goes absolutely no further unless you can fully disable in hardware
the SATA controller which is of absolutely no use to anyone trying to
install to a SATA drive.  This is present in any of the kernel's
currently shipped with and available for FC3.
Comment 7 Alan Cox 2005-01-02 10:45:23 EST
That would make sense. In the reports #1 .. #5 the R128 DRI has been
unloaded and then the IRQ has arrived indicating it was an X bug.

Other Jason (#6)  - the bug you report appears unrelated so can you
file a  seperate report for it. (The fact both involve IRQ 11 is chance).

Thanks


*** This bug has been marked as a duplicate of 138822 ***
Comment 8 Red Hat Bugzilla 2006-02-21 14:07:15 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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