On 3/5/2014 8:13 PM, Suravee Suthikulanit wrote:
On 3/5/2014 3:24 PM, Bjorn Helgaas wrote:
[+cc linux-acpi]
On Wed, Mar 5, 2014 at 2:06 PM, <suravee.suthikulpanit@xxxxxxx> wrote:
From: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
The current code only supports upto AMD hostbridge for family11h.
This causes PCI numa_node information to be reported incorrectly
for newer family with multi sockets.
Where is the incorrect reporting? In ACPI tables? Is this patch a
way to cover up firmware defects in the ACPI description? Or is this
for machines without ACPI (it seems unlikely that machines with new
AMD processors would not have ACPI)?
This is incorrectly reported in the sysfs for each PCI device (e.g.
/devices/pci0000:50/0000:50:00.2/numa_node). Without the patch, they
return -1.
In file arch/x86/pci/acpi.c, in function pci_acpi_scan_root(), it is
queries the node information as following:
#ifdef CONFIG_ACPI_NUMA
pxm = acpi_get_pxm(device->handle);
if (pxm >= 0)
node = pxm_to_node(pxm);
if (node != -1)
set_mp_bus_to_node(busnum, node);
else
#endif
node = get_mp_bus_to_node(busnum);
In this case, I see that the acpi_get_pxm() returns -1. Therefore, it
falls back to using the node information in mp_bus_to_node[]. So,
without this patch, it would also returning -1.
Also, the spec mentioned that the _PXM is optional, so I am not sure if
this is a firmware bug.
Suravee
I am not quite familiar with the ACPI for this part. However, after
taking a look at the code (in driver/acpi/pci_root.c:
acpi_pci_root_add()), I believe it's trying to locate _PXM method in the
DSDT table, in which I don't see any _PXM methods.
I'm still trying to debug this issue, any suggestions would be appreciated.
Thank you,
Suravee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
