Bug 14447
| Summary: | Dell Precision T7500 BIOS (A01, A03) does not provide correct NUMA information | ||
|---|---|---|---|
| Product: | Memory Management | Reporter: | Jens-Michael Hoffmann (jensmh) |
| Component: | NUMA/discontigmem | Assignee: | mm_numa-discontigmem |
| Status: | CLOSED OBSOLETE | ||
| Severity: | normal | CC: | alan, gunther.mayer, krahn, linux-bugs, Matt_Domsch, rezwanul_kabir, TimothyJGiese |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Debian 2.6.30-2, Debian 2.6.31 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg
lspci acpidump of Dell Precision T5500 |
||
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) |
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.