All of lore.kernel.org
 help / color / mirror / Atom feed
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
>
>
>   

  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.