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
• 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.

Regards,

Tony BONNIN