lkml.org 
[lkml]   [2014]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems
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




\
 
 \ /
  Last update: 2014-03-14 04:01    [W:0.100 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site