Re: [issue352] SMP weirdness in 1.6.2-RELEASE

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>