Re: [PATCH 0/1] sched/topology: NUMA distance deduplication
Helo Valentin!
On 3/17/21 8:36 PM, Valentin Schneider wrote:
> I see ACPI in your boot logs, so I'm guessing you have a bogus SLIT table
> (the ACPI table with node distances). You should be able to double check
> this with something like:
>
> $ acpidump > acpi.dump
> $ acpixtract -a acpi.dump
> $ iasl -d *.dat
> $ cat slit.dsl
There does not seem to be a SLIT table in my firmware:
root@glendronach:~# acpidump > acpi.dump
root@glendronach:~# acpixtract -a acpi.dump
Intel ACPI Component Architecture
ACPI Binary Table Extraction Utility version 20200925
Copyright (c) 2000 - 2020 Intel Corporation
acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e91
SSDT - 3768 bytes written (0x00000EB8) - ssdt1.dat
acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e00
acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e91
SPCR - 80 bytes written (0x00000050) - spcr.dat
acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e00
acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e91
APIC - 200 bytes written (0x000000C8) - apic.dat
SSDT - 1110 bytes written (0x00000456) - ssdt2.dat
SSDT - 316 bytes written (0x0000013C) - ssdt3.dat
SPMI - 80 bytes written (0x00000050) - spmi.dat
DSDT - 58726 bytes written (0x0000E566) - dsdt.dat
SSDT - 312 bytes written (0x00000138) - ssdt4.dat
SSDT - 2150 bytes written (0x00000866) - ssdt5.dat
SSDT - 316 bytes written (0x0000013C) - ssdt6.dat
SSDT - 3768 bytes written (0x00000EB8) - ssdt7.dat
FACP - 244 bytes written (0x000000F4) - facp.dat
SSDT - 1203 bytes written (0x000004B3) - ssdt8.dat
CPEP - 52 bytes written (0x00000034) - cpep.dat
SSDT - 316 bytes written (0x0000013C) - ssdt9.dat
DBGP - 52 bytes written (0x00000034) - dbgp.dat
SSDT - 3768 bytes written (0x00000EB8) - ssdt10.dat
FACS - 64 bytes written (0x00000040) - facs.dat
root@glendronach:~#
root@glendronach:~# ls *.dsl *.dat
apic.dat cpep.dsl dsdt.dat facp.dsl spcr.dat spmi.dsl ssdt1.dat ssdt2.dsl ssdt4.dat ssdt5.dsl ssdt7.dat ssdt8.dsl
apic.dsl dbgp.dat dsdt.dsl facs.dat spcr.dsl ssdt10.dat ssdt1.dsl ssdt3.dat ssdt4.dsl ssdt6.dat ssdt7.dsl ssdt9.dat
cpep.dat dbgp.dsl facp.dat facs.dsl spmi.dat ssdt10.dsl ssdt2.dat ssdt3.dsl ssdt5.dat ssdt6.dsl ssdt8.dat ssdt9.dsl
root@glendronach:~#
> a) Complain to your hardware vendor to have them fix the table and ship a
> firmware fix
The hardware is probably too old for the vendor to care about fixing it.
> b) Fix the ACPI table yourself - I've been told it's doable for *some* of
> them, but I've never done that myself
> c) Compile your kernel with CONFIG_NUMA=n, as AFAICT you only actually have
> a single node
> d) Ignore the warning
>
>
> c) is clearly not ideal if you want to use a somewhat generic kernel image
> on a wide host of machines; d) is also a bit yucky...
Shouldn't the kernel be able to cope with quirky hardware? From what I remember in the past,
ACPI tables used to be broken quite a lot and the kernel contained workarounds for such cases,
didn't it?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: