All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
	kim.naru@amd.com,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems
Date: Thu, 13 Mar 2014 21:06:43 -0500	[thread overview]
Message-ID: <53226433.3090803@amd.com> (raw)
In-Reply-To: <CAErSpo6ZbKFMgcm4upR7gTnYwZ15UJpxzctOwWMsGyONipq8aw@mail.gmail.com>

On 3/12/2014 4:13 PM, Bjorn Helgaas wrote:
>> I assume the system is fully functional even without these patches,
>> >right?  The only effect of these changes should be a performance
>> >improvement.

[Suravee] Yes, the system is fully functional except the numa 
information for PCI ethernet adapters is returning -1.

>> >
>> >So the choices are:
>> >
>> >   1) Change the BIOS to provide _PXM
>> >   2) Change Linux with your patches
>> >
>> >Either way, the customer has to upgrade something.  Choice 1) gets you
>> >the performance improvement on all Linux and Windows releases, even
>> >the ones that are already in the field.

[Suravee] I agree with you on both cases and I am working with the BIOS 
team to see if they can look into this and provide fixes for the future. 
  My only concern is the device _PXM information might be specific to 
each platform vendors since they are the one deciding the number of 
northbridge to be put on the systems. Also, it's quite difficult to 
influence HW/BIOS vendor to provide fixes for older platforms unless 
some important customers are complaining to them.

>> >Choice 2) fixes future Linux
>> >distros and whatever old releases you can convince the distro to
>> >backport to, and doesn't help Windows at all.  It makes work for all
>> >the distros and we (i.e., I) have to worry about maintaining this in
>> >the future.

[Suravee] Actually, this was originally reported by Redhat (please see 
https://bugzilla.redhat.com/show_bug.cgi?id=1040440), and they are 
waiting for the fixes if we decide to fix it in the upstream Linux code 
base.

>> >I'm curious to see what your BIOS folks say.  It seems strange that
>> >after all these years, they wouldn't provide something relatively
>> >simple like _PXM, so I wonder if there's more to the story.

> I looked at this a bit more.  Your patches fill in the
> mp_bus_to_node[] table, and pci_acpi_scan_root() uses
> get_mp_bus_to_node() to get that information back out.  But
> pci_acpi_scan_root() only uses get_mp_bus_to_node() if acpi_get_pxm()
> fails, or if pxm_to_node() returns -1.

[Suravee] Correct

>
> If acpi_get_pxm() failed, that's pretty good indication that the _PXM
> method is missing or broken.  If pxm_to_node() failed, it looks like
> that could mean the SRAT table is missing or broken, and we didn't
> fill in the relevant pxm_to_node_map[] entry.  So it's possible that
> we do have a _PXM method, but there's something wrong with the SRAT.

[Suravee] I am not sure which table is the _PXM method supposed to be 
apart of.

>
> Can you collect an acpidump and complete dmesg log from a system with
> the problem?  They might be too big for the mailing list; if so, you
> can attach them to a kernel.org bugzilla and just include the URL
> here.

[Suravee] Please see https://bugzilla.kernel.org/show_bug.cgi?id=72051
I have included SRAT, SLIT and DSDT table as part of the bug. Please let 
me know if you are looking for more information.

Thank you,

Suravee



WARNING: multiple messages have this Message-ID (diff)
From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
	<kim.naru@amd.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems
Date: Thu, 13 Mar 2014 21:06:43 -0500	[thread overview]
Message-ID: <53226433.3090803@amd.com> (raw)
In-Reply-To: <CAErSpo6ZbKFMgcm4upR7gTnYwZ15UJpxzctOwWMsGyONipq8aw@mail.gmail.com>

On 3/12/2014 4:13 PM, Bjorn Helgaas wrote:
>> I assume the system is fully functional even without these patches,
>> >right?  The only effect of these changes should be a performance
>> >improvement.

[Suravee] Yes, the system is fully functional except the numa 
information for PCI ethernet adapters is returning -1.

>> >
>> >So the choices are:
>> >
>> >   1) Change the BIOS to provide _PXM
>> >   2) Change Linux with your patches
>> >
>> >Either way, the customer has to upgrade something.  Choice 1) gets you
>> >the performance improvement on all Linux and Windows releases, even
>> >the ones that are already in the field.

[Suravee] I agree with you on both cases and I am working with the BIOS 
team to see if they can look into this and provide fixes for the future. 
  My only concern is the device _PXM information might be specific to 
each platform vendors since they are the one deciding the number of 
northbridge to be put on the systems. Also, it's quite difficult to 
influence HW/BIOS vendor to provide fixes for older platforms unless 
some important customers are complaining to them.

>> >Choice 2) fixes future Linux
>> >distros and whatever old releases you can convince the distro to
>> >backport to, and doesn't help Windows at all.  It makes work for all
>> >the distros and we (i.e., I) have to worry about maintaining this in
>> >the future.

