[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <200610190133.40581.len.brown@intel.com>
Date: Thu, 19 Oct 2006 01:33:40 -0400
From: Len Brown <len.brown@...el.com>
To: Dave Jones <davej@...hat.com>
Cc: Linux Kernel <linux-kernel@...r.kernel.org>,
linux-acpi@...r.kernel.org
Subject: Re: SMP broken on pre-ACPI machine.
On Wednesday 18 October 2006 18:24, Dave Jones wrote:
> 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.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists