Bugzilla – Bug 114879
noapic results in "IRQ 11: no one cared" on Acer Ferrari 4005
Last modified: 2005-09-27 08:56:07 UTC
When I boot my Acer Ferrari 4005 with the "noapic" parameter as rumored to be the default for UP systems, I end up with: irq 11: nobody cared (try booting with the "irqpoll" option) and then IRQ 11 gets disabled. Unfortunately, that includes most of the devices on my system. ATI IXP, 1394, usb, and card bus all use IRQ 11. Without "noapic," my system works fine. I'll attach my dmesg, hwinfo, and dmidecode output.
Created attachment 48541 [details] dmesg output
Created attachment 48542 [details] dmidecode output
Created attachment 48543 [details] hwinfo output
Jeff, is there a specific reason you're using noapic? Does it work if you omit the parameter <ffffffff8022b0eb>{pci_enable_device+27} <ffffffff881407d7>{:ohci1394:ohci1394_pci_probe+71} This looks like your firewire driver enables the device before installing an interrupt handler.
Doh, forget the above. I've been following the wrong track probably. So first off, I think you want to try without noapic. I assume you've done that - what were the results? Next, this could be an issue with other HW routed to IRQ 11, not the firewire controller. Other devices set up for IRQ11: 0000:06:09 yenta cardbus controller 0000:00:14.6 internal modem, no driver loaded (snd_atiixp_modem) 0000:00:14.5 audio The only interrupt handler installed is the audio handler (snd_snd_atiixp_interrupt).
In order to rule out problems with the audio driver: does it help to move the atiixp module out of the way? Or the yenta_socket module?
Yeah, it works fine without noapic. But since Andi had been pushing for noapic to be the default, I thought it might be a good idea to test it on my 10.0b3 system. Moving yenta_socket or snd-atiixp out of the way just changes the list of handlers. Moving ohci1394 out of the way does fix the problem.
Created attachment 48637 [details] dmesg w/o noapic
Created attachment 48638 [details] hwinfo w/o noapic
Created attachment 48639 [details] another dmesg w/ noapic This dmesg has a different trace for the "nobody cared" message that is quite a bit simpler and doesn't involve ACPI. (Not that it necessarily exempts ACPI)
It does indeed seem as if the card is posting an interrupt before the driver has even activated it. In the first oops, the interrupt comes through immediately while setting up the irq routing; before we've touched even a single register on this device. I suggest closing this as wontfix, especially given that the default config (no using noapic) currently works.
Or it's a bios issue. To what extent do you allow your BIOS to set up any devices for you at boot time?
I have no control over how the BIOS sets up devices. Unfortunately, the BIOS allows very little control beyond a password and which device to boot from.
In order to move forward, I'm going to close this one. Seems this notebook has several BIOS issues ;)