Skip to contentSkip to conversation

SMP broken on pre-ACPI machine.

DISCUSSION Dave Jones 4 participants 9 messages Oct 18, 2006 – Oct 19, 2006 ACPI

lore
Share & tools
lore

Dave Jones

author
#0 lore raw

I've been chasing a bug that got filed against the Fedora kernel a while back: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199052
This is a dual pentium pro from an era before we had ACPI, and it seems to be falling foul of this test in smpboot.c ..

    if (!smp_found_config && !acpi_lapic) {
        printk(KERN_NOTICE "SMP motherboard not detected.\n");
        smpboot_clear_io_apic_irqs();
        phys_cpu_present_map = physid_mask_of_physid(0);
        if (APIC_init_uniprocessor())
            printk(KERN_NOTICE "Local APIC not detected."
                       " Using dummy APIC emulation.\n");
        map_cpu_to_logical_apicid();
        cpu_set(0, cpu_sibling_map[0]);
        cpu_set(0, cpu_core_map[0]);
        return;
    }

My initial reaction is that the !acpi_lapic test should be conditional on some variable that gets set if the ACPI parsing actually succeeded.

Thoughts?

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#1 lore raw
Quoted 19 lines · Dave Jones

I've been chasing a bug that got filed against the Fedora kernel a while back: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199052
This is a dual pentium pro from an era before we had ACPI, and it seems to be falling foul of this test in smpboot.c ..

    if (!smp_found_config && !acpi_lapic) {
        printk(KERN_NOTICE "SMP motherboard not detected.\n");
        smpboot_clear_io_apic_irqs();
        phys_cpu_present_map = physid_mask_of_physid(0);
        if (APIC_init_uniprocessor())
            printk(KERN_NOTICE "Local APIC not detected."
                       " Using dummy APIC emulation.\n");
        map_cpu_to_logical_apicid();
        cpu_set(0, cpu_sibling_map[0]);
        cpu_set(0, cpu_core_map[0]);
        return;
    }
Quoted 7 lines

My initial reaction is that the !acpi_lapic test should be conditional on some variable that gets set if the ACPI parsing actually succeeded.

Thoughts?

Dave

acpi=off ? this machine should work with APM. BTW, so time ago, this machine would enter in ACPI blacklist (by the year of bios) and ACPI was turned off automatically.

Signature · 1 line
Sérgio M.B.
#2 lore raw
In reply to Dave Jones
Quoted 19 lines · Dave Jones

I've been chasing a bug that got filed against the Fedora kernel a while back: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199052
This is a dual pentium pro from an era before we had ACPI, and it seems to be falling foul of this test in smpboot.c ..

    if (!smp_found_config && !acpi_lapic) {
        printk(KERN_NOTICE "SMP motherboard not detected.\n");
        smpboot_clear_io_apic_irqs();
        phys_cpu_present_map = physid_mask_of_physid(0);
        if (APIC_init_uniprocessor())
            printk(KERN_NOTICE "Local APIC not detected."
                       " Using dummy APIC emulation.\n");
        map_cpu_to_logical_apicid();
        cpu_set(0, cpu_sibling_map[0]);
        cpu_set(0, cpu_core_map[0]);
        return;
    }
Quoted 7 lines

My initial reaction is that the !acpi_lapic test should be conditional on some variable that gets set if the ACPI parsing actually succeeded.

Thoughts?

Dave

acpi=off ? this machine should work with APM. BTW, so time ago, this machine would enter in ACPI blacklist (by the year of bios) and ACPI was turned off automatically.

Signature · 1 line
Sérgio M.B.
author
#3 lore raw
Quoted 6 lines · Sergio Monteiro Basto
Quoted 5 lines · Dave Jones

I've been chasing a bug that got filed against the Fedora kernel a while back: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199052
This is a dual pentium pro from an era before we had ACPI, and it seems to be falling foul of this test in smpboot.c ..

