From: Andi Kleen <ak@suse.de>
To: Ronald G Minnich <rminnich@lanl.gov>
Cc: Andi Kleen <ak@suse.de>, yhlu <yhlu.kernel@gmail.com>,
discuss@x86-64.org, linuxbios@openbios.org,
linux-kernel@vger.kernel.org
Subject: Re: [LinuxBIOS] x86_64: apic id lift patch
Date: Wed, 23 Nov 2005 18:35:05 +0100 [thread overview]
Message-ID: <20051123173504.GK20775@brahms.suse.de> (raw)
In-Reply-To: <43849FA5.4020201@lanl.gov>
> At the same time, we seem to be treading in territory where the fuctory
> BIOSes have not yet been. We're in the weird position, at times, of
> finding things out before the proprietary BIOSes get there.
You're saying that Arima machine only runs with LinuxBIOS so far?
>
> Sometimes the ease of updating the BIOS can cause troubles you don't
> expect. Fuctory BIOSes seem to count on infrequent updates, forked code
> bases, and so on, so that you have to update each mainboard source base
> individually -- they have the disadvantage of a forked code base, but
> the one advantage is that a mod to fix one platform won't ever break
> another.
>
> At some point I had understood that linux was going to be able to
> function without resorting to SRAT tables -- has that changed? Is this
SRAT is definitely the wave of the future. I'm going to keep
the old code working as long as it's relatively cleanly possible.
But this needs to make some assumptions, and in particular your
discontiguous APIC IDs broke that. I don't plan to try to handle
every weird case in this case - if your setup is really
weird use SRAT.
Regarding the BSP 0 - you probably just have a stupid bug
somewhere that breaks the timer interrupt. I don't know
of any hardware issue that would prevent the timer interrupt
going to a APIC ID != 0. There are some troubles with timer
interrupts, but they are different issues. IMHO the discontig
APIC IDs was just a workaround because you didn't want to fix
the interrupt routing properly, with the burden on the kernel.
You have two options now:
- Trace down why interrupt 0 doesn't work with BSP LAPIC != 0
and fix that.
- Provide SRAT.
First is probably better, although the second also wouldn't hurt.
> patch really intrusive enough that it is not acceptable? The issue is
Yes it complicates the logic enough and makes it more fragile,
which would be a long term maintenance issue. The only way
to keep the fallback code alive at all is to keep it simple
and clean.
-Andi
next prev parent reply other threads:[~2005-11-23 17:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 21:49 x86_64: apic id lift patch yhlu
2005-11-21 22:06 ` Andi Kleen
2005-11-21 22:17 ` yhlu
2005-11-21 22:24 ` Andi Kleen
2005-11-21 22:31 ` yhlu
2005-11-22 9:44 ` Andi Kleen
2005-11-23 16:58 ` [LinuxBIOS] " Ronald G Minnich
2005-11-23 17:35 ` Andi Kleen [this message]
[not found] ` <2ea3fae10511230943y5f697eb8sdbf891497fa8b88f@mail.gmail.com>
2005-11-23 17:50 ` Andi Kleen
2005-11-23 18:01 ` yhlu
2005-11-23 20:29 ` [discuss] " Andi Kleen
2005-11-23 20:29 ` Ronald G Minnich
2005-11-23 18:28 ` Stefan Reinauer
2005-11-23 20:26 ` Ronald G Minnich
[not found] ` <2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
2005-11-23 17:36 ` Andi Kleen
2005-11-23 17:40 ` yhlu
2005-11-23 18:18 ` Stefan Reinauer
2005-11-23 18:22 ` yhlu
2005-11-23 18:35 ` yhlu
2005-11-23 20:28 ` [discuss] " Andi Kleen
2005-11-23 18:17 ` Stefan Reinauer
2005-11-23 20:23 ` Ronald G Minnich
2005-11-23 20:34 ` [discuss] " Andi Kleen
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=20051123173504.GK20775@brahms.suse.de \
--to=ak@suse.de \
--cc=discuss@x86-64.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxbios@openbios.org \
--cc=rminnich@lanl.gov \
--cc=yhlu.kernel@gmail.com \
/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.