[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!
Myles
>
> Rudolf
>
More information about the coreboot
mailing list