In lapic_resume, ensure x2apic is actually disabled when the kernel expects it
to be disabled, i.e. when x2apic_mode = 0.
x2apic_mode is set to 0 and x2apic is disabled on boot if the kernel doesn't
support irq remapping or for other reasons. On resume from s2ram
(/sys/power/mem_sleep = deep), firmware can re-enable x2apic, but the kernel
continues using the xapic interface because it didn't check to see if someone
enabled x2apic behind its back, which causes hangs. This situation happens on
defconfig + bare metal + s2ram, on which this fix has been tested.
Fixes: 6e1cb38a2aef ("x64, x2apic/intr-remap: add x2apic support, including enabling interrupt-remapping")
Cc: stable@vger.kernel.org
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
---
arch/x86/kernel/apic/apic.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index d93f87f29d03..cc64d61f82cf 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2456,6 +2456,12 @@ static void lapic_resume(void *data)
if (x2apic_mode) {
__x2apic_enable();
} else {
+ /*
+ * x2apic may have been re-enabled by the
+ * firmware on resuming from s2ram
+ */
+ __x2apic_disable();
+
/*
* Make sure the APICBASE points to the right address
*
--
2.43.0> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index d93f87f29d03..cc64d61f82cf 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2456,6 +2456,12 @@ static void lapic_resume(void *data)
> if (x2apic_mode) {
> __x2apic_enable();
> } else {
> + /*
> + * x2apic may have been re-enabled by the
> + * firmware on resuming from s2ram
> + */
> + __x2apic_disable();
> +
We should likely only disable x2apic on platforms that support it and
need the disabling. How about?
...
} else {
/*
*
*/
if (x2apic_enabled())
__x2apic_disable();
I considered if an error message should be printed along with this. But,
I am not sure if it can really be called a firmware issue. It's probably
just that newer CPUs might have started defaulting to x2apic on.
Can you specify what platform you are encountering this?
Hi Sohil,
On Tue, Feb 03, 2026 at 01:08:39PM -0800, Sohil Mehta wrote:
> > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> > index d93f87f29d03..cc64d61f82cf 100644
> > --- a/arch/x86/kernel/apic/apic.c
> > +++ b/arch/x86/kernel/apic/apic.c
> > @@ -2456,6 +2456,12 @@ static void lapic_resume(void *data)
> > if (x2apic_mode) {
> > __x2apic_enable();
> > } else {
> > + /*
> > + * x2apic may have been re-enabled by the
> > + * firmware on resuming from s2ram
> > + */
> > + __x2apic_disable();
> > +
>
> We should likely only disable x2apic on platforms that support it and
> need the disabling. How about?
>
> ...
> } else {
> /*
> *
> */
> if (x2apic_enabled())
> __x2apic_disable();
__x2apic_disable disables x2apic only if boot_cpu_has(X86_FEATURE_APIC)
and x2apic is already enabled. x2apic_enabled also does the same checks,
the only difference being, it uses rdmsrq_safe instead of just rdmsrq,
which is what __x2apic_disable uses. The safe version is because of
Boris' suggestion [1]. If that's applicable here as well, then rdmsrq in
__x2apic_disable should be changed to rdmsrq_safe.
> I considered if an error message should be printed along with this. But,
> I am not sure if it can really be called a firmware issue. It's probably
> just that newer CPUs might have started defaulting to x2apic on.
>
> Can you specify what platform you are encountering this?
I'm not sure it's the CPU defaulting to x2apic on. As per Section
12.12.5.1 of the Intel SDM:
On coming out of reset, the local APIC unit is enabled and is in
the xAPIC mode: IA32_APIC_BASE[EN]=1 and IA32_APIC_BASE[EXTD]=0.
So, the CPU should be turning on in xapic mode. In fact, when x2apic is
disabled in the firmware, this problem doesn't happen.
Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the
firmware during resume. Disabling\n"?
[1] https://lore.kernel.org/all/20150116095927.GA18880@pd.tnic/
On 2/4/2026 1:17 AM, Shashank Balaji wrote: > __x2apic_disable disables x2apic only if boot_cpu_has(X86_FEATURE_APIC) > and x2apic is already enabled. I meant the X86_FEATURE_X2APIC and not X86_FEATURE_APIC. But, thinking about it more, checking that the CPU is really in X2APIC mode by reading the MSR is good enough. > x2apic_enabled also does the same checks, > the only difference being, it uses rdmsrq_safe instead of just rdmsrq, > which is what __x2apic_disable uses. The safe version is because of > Boris' suggestion [1]. If that's applicable here as well, then rdmsrq in > __x2apic_disable should be changed to rdmsrq_safe. I don't know if there is a strong justification for changing to rdmsrq_safe() over here. Also, that would be beyond the scope of this patch. In general, it's better to avoid such changes unless an actual issue pops up. > >> I considered if an error message should be printed along with this. But, >> I am not sure if it can really be called a firmware issue. It's probably >> just that newer CPUs might have started defaulting to x2apic on. >> >> Can you specify what platform you are encountering this? > > > I'm not sure it's the CPU defaulting to x2apic on. As per Section > 12.12.5.1 of the Intel SDM: > > On coming out of reset, the local APIC unit is enabled and is in > the xAPIC mode: IA32_APIC_BASE[EN]=1 and IA32_APIC_BASE[EXTD]=0. > > So, the CPU should be turning on in xapic mode. In fact, when x2apic is > disabled in the firmware, this problem doesn't happen. > It's a bit odd then that the firmware chooses to enable x2apic without the OS requesting it. Linux maintains a concept of X2APIC_ON_LOCKED in x2apic_state which is based on the hardware preference to keep the apic in X2APIC mode. When you have x2apic enabled in firmware, but the system is in XAPIC mode, can you read the values in MSR_IA32_ARCH_CAPABILITIES and MSR_IA32_XAPIC_DISABLE_STATUS? XAPIC shouldn't be disabled because you are running in that mode. But, it would be good to confirm. > Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the > firmware during resume. Disabling\n"? I mainly want to make sure the firmware is really at fault before we add such a print. But it seems likely now that the firmware messed up.
On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote: > On 2/4/2026 1:17 AM, Shashank Balaji wrote: > > > __x2apic_disable disables x2apic only if boot_cpu_has(X86_FEATURE_APIC) > > and x2apic is already enabled. > > I meant the X86_FEATURE_X2APIC and not X86_FEATURE_APIC. My bad, I got that wrong. __x2apic_disable checks for X86_FEATURE_APIC, while x2apic_enabled checks for X86_FEATURE_X2APIC. > But, thinking about it more, checking that the CPU is really in X2APIC mode > by reading the MSR is good enough. But yes, I agree. > > x2apic_enabled also does the same checks, > > the only difference being, it uses rdmsrq_safe instead of just rdmsrq, > > which is what __x2apic_disable uses. The safe version is because of > > Boris' suggestion [1]. If that's applicable here as well, then rdmsrq in > > __x2apic_disable should be changed to rdmsrq_safe. > > I don't know if there is a strong justification for changing to > rdmsrq_safe() over here. Also, that would be beyond the scope of this > patch. In general, it's better to avoid such changes unless an actual > issue pops up. Makes sense. > >> I considered if an error message should be printed along with this. But, > >> I am not sure if it can really be called a firmware issue. It's probably > >> just that newer CPUs might have started defaulting to x2apic on. > >> > >> Can you specify what platform you are encountering this? > > > > > > I'm not sure it's the CPU defaulting to x2apic on. As per Section > > 12.12.5.1 of the Intel SDM: > > > > On coming out of reset, the local APIC unit is enabled and is in > > the xAPIC mode: IA32_APIC_BASE[EN]=1 and IA32_APIC_BASE[EXTD]=0. > > > > So, the CPU should be turning on in xapic mode. In fact, when x2apic is > > disabled in the firmware, this problem doesn't happen. > > > > It's a bit odd then that the firmware chooses to enable x2apic without > the OS requesting it. Well, the firmware has a setting saying "Enable x2apic", which was enabled. So it did what the setting says > Linux maintains a concept of X2APIC_ON_LOCKED in x2apic_state which is > based on the hardware preference to keep the apic in X2APIC mode. > > When you have x2apic enabled in firmware, but the system is in XAPIC > mode, can you read the values in MSR_IA32_ARCH_CAPABILITIES and > MSR_IA32_XAPIC_DISABLE_STATUS? > > XAPIC shouldn't be disabled because you are running in that mode. But, > it would be good to confirm. With x2apic enabled by the firmware, and after kernel switches to xapic (because no interrupt remapping support), bit 21 (XAPIC_DISABLE_STATUS) of MSR_IA32_ARCH_CAPABILITIES is 0, and MSR_IA32_XAPIC_DISABLE_STATUS MSR is not available. > > Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the > > firmware during resume. Disabling\n"? > > I mainly want to make sure the firmware is really at fault before we add > such a print. But it seems likely now that the firmware messed up.
On 2/4/2026 10:07 PM, Shashank Balaji wrote:
> On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote:
>> It's a bit odd then that the firmware chooses to enable x2apic without
>> the OS requesting it.
>
> Well, the firmware has a setting saying "Enable x2apic", which was
> enabled. So it did what the setting says
>
The expectation would be that firmware would restore to the same state
before lapic_suspend().
>
>>> Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the
>>> firmware during resume. Disabling\n"?
>>
>> I mainly want to make sure the firmware is really at fault before we add
>> such a print. But it seems likely now that the firmware messed up.
Maybe a warning would be useful to encourage firmware to fix this going
forward. I don't have a strong preference on the wording, but how about?
pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
resume.\n");
A few nits:
For the code comments, you can use more of the line width. Generally, 72
(perhaps even 80) chars is okay for comments dependent on the code in
the vicinity.
The tip tree has slightly unique preferences, such as capitalizing the
first word of the patch title.
Please refer:
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-submission-notes
On Thu, Feb 05, 2026 at 03:18:58PM -0800, Sohil Mehta wrote:
> On 2/4/2026 10:07 PM, Shashank Balaji wrote:
> > On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote:
>
> >> It's a bit odd then that the firmware chooses to enable x2apic without
> >> the OS requesting it.
> >
> > Well, the firmware has a setting saying "Enable x2apic", which was
> > enabled. So it did what the setting says
> >
>
> The expectation would be that firmware would restore to the same state
> before lapic_suspend().
I'm a bit out of my depth here, but I went looking around, and this is from the
latest ACPI spec (v6.6) [1]:
When executing from the power-on reset vector as a result of waking
from an S2 or S3 sleep state, the platform firmware performs only the
hardware initialization required to restore the system to either the
state the platform was in prior to the initial operating system boot,
or to the pre-sleep configuration state. In multiprocessor systems,
non-boot processors should be placed in the same state as prior to the
initial operating system boot.
(further ahead)
If this is an S2 or S3 wake, then the platform runtime firmware
restores minimum context of the system before jumping to the waking
vector. This includes:
CPU configuration. Platform runtime firmware restores the
pre-sleep configuration or initial boot configuration of each
CPU (MSR, MTRR, firmware update, SMBase, and so on). Interrupts
must be disabled (for IA-32 processors, disabled by CLI
instruction).
(and other things)
I suppose, in my case, the firmware is restoring initial boot
configuration on S3 resume. And initial boot configuration of x2apic is
set from the firmware's UI "Enable x2apic".
> Maybe a warning would be useful to encourage firmware to fix this going
> forward. I don't have a strong preference on the wording, but how about?
>
> pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
> resume.\n");
At least as per the spec, it's not something the firmware needs to fix,
and it's not unexpected re-enablement.
Am I missing something?
But it _is_ surprising that this bug went unnoticed for so long :)
[1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization
On 2/6/2026 12:57 AM, Shashank Balaji wrote:
> On Thu, Feb 05, 2026 at 03:18:58PM -0800, Sohil Mehta wrote:
>> On 2/4/2026 10:07 PM, Shashank Balaji wrote:
>>> On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote:
>>
>>>> It's a bit odd then that the firmware chooses to enable x2apic without
>>>> the OS requesting it.
>>>
>>> Well, the firmware has a setting saying "Enable x2apic", which was
>>> enabled. So it did what the setting says
>>>
>>
I still think the firmware behavior is flawed. Some confusion
originates from the option "Enable x2apic". Based on just these two
words, the behavior seems highly ambiguous. I interpret it to mean "Make
the x2apic feature available to the kernel". Then it is up to the kernel
whether it decides to use it.
If the intention of the BIOS option is to automatically/always enable
x2apic then there is an architectural way to do it. It can set the bits
that track to x2apic_hw_locked(). But, doing it this way during resume
(behind OS's back) is unexpected.
>>
>> pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
>> resume.\n");
>
> At least as per the spec, it's not something the firmware needs to fix,
> and it's not unexpected re-enablement.
>
> Am I missing something?
>
> But it _is_ surprising that this bug went unnoticed for so long :)
Maybe this BIOS option isn't typically found in a production firmware. I
think it would be preferable to have the pr_warn_once() but I won't push
super hard for it due to the unclear information.
Whatever you choose for v2, can you please briefly describe the
ambiguity in the commit message? It would help other reviewers provide
better insight and be handy if we ever need to come back to this.
On Thu, Feb 05, 2026 at 03:18:58PM -0800, Sohil Mehta wrote:
> Maybe a warning would be useful to encourage firmware to fix this going
> forward. I don't have a strong preference on the wording, but how about?
>
> pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
> resume.\n");
That works
> A few nits:
>
> For the code comments, you can use more of the line width. Generally, 72
> (perhaps even 80) chars is okay for comments dependent on the code in
> the vicinity.
>
> The tip tree has slightly unique preferences, such as capitalizing the
> first word of the patch title.
>
> Please refer:
> https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-submission-notes
Thanks! I noticed that I also didn't use '()' for function names in the
commit message. I'll fix all these and add the pr_warn_once in v2.
Hi Shashank,
kernel test robot noticed the following build errors:
[auto build test ERROR on 18f7fcd5e69a04df57b563360b88be72471d6b62]
url: https://github.com/intel-lab-lkp/linux/commits/Shashank-Balaji/x86-x2apic-disable-x2apic-on-resume-if-the-kernel-expects-so/20260202-181147
base: 18f7fcd5e69a04df57b563360b88be72471d6b62
patch link: https://lore.kernel.org/r/20260202-x2apic-fix-v1-1-71c8f488a88b%40sony.com
patch subject: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
config: i386-randconfig-001-20260202 (https://download.01.org/0day-ci/archive/20260203/202602030600.jFhsJyEC-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260203/202602030600.jFhsJyEC-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602030600.jFhsJyEC-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/x86/kernel/apic/apic.c:2463:3: error: call to undeclared function '__x2apic_disable'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
2463 | __x2apic_disable();
| ^
arch/x86/kernel/apic/apic.c:2463:3: note: did you mean '__x2apic_enable'?
arch/x86/kernel/apic/apic.c:1896:20: note: '__x2apic_enable' declared here
1896 | static inline void __x2apic_enable(void) { }
| ^
1 error generated.
vim +/__x2apic_disable +2463 arch/x86/kernel/apic/apic.c
2435
2436 static void lapic_resume(void *data)
2437 {
2438 unsigned int l, h;
2439 unsigned long flags;
2440 int maxlvt;
2441
2442 if (!apic_pm_state.active)
2443 return;
2444
2445 local_irq_save(flags);
2446
2447 /*
2448 * IO-APIC and PIC have their own resume routines.
2449 * We just mask them here to make sure the interrupt
2450 * subsystem is completely quiet while we enable x2apic
2451 * and interrupt-remapping.
2452 */
2453 mask_ioapic_entries();
2454 legacy_pic->mask_all();
2455
2456 if (x2apic_mode) {
2457 __x2apic_enable();
2458 } else {
2459 /*
2460 * x2apic may have been re-enabled by the
2461 * firmware on resuming from s2ram
2462 */
> 2463 __x2apic_disable();
2464
2465 /*
2466 * Make sure the APICBASE points to the right address
2467 *
2468 * FIXME! This will be wrong if we ever support suspend on
2469 * SMP! We'll need to do this as part of the CPU restore!
2470 */
2471 if (boot_cpu_data.x86 >= 6) {
2472 rdmsr(MSR_IA32_APICBASE, l, h);
2473 l &= ~MSR_IA32_APICBASE_BASE;
2474 l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr;
2475 wrmsr(MSR_IA32_APICBASE, l, h);
2476 }
2477 }
2478
2479 maxlvt = lapic_get_maxlvt();
2480 apic_write(APIC_LVTERR, ERROR_APIC_VECTOR | APIC_LVT_MASKED);
2481 apic_write(APIC_ID, apic_pm_state.apic_id);
2482 apic_write(APIC_DFR, apic_pm_state.apic_dfr);
2483 apic_write(APIC_LDR, apic_pm_state.apic_ldr);
2484 apic_write(APIC_TASKPRI, apic_pm_state.apic_taskpri);
2485 apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
2486 apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
2487 apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
2488 #ifdef CONFIG_X86_THERMAL_VECTOR
2489 if (maxlvt >= 5)
2490 apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
2491 #endif
2492 #ifdef CONFIG_X86_MCE_INTEL
2493 if (maxlvt >= 6)
2494 apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci);
2495 #endif
2496 if (maxlvt >= 4)
2497 apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
2498 apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
2499 apic_write(APIC_TDCR, apic_pm_state.apic_tdcr);
2500 apic_write(APIC_TMICT, apic_pm_state.apic_tmict);
2501 apic_write(APIC_ESR, 0);
2502 apic_read(APIC_ESR);
2503 apic_write(APIC_LVTERR, apic_pm_state.apic_lvterr);
2504 apic_write(APIC_ESR, 0);
2505 apic_read(APIC_ESR);
2506
2507 irq_remapping_reenable(x2apic_mode);
2508
2509 local_irq_restore(flags);
2510 }
2511
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Tue, Feb 03, 2026 at 06:31:40AM +0800, kernel test robot wrote:
> Hi Shashank,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on 18f7fcd5e69a04df57b563360b88be72471d6b62]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Shashank-Balaji/x86-x2apic-disable-x2apic-on-resume-if-the-kernel-expects-so/20260202-181147
> base: 18f7fcd5e69a04df57b563360b88be72471d6b62
> patch link: https://lore.kernel.org/r/20260202-x2apic-fix-v1-1-71c8f488a88b%40sony.com
> patch subject: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
> config: i386-randconfig-001-20260202 (https://download.01.org/0day-ci/archive/20260203/202602030600.jFhsJyEC-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260203/202602030600.jFhsJyEC-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202602030600.jFhsJyEC-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> >> arch/x86/kernel/apic/apic.c:2463:3: error: call to undeclared function '__x2apic_disable'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 2463 | __x2apic_disable();
> | ^
> arch/x86/kernel/apic/apic.c:2463:3: note: did you mean '__x2apic_enable'?
> arch/x86/kernel/apic/apic.c:1896:20: note: '__x2apic_enable' declared here
> 1896 | static inline void __x2apic_enable(void) { }
> | ^
> 1 error generated.
This happens when CONFIG_X86_X2APIC is disabled. This patch fixes it,
which I'll include in v2:
diff --git i/arch/x86/kernel/apic/apic.c w/arch/x86/kernel/apic/apic.c
index 8820b631f8a2..06cce23b89c1 100644
--- i/arch/x86/kernel/apic/apic.c
+++ w/arch/x86/kernel/apic/apic.c
@@ -1894,6 +1894,7 @@ void __init check_x2apic(void)
static inline void try_to_enable_x2apic(int remap_mode) { }
static inline void __x2apic_enable(void) { }
+static inline void __x2apic_disable(void) {}
#endif /* !CONFIG_X86_X2APIC */
void __init enable_IR_x2apic(void)
Hi Shashank,
kernel test robot noticed the following build errors:
[auto build test ERROR on 18f7fcd5e69a04df57b563360b88be72471d6b62]
url: https://github.com/intel-lab-lkp/linux/commits/Shashank-Balaji/x86-x2apic-disable-x2apic-on-resume-if-the-kernel-expects-so/20260202-181147
base: 18f7fcd5e69a04df57b563360b88be72471d6b62
patch link: https://lore.kernel.org/r/20260202-x2apic-fix-v1-1-71c8f488a88b%40sony.com
patch subject: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
config: x86_64-buildonly-randconfig-001-20260202 (https://download.01.org/0day-ci/archive/20260202/202602022242.iSdFHMDI-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260202/202602022242.iSdFHMDI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602022242.iSdFHMDI-lkp@intel.com/
All errors (new ones prefixed by >>):
arch/x86/kernel/apic/apic.c: In function 'lapic_resume':
>> arch/x86/kernel/apic/apic.c:2463:17: error: implicit declaration of function '__x2apic_disable'; did you mean '__x2apic_enable'? [-Wimplicit-function-declaration]
2463 | __x2apic_disable();
| ^~~~~~~~~~~~~~~~
| __x2apic_enable
vim +2463 arch/x86/kernel/apic/apic.c
2435
2436 static void lapic_resume(void *data)
2437 {
2438 unsigned int l, h;
2439 unsigned long flags;
2440 int maxlvt;
2441
2442 if (!apic_pm_state.active)
2443 return;
2444
2445 local_irq_save(flags);
2446
2447 /*
2448 * IO-APIC and PIC have their own resume routines.
2449 * We just mask them here to make sure the interrupt
2450 * subsystem is completely quiet while we enable x2apic
2451 * and interrupt-remapping.
2452 */
2453 mask_ioapic_entries();
2454 legacy_pic->mask_all();
2455
2456 if (x2apic_mode) {
2457 __x2apic_enable();
2458 } else {
2459 /*
2460 * x2apic may have been re-enabled by the
2461 * firmware on resuming from s2ram
2462 */
> 2463 __x2apic_disable();
2464
2465 /*
2466 * Make sure the APICBASE points to the right address
2467 *
2468 * FIXME! This will be wrong if we ever support suspend on
2469 * SMP! We'll need to do this as part of the CPU restore!
2470 */
2471 if (boot_cpu_data.x86 >= 6) {
2472 rdmsr(MSR_IA32_APICBASE, l, h);
2473 l &= ~MSR_IA32_APICBASE_BASE;
2474 l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr;
2475 wrmsr(MSR_IA32_APICBASE, l, h);
2476 }
2477 }
2478
2479 maxlvt = lapic_get_maxlvt();
2480 apic_write(APIC_LVTERR, ERROR_APIC_VECTOR | APIC_LVT_MASKED);
2481 apic_write(APIC_ID, apic_pm_state.apic_id);
2482 apic_write(APIC_DFR, apic_pm_state.apic_dfr);
2483 apic_write(APIC_LDR, apic_pm_state.apic_ldr);
2484 apic_write(APIC_TASKPRI, apic_pm_state.apic_taskpri);
2485 apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
2486 apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
2487 apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
2488 #ifdef CONFIG_X86_THERMAL_VECTOR
2489 if (maxlvt >= 5)
2490 apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
2491 #endif
2492 #ifdef CONFIG_X86_MCE_INTEL
2493 if (maxlvt >= 6)
2494 apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci);
2495 #endif
2496 if (maxlvt >= 4)
2497 apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
2498 apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
2499 apic_write(APIC_TDCR, apic_pm_state.apic_tdcr);
2500 apic_write(APIC_TMICT, apic_pm_state.apic_tmict);
2501 apic_write(APIC_ESR, 0);
2502 apic_read(APIC_ESR);
2503 apic_write(APIC_LVTERR, apic_pm_state.apic_lvterr);
2504 apic_write(APIC_ESR, 0);
2505 apic_read(APIC_ESR);
2506
2507 irq_remapping_reenable(x2apic_mode);
2508
2509 local_irq_restore(flags);
2510 }
2511
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
© 2016 - 2026 Red Hat, Inc.