From: Mike Travis <travis@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: put trigger in to detect mismatched apic versions.
Date: Fri, 16 Jan 2009 16:06:04 -0800 [thread overview]
Message-ID: <497120EC.1080201@sgi.com> (raw)
In-Reply-To: <497116A8.5080900@sgi.com>
Mike Travis wrote:
> Ingo Molnar wrote:
>> * Mike Travis <travis@sgi.com> wrote:
>>
>>> Hi Ingo,
>>>
>>> I did notice that the versions all came up the same, and that the checks
>>> were very specific. I was trying to be as transparent and unintrusive
>>> as possible. Since there's so few calls, I though this was a good
>>> approach but apparently I was wrong.
>>>
>>> I like the idea of collapsing the array down to one and checking to see
>>> if all apic's have the same version, but is this really the case? Must
>>> all apics be the same?
>> Could you please send a patch that doesnt change the code, only adds a
>> 'boot APIC version' kind of variable as an apic_version __read_mostly
>> variable and does a WARN_ONCE() if that mismatches? We can then stick that
>> into -tip and see whether it triggers.
>>
>> The max array size is ~128K, right? So if the WARN_ONCE() does not
>> trigger, we can just drop the array and use the central apic_version
>> variable ...
>>
>> And even if it _does_ trigger, the version incompatibilities between APIC
>> protocols are very rare. They only happen across wildly different CPU
>> architectures like when going from very old external apics to integrated
>> apics, or going from apics to x-apics. We wont see any mixing across those
>> boundaries.
>>
>> Ingo
>
> Btw, I checked with our UV architect and the problem is that we need a
> 16 bit apic id which is what caused the MAX_APICS to be bumped to 32k.
> The lower 8 bits are the normal apic id, and the upper bit relate to
> the node. This means cpu 0 on node 0 has the same apic id as cpu 0 on
> node 1, etc. I also asked about whether we could rely on always having
> the same apic version, and the answer was yes, though it's really only
> relevant between the cpus on a node.
>
> Thanks,
> Mike
> ---
> Subject: x86: put trigger in to detect mismatched apic versions.
>
> Fire off one message if two apic's discovered with different
> apic versions.
>
> Signed-off-by: Mike Travis <travis@sgi.com>
> ---
> arch/x86/kernel/apic.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> --- linux-2.6-for-ingo.orig/arch/x86/kernel/apic.c
> +++ linux-2.6-for-ingo/arch/x86/kernel/apic.c
> @@ -1833,6 +1833,11 @@ void __cpuinit generic_processor_info(in
> num_processors++;
> cpu = cpumask_next_zero(-1, cpu_present_mask);
>
> + if (version != apic_version[boot_cpu_physical_apicid])
> + WARN_ONCE(1,
> + "ACPI: apic version mismatch, bootcpu: %x cpu %d: %x\n",
> + apic_version[boot_cpu_physical_apicid], cpu, version);
> +
> physid_set(apicid, phys_cpu_present_map);
> if (apicid == boot_cpu_physical_apicid) {
> /*
I've pushed this one to my-for-you git tree as well.
(Seems awful quiet ... is everyone heading to Australia? ;-)
Thanks,
Mike
-- -
The following changes since commit 6eb714c63ed5bd663627f7dda8c4d5258f3b64ef:
Mike Travis (1):
cpufreq: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git master
Mike Travis (1):
x86: put trigger in to detect mismatched apic versions.
arch/x86/kernel/apic.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
next prev parent reply other threads:[~2009-01-17 0:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 9:05 [PULL}: latest tip/cpus4096 changes Mike Travis
2009-01-16 9:25 ` Ingo Molnar
2009-01-16 17:53 ` Mike Travis
2009-01-16 22:30 ` Ingo Molnar
2009-01-16 23:22 ` [PATCH] x86: put trigger in to detect mismatched apic versions Mike Travis
2009-01-17 0:06 ` Mike Travis [this message]
2009-01-17 3:07 ` Jack Steiner
2009-01-18 19:08 ` Ingo Molnar
2009-01-18 21:25 ` Jack Steiner
2009-01-19 17:08 ` Mike Travis
2009-01-18 19:04 ` Ingo Molnar
2009-01-16 9:28 ` [PULL}: latest tip/cpus4096 changes Ingo Molnar
2009-01-16 17:54 ` Mike Travis
2009-01-16 9:34 ` Ingo Molnar
2009-01-16 17:08 ` Jeremy Fitzhardinge
2009-01-16 19:55 ` Mike Travis
2009-01-16 21:15 ` Jeremy Fitzhardinge
2009-01-16 17:55 ` Mike Travis
2009-01-16 14:25 ` Ingo Molnar
2009-01-16 18:03 ` Mike Travis
2009-01-16 22:32 ` Ingo Molnar
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=497120EC.1080201@sgi.com \
--to=travis@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.