From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <ak@muc.de>
Cc: Gerhard Mack <gmack@innerfire.net>,
Tommy Faasen <tommy@vuurwerk.nl>,
linux-kernel@vger.kernel.org
Subject: Re: SMP processor rework help needed
Date: 15 Oct 2001 09:20:25 -0600 [thread overview]
Message-ID: <m18zedorpi.fsf@frodo.biederman.org> (raw)
In-Reply-To: <k2wv1yhsh4.fsf@zero.aec.at> <Pine.LNX.4.10.10110141349510.31660-100000@innerfire.net> <20011014230709.47894@colin.muc.de>
In-Reply-To: <20011014230709.47894@colin.muc.de>
Andi Kleen <ak@muc.de> writes:
> On Sun, Oct 14, 2001 at 10:50:50PM +0200, Gerhard Mack wrote:
> > This may sound like a dumb question but wouldn't simply swapping the CPUs
> > have the same affect?
>
> In theory yes, assuming the determination of the boot cpu is fully
> deterministic. the spec says it is the one with the lowest apic number; but
> who knows if that is true in every weird board.
I do recall that the apics have programmable numbers. We even test
that as part of our cpu initialization. So that means little.
For intel the initial determination is made having the cpus race on
the apic bus. The cpu that sends a message first gets the lowest
apicid. Though I need to see how the P4 Xeon does it, as the apic
bus is actually unused.
Also many boards have logic so that allows the second cpu to become the
boot cpu if the first cpu fails to boot. This logic might be as
simple as round-robin, so even a deterministic may make this
difficult.
So the only reliable way to force the boot cpu is with software that
runs before the operating system, usually the firmware.
I'll keep this in mind for linuxBIOS, as that would be an ideal place
to implement something like that.
Eric
next prev parent reply other threads:[~2001-10-15 15:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-14 20:23 SMP processor rework help needed Tommy Faasen
2001-10-14 20:33 ` Andi Kleen
2001-10-14 20:50 ` Gerhard Mack
2001-10-14 21:07 ` Andi Kleen
2001-10-15 15:20 ` Eric W. Biederman [this message]
2001-10-14 22:09 ` Tommy Faasen
2001-10-15 5:07 ` Pascal Schmidt
2001-10-15 21:25 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2001-10-15 17:16 Manfred Spraul
2001-10-15 21:39 ` Alan Cox
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=m18zedorpi.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=ak@muc.de \
--cc=gmack@innerfire.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tommy@vuurwerk.nl \
/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.