All of lore.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <len.brown@intel.com>
To: Dave Jones <davej@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, linux-acpi@vger.kernel.org
Subject: Re: SMP broken on pre-ACPI machine.
Date: Thu, 19 Oct 2006 01:33:40 -0400	[thread overview]
Message-ID: <200610190133.40581.len.brown@intel.com> (raw)
In-Reply-To: <20061018222433.GA4770@redhat.com>

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

  parent reply	other threads:[~2006-10-19  5:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-18 22:24 SMP broken on pre-ACPI machine Dave Jones
2006-10-18 23:45 ` Sergio Monteiro Basto
2006-10-18 23:48 ` Sergio Monteiro Basto
2006-10-19  3:04   ` Dave Jones
2006-10-19  5:33 ` Len Brown [this message]
2006-10-19 19:16   ` Dave Jones
2006-10-19 20:11     ` Dave Jones
2006-10-19 22:17       ` Alan Cox
2006-10-19 23:20         ` Dave Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610190133.40581.len.brown@intel.com \
    --to=len.brown@intel.com \
    --cc=davej@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.