Description of problem: When using Xorg with driver i810 and DRM enabled, switching back to a text console causes a storm of interrupts on irq 11 and it gets disabled. Unfortunately irq 11 is also used for a ton of other hardware on my system, and it all stops working at that point. This started happening with 2.6.19, though did very occasionally occur earlier too. The only solution I've found is to remove i915.ko from /lib/modules and reboot. [Er, or turn off DRM in xorg.conf I suppose.] This of course results in degraded 3D performance. Version-Release number of selected component (if applicable): kernel-2.6.22.1-32.fc6 xorg-x11-server-Xorg-1.1.1-47.10.fc6 xorg-x11-drv-i810-1.6.5-10.fc6 How reproducible: Always Steps to Reproduce: 1. Boot machine to run level 5 2. Switch VT to a text console Actual results: irq 11 gets disabled Expected results: irq 11 doesn't get disabled Additional info: What lspci says about my graphics card (hardware is actually a ThinkPad R51, model 2887-K2G): 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) Log messages at time of failure: kernel: irq 11: nobody cared (try booting with the "irqpoll" option) kernel: [<c045496e>] __report_bad_irq+0x36/0x75 kernel: [<c0454b5b>] note_interrupt+0x1ae/0x1eb kernel: [<c04540b6>] handle_IRQ_event+0x1a/0x3f kernel: [<c045548a>] handle_level_irq+0x95/0xc7 kernel: [<c04553f5>] handle_level_irq+0x0/0xc7 kernel: [<c04071f7>] do_IRQ+0xac/0xd1 kernel: [<c040592b>] common_interrupt+0x23/0x28 kernel: [<c042be44>] __do_softirq+0x54/0xc1 kernel: [<c04070f3>] do_softirq+0x59/0xb1 kernel: [<c04553f5>] handle_level_irq+0x0/0xc7 kernel: [<c042bd0c>] irq_exit+0x38/0x6b kernel: [<c0407208>] do_IRQ+0xbd/0xd1 kernel: [<c040592b>] common_interrupt+0x23/0x28 kernel: [<c04ebf30>] __copy_to_user_ll+0x0/0xcf kernel: [<c041cffb>] save_v86_state+0x5a/0x13a kernel: [<c0620f5a>] build_aevent+0x181/0x2a5 kernel: [<c041dc0a>] handle_vm86_fault+0x663/0x6c5 kernel: [<c062f087>] do_general_protection+0x0/0x20d kernel: [<c062edba>] error_code+0x72/0x78 kernel: [<c0410000>] amd_validate_add_page+0x1b/0x27 kernel: [<c0404f8e>] syscall_call+0x7/0xb kernel: ======================= kernel: handlers: kernel: [<c058a5b8>] (yenta_interrupt+0x0/0xb4) kernel: [<c058f329>] (usb_hcd_irq+0x0/0x4e) last message repeated 3 times kernel: [<f019ba9e>] (ohci_irq_handler+0x0/0x77f [ohci1394]) kernel: [<f0292535>] (ipw_isr+0x0/0x9b [ipw2200]) kernel: [<f0339014>] (snd_intel8x0_interrupt+0x0/0x1e2 [snd_intel8x0]) kernel: [<f0341fbf>] (snd_intel8x0_interrupt+0x0/0x1a3 [snd_intel8x0m]) kernel: Disabling IRQ #11 kernel: ipw2200: Failed to send SCAN_REQUEST_EXT: Command timed out. last message repeated 4 times I did once try booting with irqpoll - it meant that the network card carried on working, but my CDRW would only make coasters. Didn't stop the irq from being disabled. Google finds me a thread discussing a similar issue but with no resolution: http://archive.netbsd.se/?ml=dri-devel&a=2007-01&t=3046228
(This is a mass-update to all current FC6 kernel bugs in NEW state) Hello, I'm reviewing this bug list as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug, however this version of Fedora is no longer maintained. Please attempt to reproduce this bug with a current version of Fedora (presently Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a few days if there is no further information lodged. Thanks for using Fedora!
This is my main machine and upgrading to F8 is not a task to be undertaken lightly, especially in view of the Anaconda bugs in F8. I don't know if it counts, but I rebuilt F8's current kernel SRPM (2.6.23.9-85) unmodified on FC6 and it's still broken in exactly the same way with a very similar traceback. I'm not sure whether I have to also upgrade Xorg for this to be a valid test, but to be honest it does look like a kernel bug.
You can work around this problem with the kernel parameter "noirqdebug".
That certainly stops the message. Unfortunately it also stops the whole system dead, presumably because the graphics card is sending so many interrupts there's no time to do anything else. Not even Alt+SysRq+b had any effect once the system had hung.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.