[coreboot] IRQ 9 on s2895 and s2892

Myles Watson mylesgw at gmail.com
Wed Mar 11 18:22:57 CET 2009

On Tue, Mar 10, 2009 at 5:06 PM, Rudolf Marek <r.marek at assembler.cz> wrote:
>> I'm extracting this from a different thread hoping for more help :)
>> How do you find an interrupt source that's going crazy like that?
>> When I boot with acpi=off I IRQ9 doesn't even get registered.
> This matches whats going on. The shared IRQ handler for IRQ9 looks to all
> functions which has registered via request_irq. Each such function returns
> IRQ_HANDLED or IRQ_NONE when it detects its not their iRQ.
> To get a source look to:
> 1) superIO config
I'm assuming that since I have the problem on my Tyan s2895 and s2892,
and they have different superIOs that that's not the problem.  What do
you think?

> 2) PCI IRQ router inside SB (it is used to route the IRQ to 8259, its just a
> bit more complex multiplexor which decides if IRQ goes to APIC or 8259 or
> both.

Ah.  I'm sorry I think you've tried to tell me this multiple times but
I've missed it.  You're saying that the IRQ is getting sent to two
different IRQs and one of them has a handler, but the other doesn't?

In that case we can narrow it down because only a few IRQs have counts
>= IRQ9.  Right?

> I cannot find anything about nvidia IRQ routers :/ I hate no-docs state!

Yes.  I don't have another option right now.  There aren't very many
boards with multiple PCI root buses on different Opterons.

> 3) by observation
>   a) boot kernel with initramfs filesystem (or initrd)
>   b) mount /proc/
>   c) observe if any activity is on that IRQ
>   d) if not load some drivers for PCI devices (network etc...)
>   e) or even better try without ethernet plugged, USB...
> Or better method is to hack the "disabling IRQ" handler and printk the
> interrupt counter there to see if it matches some other count.

Thanks for your help!


> Rudolf

More information about the coreboot mailing list