Quoted 7 lines
Quoted 5 lines
    if (!smp_found_config && !acpi_lapic) {
        printk(KERN_NOTICE "SMP motherboard not detected.\n");

My initial reaction is that the !acpi_lapic test should be conditional on some variable that gets set if the ACPI parsing actually succeeded.

acpi=off ?

This is irrelevant. There are no acpi tables, so acpi will disable itself.

Quoted 1 line

this machine should work with APM.

Also irrelevant, as power management isn't the problem here.

Quoted 3 lines

BTW, so time ago, this
machine would enter in ACPI blacklist (by the year of bios) and ACPI was turned off automatically.

Finally, this machine has no DMI tables, so date blacklists are also useless. (Not that it matters anyway due to the lack of ACPI tables)

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#4 lore raw
In reply to Dave Jones
Quoted 19 lines · Dave Jones

I've been chasing a bug that got filed against the Fedora kernel a while back: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199052
This is a dual pentium pro from an era before we had ACPI, and it seems to be falling foul of this test in smpboot.c ..

    if (!smp_found_config && !acpi_lapic) {
        printk(KERN_NOTICE "SMP motherboard not detected.\n");
        smpboot_clear_io_apic_irqs();
        phys_cpu_present_map = physid_mask_of_physid(0);
        if (APIC_init_uniprocessor())
            printk(KERN_NOTICE "Local APIC not detected."
                       " Using dummy APIC emulation.\n");
        map_cpu_to_logical_apicid();
        cpu_set(0, cpu_sibling_map[0]);
        cpu_set(0, cpu_core_map[0]);
        return;
    }
Quoted 2 lines

My initial reaction is that the !acpi_lapic test should be conditional on some variable that gets set if the ACPI parsing actually succeeded.

acpi_lapic isn't related to the problem at hand -- that smp_found_config is not set.

That said, allowing acpi_lapic=1 to bail out of this check has the sole function of allowing SMP/PIC configurations. (smp_found_config in ACPI mode is set if acpi_lapic and acpi_ioapic are set) SMP/PIC configurations are not very interesting, except for debugging. Indeed, MPS prohibits them by mandating an IOAPIC be present for SMP -- but ACPI has no such rule.

-Len

author
#5 lore raw
Quoted 6 lines · Len Brown
Quoted 5 lines · Dave Jones

I've been chasing a bug that got filed against the Fedora kernel a while back: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199052
This is a dual pentium pro from an era before we had ACPI, and it seems to be falling foul of this test in smpboot.c ..

Quoted 7 lines
Quoted 5 lines
    if (!smp_found_config && !acpi_lapic) {
        printk(KERN_NOTICE "SMP motherboard not detected.\n");

My initial reaction is that the !acpi_lapic test should be conditional on some variable that gets set if the ACPI parsing actually succeeded.

acpi_lapic isn't related to the problem at hand -- that smp_found_config is not set.

Right, it just seemed odd to me when I was eyeballing this code.

Quoted 6 lines

That said, allowing acpi_lapic=1 to bail out of this check has the sole function of allowing SMP/PIC configurations. (smp_found_config in ACPI mode is set if acpi_lapic and acpi_ioapic are set) SMP/PIC configurations are not very interesting, except for debugging. Indeed, MPS prohibits them by mandating an IOAPIC be present for SMP -- but ACPI has no such rule.

Why smp_found_config isn't set in that guys configuration is a mystery to me, as his MPS tables look sane..

MP Table:
# APIC ID Version State Family Model Step Flags
# 0 0x10 BSP, usable 6 2 1 0x0381
# 0 0x10 AP, usable 6 1 7 0xfbff

Hmm, wait, he has unpaired CPUs. I wonder if that's the reason. I know *some* combinations of PPro's are valid to be paired, but I'll need to dig out the old docs to be sure.

Dave

Signature · 1 line
http://www.codemonkey.org.uk
author
#6 lore raw
Quoted 11 lines · Dave Jones

Why smp_found_config isn't set in that guys configuration is a mystery to me, as his MPS tables look sane..

MP Table:
# APIC ID Version State Family Model Step Flags
# 0 0x10 BSP, usable 6 2 1 0x0381
# 0 0x10 AP, usable 6 1 7 0xfbff

Hmm, wait, he has unpaired CPUs. I wonder if that's the reason. I know *some* combinations of PPro's are valid to be paired, but I'll need to dig out the old docs to be sure.

Ok, after reading http://www.intel.com/design/archives/processors/pro/docs/242689.htm
I'm more puzzled than ever. There never was a model 2 Pentium Pro. Either this BIOS is on crack and putting nonsense in its MPS tables,
or this is a hardware flaw of some sort.

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#7 lore raw

Ar Iau, 2006-10-19 am 16:11 -0400, ysgrifennodd Dave Jones:

Quoted 8 lines · Dave Jones
Quoted 7 lines

Why smp_found_config isn't set in that guys configuration is a mystery to me, as his MPS tables look sane..

MP Table:
# APIC ID Version State Family Model Step Flags
# 0 0x10 BSP, usable 6 2 1 0x0381

Isn't that an "overdrive" ? if so it isn't supposed to be SMP capable

author
#8 lore raw
Quoted 11 lines · Alan Cox

Ar Iau, 2006-10-19 am 16:11 -0400, ysgrifennodd Dave Jones:

Quoted 8 lines · Dave Jones
Quoted 7 lines

Why smp_found_config isn't set in that guys configuration is a mystery to me, as his MPS tables look sane..

MP Table:
# APIC ID Version State Family Model Step Flags
# 0 0x10 BSP, usable 6 2 1 0x0381

Isn't that an "overdrive" ? if so it isn't supposed to be SMP capable

I don't think so. The only overdrive that fitted in a socket 8 board was a PPro->PentiumII thing, which would be model 3 stepping 2 as far as I can figure out from a lengthy archeology trip through developer.intel.com.

There were also some Socket8->Socket370 convertors, but afaik they just passed through the family/model/stepping of whatever was plugged into them.

Dave

Signature · 1 line
http://www.codemonkey.org.uk