Created attachment 23475 [details] dmesg The machine is a Dell Precision T7500 with 2 Nehalem CPUs. In the BIOS, memory interleaving is set to "NUMA". It was the only BIOS option mentioning NUMA. So I would expect that the kernel detects and uses NUMA. Problem is still there with latest BIOS update (A03). Dell technical support did not want to accept an error report on this.
Created attachment 23476 [details] lspci
I have the same problem on Dell Precision T5500. I discovered that the kernel option acpi=rsdt allows the SRAT table to be parsed successfully.
Created attachment 23599 [details] acpidump of Dell Precision T5500 This is the ACPI table from my Dell Precision T5500 with BIOS A03. I examined the RSDT and XSDT tables, and found that it is indeed missing a pointer to the SRAT table. The RSDT table includes the SRAT, but also points to an older version of the FACP table with less information. Obviously, this is a problem with the BIOS. I don't know if the extra FACP data is actually useful, but it seems possible that there may be situations where it may be worth getting data from both RSDT and XSDT. Depending on how common it is for ACPI tables to be broken, maybe the kernel acpi flags could be expanded to exclude and/or include specific tables. For example, the folloing options could say to use the XSDT table, but also take the SRAT from the RSDT: acpi=xsdt,+rsdt.srat
I confirm the symptoms described in the above comments using a Dell Precision T5500n using RHEL5.3, as pre-installed by Dell, and using RedHat's updated kernel, as provided by the RedHat Network using the subscription included in the package purchased from Dell. BIOS= A03 kernel = 2.6.18-164.9.1.el5
Dell told me this will be fixed in next Bios for T7500 which is supposed to be A04 and due end of march. Also note: this bug seems to affect only machines which do not contain valid ACPI SLIC entry (you get valid SLIC if you purchase the machine with Windows OEM preactivation)