[Suravee] Actually, this was originally reported by Redhat (please see 
https://bugzilla.redhat.com/show_bug.cgi?id=1040440), and they are 
waiting for the fixes if we decide to fix it in the upstream Linux code 
base.

>> >I'm curious to see what your BIOS folks say.  It seems strange that
>> >after all these years, they wouldn't provide something relatively
>> >simple like _PXM, so I wonder if there's more to the story.

> I looked at this a bit more.  Your patches fill in the
> mp_bus_to_node[] table, and pci_acpi_scan_root() uses
> get_mp_bus_to_node() to get that information back out.  But
> pci_acpi_scan_root() only uses get_mp_bus_to_node() if acpi_get_pxm()
> fails, or if pxm_to_node() returns -1.

[Suravee] Correct

>
> If acpi_get_pxm() failed, that's pretty good indication that the _PXM
> method is missing or broken.  If pxm_to_node() failed, it looks like
> that could mean the SRAT table is missing or broken, and we didn't
> fill in the relevant pxm_to_node_map[] entry.  So it's possible that
> we do have a _PXM method, but there's something wrong with the SRAT.

[Suravee] I am not sure which table is the _PXM method supposed to be 
apart of.

>
> Can you collect an acpidump and complete dmesg log from a system with
> the problem?  They might be too big for the mailing list; if so, you
> can attach them to a kernel.org bugzilla and just include the URL
> here.

[Suravee] Please see https://bugzilla.kernel.org/show_bug.cgi?id=72051
I have included SRAT, SLIT and DSDT table as part of the bug. Please let 
me know if you are looking for more information.

Thank you,

Suravee



  parent reply	other threads:[~2014-03-14  2:06 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 21:06 [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 1/3] amd/pci: Add supports for generic AMD hostbridges suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 2/3] amd/pci: Support additional MMIO ranges capabilities suravee.suthikulpanit
2014-03-20 17:33   ` Bjorn Helgaas
2014-03-05 21:06 ` [PATCH 3/3] amd/pci: Miscellaneous code clean up for early_fillup_mp_bus_info suravee.suthikulpanit
2014-03-05 21:24 ` [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems Bjorn Helgaas
2014-03-06  2:13   ` Suravee Suthikulanit
2014-03-06  2:13     ` Suravee Suthikulanit
2014-03-06  6:30     ` Suravee Suthikulpanit
2014-03-06  6:30       ` Suravee Suthikulpanit
2014-03-06 17:40       ` Bjorn Helgaas
2014-03-06 20:03         ` Suravee Suthikulpanit
2014-03-06 20:03           ` Suravee Suthikulpanit
2014-03-11 18:12           ` Bjorn Helgaas
2014-03-12 21:13             ` Bjorn Helgaas
2014-03-13  1:30               ` Myron Stowe
2014-03-14  2:06               ` Suravee Suthikulpanit [this message]
2014-03-14  2:06                 ` Suravee Suthikulpanit
2014-03-17 17:18                 ` Bjorn Helgaas
2014-03-20 17:42                   ` Bjorn Helgaas
2014-04-19  2:53 ` [PATCH v2 0/5] x86/PCI: Add AMD hostbridge support " Myron Stowe
2014-04-19  2:53   ` [PATCH v2 1/5] x86/PCI: Add support for generic AMD hostbridges Myron Stowe
2014-04-19 11:31     ` Borislav Petkov
2014-04-28 21:10       ` Myron Stowe
2014-04-19  2:53   ` [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities Myron Stowe
2014-04-19 13:52     ` Borislav Petkov
2014-04-20  7:59       ` Borislav Petkov
2014-04-25 22:24         ` Myron Stowe
2014-04-26  9:10           ` Borislav Petkov
2014-04-28 20:50             ` Bjorn Helgaas
2014-04-28 21:40               ` Borislav Petkov
2014-04-28 21:40                 ` Borislav Petkov
2014-04-29  7:33                 ` Andreas Herrmann
2014-04-29 10:20                   ` Borislav Petkov
2014-04-29 13:07                     ` Steffen Persvold
2014-04-29 15:16                     ` Suravee Suthikulanit
2014-04-29 15:16                       ` Suravee Suthikulanit
2014-04-29 19:14                       ` Borislav Petkov
2014-04-29 21:40                         ` Myron Stowe
2014-04-30  7:00                           ` Robert Richter
2014-04-30  7:50                             ` Suravee Suthikulpanit
2014-04-30  7:50                               ` Suravee Suthikulpanit
2014-04-30  9:51                               ` Robert Richter
2014-04-30 23:03                             ` Myron Stowe
2014-04-29 11:19                   ` Robert Richter
2014-04-29  7:06               ` Jan Beulich
2014-04-29  7:06                 ` Jan Beulich
2014-04-29  3:04           ` Suravee Suthikulanit
2014-04-29  3:04             ` Suravee Suthikulanit
2014-04-28 21:19       ` Myron Stowe
2014-04-29  2:47         ` Suravee Suthikulanit
2014-04-29  2:47           ` Suravee Suthikulanit
2014-04-29 17:17     ` Robert Richter
2014-04-30  6:41     ` Robert Richter
2014-04-19  2:53   ` [PATCH v2 3/5] x86/PCI: Miscellaneous code clean up for early_fillup_mp_bus_info Myron Stowe
2014-04-20  8:02     ` Borislav Petkov
2014-04-28 21:21       ` Myron Stowe
2014-04-19  2:53   ` [PATCH v2 4/5] ACPI/PCI: Warn if we have to "guess" host bridge node information Myron Stowe
2014-04-20 10:21     ` Borislav Petkov
2014-04-28 21:24       ` Myron Stowe
2014-04-29 19:16         ` Borislav Petkov
2014-04-19  2:53   ` [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node' Myron Stowe
2014-04-20 10:54     ` Borislav Petkov
2014-04-20 13:44       ` Myron Stowe
2014-04-21 16:53         ` Daniel J Blueman
2014-04-29  2:02           ` Suravee Suthikulanit
2014-04-29  2:02             ` Suravee Suthikulanit
2014-04-29 19:29             ` Bjorn Helgaas
2014-04-28 21:28       ` Myron Stowe

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=53226433.3090803@amd.com \
    --to=suravee.suthikulpanit@amd.com \
    --cc=aravind.gopalakrishnan@amd.com \
    --cc=bhelgaas@google.com \
    --cc=kim.naru@amd.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=yinghai@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.