Bug 142762 - irq 11: nobody cared - Abit VP6
irq 11: nobody cared - Abit VP6
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-13 17:09 EST by Paul Flinders
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-03 03:10:14 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)

  None (edit)
Description Paul Flinders 2004-12-13 17:09:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041212 Firefox/1.0

Description of problem:
Running fedora-core current (at present kernel 2.6.9-FC4_1014 but all
recent (since mid-aug 2004) development kernels) I'm having problems
with the kernel de-registering interrupts.

The order is always the same - first USB goes, then (after a few
hours) ethernet.

The following is logged in /var/log/messages for the USB interrupts

Dec 11 15:06:35 bessie kernel: irq 11: nobody cared! (screaming
interrupt?)
Dec 11 15:06:35 bessie kernel: irq 11: Please try booting with
acpi=off and report a bug
Dec 11 15:06:35 bessie kernel:  [<c0107316>] __report_bad_irq+0x3a/0x77
Dec 11 15:06:35 bessie kernel:  [<c010758d>] note_interrupt+0xea/0x115
Dec 11 15:06:35 bessie kernel:  [<c01077cb>] do_IRQ+0xd5/0x130
Dec 11 15:06:35 bessie kernel:  [<c02c7d14>] common_interrupt+0x18/0x20
Dec 11 15:06:35 bessie kernel:  [<c0104018>] default_idle+0x0/0x2c
Dec 11 15:06:35 bessie kernel:  [<c02c007b>] unix_release_sock+0x162/0x201
Dec 11 15:06:35 bessie kernel:  [<c0104041>] default_idle+0x29/0x2c
Dec 11 15:06:35 bessie kernel:  [<c010409d>] cpu_idle+0x26/0x3b
Dec 11 15:06:35 bessie kernel: handlers:
Dec 11 15:06:35 bessie kernel: [<c024e310>] (usb_hcd_irq+0x0/0x4b)
Dec 11 15:06:35 bessie kernel: [<c024e310>] (usb_hcd_irq+0x0/0x4b)
Dec 11 15:06:35 bessie kernel: Disabling IRQ #11

And the following when the ethernet gets disabled

Dec 11 23:08:40 bessie kernel: irq 185: nobody cared! (screaming
interrupt?)
Dec 11 23:08:40 bessie kernel: irq 185: Please try booting with
acpi=off and report a bug
Dec 11 23:08:40 bessie kernel:  [<c0107316>] __report_bad_irq+0x3a/0x77
Dec 11 23:08:40 bessie kernel:  [<c010758d>] note_interrupt+0xea/0x115
Dec 11 23:08:40 bessie kernel:  [<c01077cb>] do_IRQ+0xd5/0x130
Dec 11 23:08:40 bessie kernel:  [<c02c7d14>] common_interrupt+0x18/0x20
Dec 11 23:08:40 bessie kernel: handlers:
Dec 11 23:08:40 bessie kernel: [<e08ef8c5>]
(rtl8139_interrupt+0x0/0x17d [8139too])
Dec 11 23:08:40 bessie kernel: Disabling IRQ #185

Once the ethernet interrupt has gone the machine is effectively dead
as it has quite a bit NFS mounted.

unloading and reloading the ethernet driver just results in the
"nobody cared"..."Disabling IRQ" message being issued immediately.


Booting with acpi=off does appear to fix the problem - so, as
requested, I'm reporting a bug.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1) install Fedora development on an abit-vp6
2) wait :)



    

Actual Results:  Errors as above

Additional info:
Comment 1 Dave Jones 2005-02-24 02:18:53 EST
any better with the latest errata ?
Comment 2 Paul Flinders 2005-02-27 08:24:33 EST
Just the same

$ uname -a
Linux bessie.flinders.org 2.6.10-1.1154_FC4smp #1 SMP Fri Feb 25 19:41:11 EST
2005 i686 i686 i386 GNU/Linux

$ dmesg|tail -20
APIC error on CPU1: 40(40)
APIC error on CPU0: 40(40)
APIC error on CPU0: 40(40)
APIC error on CPU1: 40(40)
APIC error on CPU1: 40(40)
APIC error on CPU1: 40(40)
irq 11: nobody cared!
 [<c0138207>] __report_bad_irq+0x2b/0x68
 [<c01382a0>] note_interrupt+0x43/0x67
 [<c0137dd6>] __do_IRQ+0xe5/0x117
 [<c0105d16>] do_IRQ+0x62/0x7e
 =======================
 [<c01046f6>] common_interrupt+0x1a/0x20
 [<c0102018>] default_idle+0x0/0x29
 [<c010203b>] default_idle+0x23/0x29
 [<c01020be>] cpu_idle+0x4a/0x5f
handlers:
[<c0254f93>] (usb_hcd_irq+0x0/0x4b)
[<c0254f93>] (usb_hcd_irq+0x0/0x4b)
Disabling IRQ #11

