I assume the system is fully functional even without these patches,
>right? The only effect of these changes should be a performance
>improvement.
>
>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.
>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.
>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.
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.
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.