lenovo R60 SMP/APIC_IO woes
atrens at nortel.com
Mon Apr 23 06:26:32 PDT 2007
Matthew Dillon wrote:
> :In the last few hours I've noted about 24 'stray interrupt 7' messages while
> :running SMP (no IOAPIC) .. I'm guessing that these are incorrectly routed
> No, its probably a summary interrupt from the IOAPIC. Because the BIOS
> is stupid, hardware chipsets are often able to route *ALL* of the masked
> IOAPIC interrupts to a single PIC interrupt. It's usually IRQ 7 or
> IRQ 15. Since the method to disable this routing is not usually
> documented, we have no way of turning it off short of hoping that the
> BIOS knows how to do it when we use the IOAPIC. Some IOAPICs
> automatically route this special interrupt if their pins are masked.
> Unfortunately, pin masking is a normal part of our interrupt handling
> code (linux does something nutty to try to avoid pin masking).
> The only real solution is for us to not use IRQ 7 at all and just
> mask it out on the PIC.
> :> kern.emergency_intr_enable (default 0 = off)
> :> kern.emergency_intr_freq (default 10 = 10hz)
> :Do these need to be set by the bootloader, I suppose so, eh ?
> It can be set by the bootloader and/or at run-time with a sysctl.
> :Thanks for all the info, Matt! As always you're a great help!
> :. any ideas about my other problem (previous message) wrt 1/2 speed kernel builds?
> All I can think of is that its having real problems routing interrupts.
> Are you using emergency interrupt polling or does it work without that?
It works without emergency interrupt polling. My compile tests were run with SMP (no IO_APIC and
no emergency interrupt polling).
I'm just now re-running my kernel compile test with e-i-p enabled to see if it improves the speed.
Okay, that's better - compile time dropped from 13 minutes to just over 7 minutes! That's roughly
the same as my UP kernel compile time.
Now I'll try with -j 2 to see if that helps ..
Whoa! 4 minutes! Very cool!
Mucho better! :) :)
Now .. speculating as to the cause ... could it be that interrupts are only being delivered to
CPU0 and not CPU1 ? That would explain the roughly 1/2 speed slow down during the test if both
cpus were alternating running compile processes ..
More information about the Bugs