DragonFly bugs List (threaded) for 2006-10
Re: [issue352] SMP weirdness in 1.6.2-RELEASE
:Mike Jakubik <mikej@xxxxxxxxxx> added the comment:
:Disabling APIC_IO seems to make the system sane. Are there any negative effects
:from disabling it?
:P.S. Although this is an old beast, I do not think this is a hardware problem,
:as it works just fine with Windows 2003 and FreeBSD 6 (with APIC).
Mostly things that go unnoticed. The PIC has fewer IRQs then the APICs,
so more devices will wind up sharing an IRQ, and all PIC interrupts
are routed to cpu #0 (but at the moment we do that anyway even for
APIC_IO so no loss there). Some PC hardware routes a catch-all IRQ
to the PIC as well, usually to IRQ 7 or IRQ 15, and on such hardware
you pretty much have to disable the PIC entirely to get rid of the
spurious interrupts. Eventually PC hardware will stop supporting the
old PIC entirely. Some already don't.
For DragonFly this means we will have to play catch-up with FreeBSD
with regards to moving away from using the 8254 timer (using the LAPIC
timer instead), which allows us to disable the PIC entirely, and then
use APIC_IO. Eventually.
At the moment there are many, MANY BIOSes whos MP tables are totally
broken when it comes to IO APIC pin assignments. Yours is one of
those BIOSes. Such systems often have a working PIC, though, so
commenting out APIC_IO usually does the trick. ACPI is supposed to
replace the MP table but ACPI has its own problems. There are *FOUR*
BIOS interrupt routing interfaces and all of them are broken to some
degree or other.