Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot

["Rafael J. Wysocki (Intel)" <rafael@xxxxxxxxxx>]

On Mon, Sep 21, 2026 at 6:44 PM Marek Marczykowski-Górecki
<marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Sep 21, 2026 at 05:26:55PM +0200, Rafael J. Wysocki (Intel) wrote:
> > On Sun, Sep 20, 2026 at 5:48 PM Support TRINITY <support@xxxxxxxxxxxxxxx> 
> > wrote:
> > >
> > > Hello,
> > >
> > > I am reporting a bare-metal Xen dom0 boot regression seen with Linux 
> > > 6.18.52.
> > >
> > > On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on bare 
> > > metal, while Linux 6.18.52 consistently black-screens before dom0 
> > > userspace/networking comes up.
> > >
> > > #regzbot introduced: v6.18.51..v6.18.52
> > > #regzbot title: ACPI processor/cpuidle lifecycle change breaks bare-metal 
> > > Xen dom0 boot
> > > #regzbot link: 
> > > https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447
> > >
> > > Tested results:
> > >
> > > Linux 6.18.51-r0, Xen dom0, bare metal: boots
> > > Linux 6.18.52-r0, Xen dom0, bare metal: black screen before 
> > > userspace/network
> >
> > I'm wondering what's special about Xen dom0 bare metal.
> >
> > Does adding processor=nocst to the kernel command line help, by any chance?
>
> It does not.
>
> > The patch is essentially a revert of commit 13ebeef6a1b9 ("ACPI:
> > processor: idle: Optimize ACPI idle driver registration") which I'd
> > rather not do without knowing what exactly is going on.
> >
> > At this point it looks like a missing check somewhere or similar, so
> > it would be good to find out where exactly it crashes.
>
> I can reproduce the crash, I get this:
>
> [    3.525669] BUG: kernel NULL pointer dereference, address: 0000000000000008
> [    3.525677] #PF: supervisor read access in kernel mode
> [    3.525681] #PF: error_code(0x0000) - not-present page
> [    3.525685] PGD 0 P4D 0
> [    3.525688] Oops: Oops: 0000 [#1] SMP NOPTI
> [    3.525693] CPU: 0 UID: 0 PID: 21 Comm: cpuhp/0 Not tainted 
> 6.18.52-1.qubes.23.fc41.x86_64 #1 PREEMPT(full)
> [    3.525700] Hardware name: Micro-Star International Co., Ltd. MS-7E06/PRO 
> Z790-P WIFI (MS-7E06), BIOS Dasharo (coreboot+UEFI) v0.9.1 01/17/2024
> [    3.525706] RIP: e030:cpuidle_register_device+0xd2/0x350
> [    3.525714] Code: 00 00 8b 55 04 49 89 c5 49 89 d4 81 fa ff 1f 00 00 0f 87 
> 68 02 00 00 48 8b 04 d5 c0 a0 19 82 48 83 3c 18 00 0f 85 ad 48 12 ff <49> 8b 
> 7d 08 48 89 14 24 e8 31 73 30 ff 84 c0 0f 84 72 01 00 00 41
> [    3.525723] RSP: e02b:ffffc90040133db8 EFLAGS: 00010246
> [    3.525727] RAX: ffff888235f5c000 RBX: ffffffff834d4d40 RCX: 
> 0000000000000000
> [    3.525732] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 
> ffff888101c39c00
> [    3.525736] RBP: ffff888101c39c00 R08: 4ec4ec4ec4ec4ec5 R09: 
> ffff888101c39c00
> [    3.525740] R10: ffffc90040133df8 R11: 0000000000000000 R12: 
> 0000000000000000
> [    3.525744] R13: 0000000000000000 R14: 0000000000000000 R15: 
> ffffffff834d4d40
> [    3.525752] FS:  0000000000000000(0000) GS:ffff888235f5c000(0000) 
> knlGS:0000000000000000
> [    3.525757] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    3.525761] CR2: 0000000000000008 CR3: 000000000242c000 CR4: 
> 0000000000050660
> [    3.525768] Call Trace:
> [    3.525771]  <TASK>
> [    3.525775]  acpi_processor_power_init+0xde/0x150
> [    3.525782]  ? __pfx_acpi_soft_cpu_online+0x10/0x10
> [    3.525787]  acpi_soft_cpu_online+0x123/0x170
> [    3.525792]  cpuhp_invoke_callback+0x134/0x470
> [    3.525797]  ? __pfx_smpboot_thread_fn+0x10/0x10
> [    3.525802]  cpuhp_thread_fun+0xa2/0x170
> [    3.525806]  smpboot_thread_fn+0xf3/0x220
> [    3.525810]  kthread+0xfc/0x240
> [    3.525814]  ? __pfx_kthread+0x10/0x10
> [    3.525818]  ? __pfx_kthread+0x10/0x10
> [    3.525822]  ret_from_fork+0x158/0x170
> [    3.525827]  ? __pfx_kthread+0x10/0x10
> [    3.525830]  ret_from_fork_asm+0x1a/0x30
> [    3.525835]  </TASK>
> [    3.525837] Modules linked in:
> [    3.525842] CR2: 0000000000000008
> [    3.525845] ---[ end trace 0000000000000000 ]---
> [    3.525849] RIP: e030:cpuidle_register_device+0xd2/0x350
> [    3.525854] Code: 00 00 8b 55 04 49 89 c5 49 89 d4 81 fa ff 1f 00 00 0f 87 
> 68 02 00 00 48 8b 04 d5 c0 a0 19 82 48 83 3c 18 00 0f 85 ad 48 12 ff <49> 8b 
> 7d 08 48 89 14 24 e8 31 73 30 ff 84 c0 0f 84 72 01 00 00 41
> [    3.525862] RSP: e02b:ffffc90040133db8 EFLAGS: 00010246
> [    3.525866] RAX: ffff888235f5c000 RBX: ffffffff834d4d40 RCX: 
> 0000000000000000
> [    3.525870] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 
> ffff888101c39c00
> [    3.525874] RBP: ffff888101c39c00 R08: 4ec4ec4ec4ec4ec5 R09: 
> ffff888101c39c00
> [    3.525878] R10: ffffc90040133df8 R11: 0000000000000000 R12: 
> 0000000000000000
> [    3.525882] R13: 0000000000000000 R14: 0000000000000000 R15: 
> ffffffff834d4d40
> [    3.525889] FS:  0000000000000000(0000) GS:ffff888235f5c000(0000) 
> knlGS:0000000000000000
> [    3.525894] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    3.525898] CR2: 0000000000000008 CR3: 000000000242c000 CR4: 
> 0000000000050660
> [    3.525904] Kernel panic - not syncing: Fatal exception
> [    3.525931] Kernel Offset: disabled
>
> And I have also another data point: Linux 7.2.6 is _not_ affected. And
> similarly, Linux 7.3-rc3 works fine (haven't tried -rc4 yet).

So it is likely that the patch in question went into 6.18.y without a
dependency.

Let's see.  In 6.18.52, acpi_processor_power_init() is called in the
!cpuidle_get_driver() case, which does not happen in the mainline.

AFAICS, 6.18.y needs to pick up commit 0089ce1c056a ("ACPI: processor:
Update cpuidle driver check in __acpi_processor_start()") whose Fixes:
tag should really point to 13ebeef6a1b9 which is a re-introduction of
7a8c994cbb2d originally fixed by 8a1b5d412cb4.

Thanks!