The system had been up just under 2 hours (rebooted @11:16 above message @13:15)
Comment 3 Dave Jones 2005-11-10 15:17:30 EST
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.
Comment 4 Dave Jones 2005-12-27 23:41:13 EST
This bug has been mass-closed along with other bugs that have been in NEEDINFO
state for several months.

Due to the large volume of inactive bugs in bugzilla, this is the only method we
have of cleaning out stale bug reports where the reporter has disappeared.

If you can reproduce this bug after installing all the current updates, please
reopen this bug.

If you are not the reporter, you can add a comment requesting it be reopened,
and someone will get to it asap.

Thank you.
Comment 5 Paul Flinders 2006-01-01 13:56:59 EST
Well, it was only 6 weeks since you asked me to retest this & I had to get the
machine out of the attic!.

However, I'm afraid that this is still a problem in 2.6.14-1.1805_FC5 although
the error message has changed a bit (irqpoll is new to me).

System had been up about 80 minutes when I got this.

Jan  1 16:48:45 bessie kernel: irq 185: nobody cared (try booting with the
"irqpoll" option)
Jan  1 16:48:45 bessie kernel:  [<c014385c>] __report_bad_irq+0x2b/0x69    
[<c0143924>] note_interrupt+0x71/0x95
Jan  1 16:48:45 bessie kernel:  [<c0143321>] __do_IRQ+0xac/0xdf     [<c0104e9e>]
do_IRQ+0x62/0x7d
Jan  1 16:48:45 bessie kernel:  =======================
Jan  1 16:48:45 bessie kernel:  [<c01038e2>] common_interrupt+0x1a/0x20    
[<c0101018>] default_idle+0x0/0x55
Jan  1 16:48:45 bessie kernel:  [<c0101044>] default_idle+0x2c/0x55    
[<c01010fe>] cpu_idle+0x91/0xaa
Jan  1 16:48:45 bessie kernel:  [<c03cd7b0>] start_kernel+0x187/0x189    
Jan  1 16:48:45 bessie kernel: handlers:
Jan  1 16:48:45 bessie kernel: [<e0876bcf>] (rtl8139_interrupt+0x0/0x19f [8139too])
Jan  1 16:48:45 bessie kernel: Disabling IRQ #185
Jan  1 16:48:50 bessie kernel: irq 11: nobody cared (try booting with the
"irqpoll" option)
Jan  1 16:48:50 bessie kernel:  [<c014385c>] __report_bad_irq+0x2b/0x69    
[<c0143924>] note_interrupt+0x71/0x95
Jan  1 16:48:50 bessie kernel:  [<c0143321>] __do_IRQ+0xac/0xdf     [<c0104e9e>]
do_IRQ+0x62/0x7d
Jan  1 16:48:50 bessie kernel:  =======================
Jan  1 16:48:50 bessie kernel:  [<c01038e2>] common_interrupt+0x1a/0x20    
[<c0101018>] default_idle+0x0/0x55
Jan  1 16:48:50 bessie kernel:  [<c0101044>] default_idle+0x2c/0x55    
[<c01010fe>] cpu_idle+0x91/0xaa
Jan  1 16:48:50 bessie kernel: handlers:
Jan  1 16:48:50 bessie kernel: [<c02722c1>] (usb_hcd_irq+0x0/0x50)
Jan  1 16:48:50 bessie kernel: [<c02722c1>] (usb_hcd_irq+0x0/0x50)
Jan  1 16:48:50 bessie kernel: Disabling IRQ #11
Comment 6 Len Brown 2006-01-18 02:12:50 EST
Does any ACPI-enabled kernel of any age handle this system?

For the recent failing kernel, does "acpi=noirq" make it work?
Please attach the complete output from 'dmesg -s64000' and
'cat /proc/interrupts' for the sucess and failure cases.
Comment 7 Paul Flinders 2006-01-20 06:38:58 EST
> Does any ACPI-enabled kernel of any age handle this system?

I'm not sure - I don't currently have anything older than 2.6.10 which
post-dates my original bug-report. I recall working kernels before Aug 2004 but
not what their ACPI functionality was.

I'll dig through my backups & see if I have some older kernels to try. 

> does "acpi=noirq" make it work
I'll check & get back to you - "acpi=irqpoll" does appear to work.

> Please attach...
I'll send those the next time I boot that box.
Comment 8 Dave Jones 2006-02-03 01:07:27 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 9 Paul Flinders 2006-02-03 03:10:14 EST
I've been trying for the last 12 days to reproduce this - the suspect machine
has been up the entire time on different versions. But it has been working even
in kernels that had problems within an hour or so of booting.

Obviously I have tried to keep the software environment stable but I have had to
update a few packages to run the newer (2.6.15) kernels so it looks as though
something has changed to mitigate this bug (or maybe it was never in the kernel
and has actually been fixed).

I'm not likely to keep this hardware active for much longer anyway

I'm closing the bug myself (if that's OK).

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