The addition of support to read the numa node for a PCI
card specified by _PXM resulted in Martin's system not
booting. Looking at the ACPI tables it seems that there
are PXM entries for the root ports, but no SRAT table.
The absence of SRAT table results in dummy_numa_init being
called. However, unlike on arm64, this doesn't then result
in numa_off being set. When the PCI code later comes along
and calls acpi_get_node for any PCI card below the root port,
it navigates up the ACPI tree until it finds the PXM value in
the root port. This value is then passed to
acpi_map_pxm_to_node. If numa_off is set this returns,
NUMA_NO_NODE (as it does on arm64), on x86 it instead tries
to allocate a numa node from the unused set without setting
up all the infrastructure that would normally accompany such
a call. We have not identified exactly which driver is
causing the subsequent hang for Martin.
It is invalid under the ACPI spec to specify new
numa nodes using PXM if they have no presence in SRAT.
Thus the simplest fix is to set numa_off when it is off due
to an invalid SRAT (here not present at all).
I do not have easy access to appropriate x86 numa systems so
would appreciate some testing of this one!
Known problem boards setups:
AMD Ryzen Threadripper 2950X on ASROCK X399 TAICHI
MSI X399 SLI PLUS (probably - not confirmed yet)
The PCI patch has been reverted, so this fix is not critical.
Reported-by: Martin Hundeb�martin@xxxxxxxxxx>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
Fixes: bad7dcd94f39 ("ACPI/PCI: Pay attention to device-specific _PXM node values")
---
arch/x86/mm/numa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 1308f5408bf7..ce1182f953ff 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -695,6 +695,8 @@ static int __init dummy_numa_init(void)
node_set(0, numa_nodes_parsed);
numa_add_memblk(0, 0, PFN_PHYS(max_pfn));
+ numa_off = true;
+
return 0;
}
--
2.18.0
