On Tue, Mar 10, 2009 at 5:06 PM, Rudolf Marek r.marek@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:
- 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?
- 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.
- 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