[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c1d7e60329a62a9f6d70ffa664632db8db668efe.camel@intel.com>
Date: Wed, 13 Dec 2023 07:39:00 +0000
From: "Zhang, Rui" <rui.zhang@...el.com>
To: "tglx@...utronix.de" <tglx@...utronix.de>,
"jsperbeck@...gle.com" <jsperbeck@...gle.com>,
"tip-bot2@...utronix.de" <tip-bot2@...utronix.de>
CC: "andres@...razel.de" <andres@...razel.de>,
"peterz@...radead.org" <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [tip: x86/urgent] x86/acpi: Ignore invalid x2APIC entries
>
> The simple change below should do the trick.
>
Yeah, I agree.
I have posted a patch to do more strict check
https://lore.kernel.org/all/20231210143925.38722-1-rui.zhang@intel.com/
in case there are some weird cases that LAPIC fails to probe any
enabled CPU and we also lose the X2APIC cpus.
Either of the patches should fix these two regressions reported.
thanks,
rui
> Thanks,
>
> tglx
> ---
> diff --git a/arch/x86/kernel/acpi/boot.c
> b/arch/x86/kernel/acpi/boot.c
> index 1a0dd80d81ac..85a3ce2a3666 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -293,6 +293,7 @@ acpi_parse_lapic(union acpi_subtable_headers *
> header, const unsigned long end)
> processor->processor_id, /* ACPI ID */
> processor->lapic_flags &
> ACPI_MADT_ENABLED);
>
> + has_lapic_cpus = true;
> return 0;
> }
>
> @@ -1134,7 +1135,6 @@ static int __init
> acpi_parse_madt_lapic_entries(void)
> if (!count) {
> count =
> acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC,
> acpi_parse_lapic,
> MAX_LOCAL_APIC);
> - has_lapic_cpus = count > 0;
> x2count =
> acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC,
> acpi_parse_x2apic,
> MAX_LOCAL_APIC);
> }
>
>
Powered by blists - more mailing lists