All of lore.kernel.org
 help / color / mirror / Atom feed
From: Support TRINITY <support@trinity-net.com>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: regressions <regressions@lists.linux.dev>,
	 linux-acpi <linux-acpi@vger.kernel.org>,
	 linux-pm <linux-pm@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	 xen-devel <xen-devel@lists.xenproject.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot
Date: Mon, 21 Sep 2026 13:06:59 +0000 (UTC)	[thread overview]
Message-ID: <8375109.285919554.1789996019673.JavaMail.zimbra@trinity-net.com> (raw)
In-Reply-To: <8aaad113-1952-4655-978d-0cdd8b048064@leemhuis.info>

Hello Thorsten,
Thanks for the follow-up.
I have not tested latest 7.3-rc yet. So far, the regression was only tested and isolated on the Alpine linux-lts 6.18.51 -> 6.18.52 path.
I will now test:
latest 7.3-rc as-is on the affected bare-metal Xen dom0 host;
latest 7.3-rc with the same partial ACPI processor/cpuidle lifecycle revert applied.
I will report back with the results.
Regards,
Tony


-----Message original-----
De: Thorsten Leemhuis <regressions@leemhuis.info>
à: Support TRINITY <support@trinity-net.com>; regressions <regressions@lists.linux.dev>; linux-acpi <linux-acpi@vger.kernel.org>; linux-pm <linux-pm@vger.kernel.org>; stable <stable@vger.kernel.org>; xen-devel <xen-devel@lists.xenproject.org>; linux-kernel <linux-kernel@vger.kernel.org>
Envoyé: lundi 21 septembre 2026 12:01 CEST
Sujet : Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot


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

  reply	other threads:[~2026-09-21 13:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 15:48 [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot Support TRINITY
2026-09-21 10:00 ` Thorsten Leemhuis
2026-09-21 13:06   ` Support TRINITY [this message]
2026-09-21 15:26 ` Rafael J. Wysocki (Intel)
2026-09-21 16:44   ` Marek Marczykowski-Górecki
2026-09-21 17:46     ` Support TRINITY
2026-09-21 18:05       ` Rafael J. Wysocki (Intel)
2026-09-21 18:29         ` Support TRINITY
2026-09-22  2:23           ` Sasha Levin
2026-09-22 10:04             ` Support TRINITY
2026-09-21 18:03     ` Rafael J. Wysocki (Intel)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8375109.285919554.1789996019673.JavaMail.zimbra@trinity-net.com \
    --to=support@trinity-net.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.