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

[Thorsten Leemhuis]

On 9/20/26 17:48, Support TRINITY wrote:
>
> I am reporting a bare-metal *Xen* dom0 boot regression seen with *Linux
> 6.18.52.*

Thx for the report. There is one somewhat important detail that was
missing (hope I didn't miss it):

Is latest 7.3-rc also affected? And if it is: does that partial revert
help there, too?

Ciao, Thorsten
> 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 <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
> <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*
> 


#regzbot introduced: 6cffb59ee50ea4