Created attachment 280833 [details] dmesg Jonathan Cameron <Jonathan.Cameron@huawei.com> noticed that we use the NUMA proximity domain of PCI host bridges, but we assume all devices below the host bridge are in the same proximity domain, ignoring any _PXM methods they may have. He posted a patch (https://lore.kernel.org/linux-pci/20180912152140.3676-2-Jonathan.Cameron@huawei.com) to fix this, but Martin Hundebøll <martin@geanix.com> reported that it caused a regression. Martin's report had several attachments, so it was rejected by the mailing list. I'll attach them here (from Message-ID e4bd3423-ae2a-262c-1391-f9741ac4fdd0@geanix.com).
Created attachment 280835 [details] DSDT.dsl Martin's disassembly of DSDT from Message-ID 8a0fd569-fa52-b884-ef0d-18aab1ef8c3f@geanix.com using iasl -e SSDT1.asl SSDT2.asl SSDT3.asl SSDT4.asl SSDT5.asl SSDT6.asl SSDT7.asl -d DSDT.asl
Ingo Molnar <mingo@kernel.org> also reported the regression at https://lore.kernel.org/linux-pci/20181113071712.GA2353@gmail.com on an AMD ThreadRipper system (MSI X399 SLI PLUS (MS-7B09)). Thomas Lendacky <Thomas.Lendacky@amd.com> reproduced a similar problem by instrumenting a kernel to skip the SRAT, which resulted in a General Protection Fault (https://lore.kernel.org/linux-pci/f27cb1b2-d468-8a07-49f8-475cf0842592@amd.com).