mirror of https://lore.kernel.org/lkml/
 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:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 15:48 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®