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

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

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?

> Linux 6.18.52-r0, Xen domU: boots
> Linux 6.18.52-r0 with Xenbus notifier change reverted: still fails
> Linux 6.18.52-r0 with only ACPI processor/cpuidle changes reverted: boots
> Linux 6.18.52-r0 with refined ACPI idle lifecycle patch: boots
>
> Affected hardware tested:
>
> Intel Core i7-4785T thin mini-ITX, 16 GB DDR3
> Intel N305 thin mini-ITX, 16 GB DDR5
> Supermicro / Intel Xeon E5-1650, 32 GB DDR3
>
> The successful boot used the regular Xen command line:
>
> multiboot2 /boot/xen.gz cpufreq=xen:performance
> module2 /boot/vmlinuz-lts modules=loop,squashfs,sd-mod,usb-storage,xfs quiet
> module2 /boot/initramfs-lts
>
> No IOMMU workaround, serial console parameter, debug parameter, storage 
> workaround, or Xen command-line change was required.
>
> The regression was narrowed to ACPI processor/cpuidle changes between 6.18.51 
> and 6.18.52, specifically the idle-driver registration lifecycle.
>
> The working 6.18.51-style behavior registers the ACPI idle driver from 
> acpi_processor_power_init() and unregisters it from 
> acpi_processor_power_exit().
>
> The failing 6.18.52 behavior registers the ACPI idle driver globally from 
> acpi_processor_driver_init() before driver_register().
>
> A first ACPI-only revert confirmed the regression source. A refined candidate 
> patch was then prepared to preserve the working ACPI idle lifecycle while 
> keeping unrelated 6.18.52 safety fixes, including:
>
> _LPI bounds checks
> cpufreq notifier cleanup on acpi_processor_driver_init() failure
>
> The refined candidate patch modifies only:
>
> drivers/acpi/processor_driver.c
> drivers/acpi/processor_idle.c
> include/acpi/processor.h
>
> It does not modify Xen, Xenbus, IOMMU, APIC, PCI/ASPM, intel_idle, syscore, 
> USB, storage, XFS, networking, printk, or the cpuidle core API.
>
> The earlier cpuidle_disabled() workaround is not included.
>
> The refined patch has been rebuilt and boot-tested successfully as Xen dom0 
> on bare metal on TRINITY-EDGE.
>
> This issue is currently visible to Alpine users because the Alpine v3.24 
> stable repository contains:
>
> alpine-release 3.24.2-r0
> linux-lts 6.18.52-r0
>
> Systems tracking Alpine 3.24 stable / latest-stable may therefore receive 
> Linux 6.18.52 as the default LTS kernel.
>
> Attachments:
>
> revert-acpi-idle-registration-lifecycle.patch
> APKBUILD
>
> The original Alpine report is here:
>
> https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447
>
> Please let me know if this should be submitted as a formal patch with 
> Signed-off-by, or if there is a better upstream fix/dependency that should be 
> backported instead.

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.