Re: irq 9: nobody cared (try booting with the "irqpoll" option)

Re: irq 9: nobody cared (try booting with the "irqpoll" option)

[Stefan Richter]

(Full quote for LKML)

Akkana Peck wrote:
> I've been participating in a thread on the linux-usb list about an
> IRQ conflict problem several of us have seen with 2.6.21 and 2.6.22
> (which didn't happen with earlier kernels).
> 
> The full thread starts at
> http://www.mail-archive.com/linux-usb-users@lists.sourceforge.net/msg18856.html
> but I'll summarize: at boot time, the kernel finds contention over
> an IRQ (23 for the original poster, 9 for me), prints the "nobody
> cared" message and a list of handlers, then disables the IRQ (which
> of course makes things fail). My machine is a Vaio SR17, while the
> OP's is a Lenovo T61. booting with irqpoll does solve the problem,
> but it's not a solution I wanted to run with in the long term.
> 
> I got suspicious because one of the handlers was reported as
> [<c02c1e50>] (ohci_irq_handler+0x0/0x920)
> which seemed odd because my machine uses UHCI for USB and doesn't
> have OHCI in the kernel at all. But it turned out the problem wasn't
> UHCI for USB, but OHCI1394, and building a kernel without that driver
> made everything else work fine.
> 
> I don't use Firewire much, so that solves the problem for me, but
> I wanted to report this since it seems like 1394 has a problem on
> some machines. (I've seen reports of the problem elsewhere too --
> there's an ubuntu bug, and googling found a few other examples.)
> 
> I'd be happy to post further details or run tests, if anyone
> is interested.
> 
> 	...Akkana

I am not aware of anything that a PCI driver like ohci1394 could do
about it.  Somebody correct me if I'm wrong, but this is between the
BIOS and low-level code for the x86 PC platform.

Is anybody aware of relevant changes from 2.6.20 to 2.6.21 that could
have introduced this regression?
-- 
Stefan Richter
-=====-=-=== -=== =----
http://arcgraph.de/sr/