From: xb <xavier.bru@bull.net>
Cc: linux-acpi@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: SRAT v1 support
Date: Mon, 18 May 2009 13:19:24 +0200 [thread overview]
Message-ID: <4A11443C.2010602@bull.net> (raw)
In-Reply-To: <86802c440905151138t42705477s95a972704db2ce9c@mail.gmail.com>
yes, could be simpler :-)
I just saw that Kurt Garloff from Suse has published 3 patches on
kernel mailing list that fixes the SRAT v1 issue:
[PATCH 0/3]: Discard reserved PXM bits for SRAT v1
[PATCH 1/3]: Store SRAT revision
[PATCH 2/3]: x86-64: Handle SRAT v1 and v2 consistently
It looks OK for us.
Thanks.
Xavier
Yinghai Lu wrote:
> On Fri, May 15, 2009 at 7:51 AM, xb <xavier.bru@bull.net> wrote:
>
>> Recent linux kernels suppose that the SRAT table is in rev 2 format (ACPI
>> 3.0), but some BIOSes still provide SRAT table in rev 1.
>> The rev 2 of the SRAT extension mainly provides an extension of the
>> "proximity_domain" item from 8 bits to 32 bits, using a "reserved" field of
>> the structure.
>> When the "reserved" field is not null, linux finds a wrong proximity domain,
>> and numa initialization is wrong.
>> Following patch tests the SRAT revision to allow a correct initialization:
>>
>> This patch tests the version of SRAT ACPI table to allow supporting SRAT rev
>> 1 and SRAT rev 2.
>>
>> diff -Nru linux-2.6.29-rc7-orig/arch/x86/kernel/acpi/boot.c
>> linux-2.6.29-rc7-tmp/arch/x86/kernel/acpi/boot.c
>> --- linux-2.6.29-rc7-orig/arch/x86/kernel/acpi/boot.c 2009-03-12
>> 14:41:38.000000000 +0100
>> +++ linux-2.6.29-rc7-tmp/arch/x86/kernel/acpi/boot.c 2009-03-16
>> 14:52:07.000000000 +0100
>> @@ -260,7 +260,8 @@
>> }
>>
>> static int __init
>> -acpi_parse_lapic(struct acpi_subtable_header * header, const unsigned long
>> end)
>> +acpi_parse_lapic(const struct acpi_subtable_header * const header,
>> + const unsigned long end, const int rev)
>>
>
> do we need to pass that rev all over around?
>
> looks like we could use one srat_version or pxm_mask variable to get
> the same result.
>
> YH
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: xb <xavier.bru@bull.net>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-acpi@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: SRAT v1 support
Date: Mon, 18 May 2009 13:19:24 +0200 [thread overview]
Message-ID: <4A11443C.2010602@bull.net> (raw)
In-Reply-To: <86802c440905151138t42705477s95a972704db2ce9c@mail.gmail.com>
yes, could be simpler :-)
I just saw that Kurt Garloff from Suse has published 3 patches on
kernel mailing list that fixes the SRAT v1 issue:
[PATCH 0/3]: Discard reserved PXM bits for SRAT v1
[PATCH 1/3]: Store SRAT revision
[PATCH 2/3]: x86-64: Handle SRAT v1 and v2 consistently
It looks OK for us.
Thanks.
Xavier
Yinghai Lu wrote:
> On Fri, May 15, 2009 at 7:51 AM, xb <xavier.bru@bull.net> wrote:
>
>> Recent linux kernels suppose that the SRAT table is in rev 2 format (ACPI
>> 3.0), but some BIOSes still provide SRAT table in rev 1.
>> The rev 2 of the SRAT extension mainly provides an extension of the
>> "proximity_domain" item from 8 bits to 32 bits, using a "reserved" field of
>> the structure.
>> When the "reserved" field is not null, linux finds a wrong proximity domain,
>> and numa initialization is wrong.
>> Following patch tests the SRAT revision to allow a correct initialization:
>>
>> This patch tests the version of SRAT ACPI table to allow supporting SRAT rev
>> 1 and SRAT rev 2.
>>
>> diff -Nru linux-2.6.29-rc7-orig/arch/x86/kernel/acpi/boot.c
>> linux-2.6.29-rc7-tmp/arch/x86/kernel/acpi/boot.c
>> --- linux-2.6.29-rc7-orig/arch/x86/kernel/acpi/boot.c 2009-03-12
>> 14:41:38.000000000 +0100
>> +++ linux-2.6.29-rc7-tmp/arch/x86/kernel/acpi/boot.c 2009-03-16
>> 14:52:07.000000000 +0100
>> @@ -260,7 +260,8 @@
>> }
>>
>> static int __init
>> -acpi_parse_lapic(struct acpi_subtable_header * header, const unsigned long
>> end)
>> +acpi_parse_lapic(const struct acpi_subtable_header * const header,
>> + const unsigned long end, const int rev)
>>
>
> do we need to pass that rev all over around?
>
> looks like we could use one srat_version or pxm_mask variable to get
> the same result.
>
> YH
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
next prev parent reply other threads:[~2009-05-18 11:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-15 14:51 SRAT v1 support xb
2009-05-15 18:38 ` Yinghai Lu
2009-05-15 18:38 ` Yinghai Lu
2009-05-18 11:19 ` xb [this message]
2009-05-18 11:19 ` xb
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=4A11443C.2010602@bull.net \
--to=xavier.bru@bull.net \
--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.