On Tue, Mar 10, 2009 at 5:06 PM, Rudolf Marek <[email protected]> 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 > -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
