Hello,

Not sure if this is appropriate for ACPI or kernel list so I Cc: both.

On my MS-6163 v3.0 (BX Master) board, the IO-APIC was previously being
used before a blacklist was incorrectly added last year.  Now that the
blacklist is removed when I upgraded to 2.4.23, ACPI doesn't seem to
want to enable IO-APIC usage (dmesg attached).  I don't remember whether
or not I had ACPI enabled when the IO-APIC was working a long time ago.

I added some debug statements to arch/i386/kernel/acpi.c/acpi_boot_init()
to try to diagnose the code flow.  However, when recompiling, almost the entire
kernel must be rebuilt for dependencies, which takes forever on my poor
machine... :(  So I didn't want to spend much more time without some outside
opinion of the situation.

But, as you can see from dmesg, it gets here:
|
===>        printk(KERN_INFO PREFIX "past blacklist\n");

#ifdef CONFIG_X86_LOCAL_APIC

        /* 
         * MADT
         * ----
         * Parse the Multiple APIC Description Table (MADT), if exists.
         * Note that this table provides platform SMP configuration 
         * information -- the successor to MPS tables.
         */

XXX     result = acpi_table_parse(ACPI_APIC, acpi_parse_madt);
        if (!result) {
                return 0;
        }
        else if (result < 0) {
                printk(KERN_ERR PREFIX "Error parsing MADT\n");
                return result;
        }
        else if (result > 1)
                printk(KERN_WARNING PREFIX "Multiple MADT tables exist\n");

===>        printk(KERN_INFO PREFIX "past MADT\n")
|
but not here.  There are no other kernel messages printed, so I think XXX is the
failing part.  Why would that happen?  Is it because this is a UP machine and
the call only works for SMP?  (CONFIG_X86_LOCAL_APIC is definitely enabled)

Is it possible that IO-APIC and ACPI can work individually but be mutually
exclusive on a system if the ACPI tables don't correctly describe the IO-APIC?

I have only a shallow understanding of how this works (from reading www.acpi.info
and kernel source) so please bear with me if I am overlooking something obvious.

thanks,

-- 
Ryan Underwood, <nemesis@icequake.net>