lenovo R60 SMP/APIC_IO woes

[Andrew Atrens]

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
> :interrupts?
> 
>     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?
> :
> :Cheers,
> :
> :Andrew
> 
>     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 ..

Andrew