On Thu, Sep 10, 2026 at 02:45:43AM -0400, Sean Meadows wrote: > Hello, > > I am writing to report a reproducible power management bug where the > system permanently hangs late in the ACPI S3 (sleep), S5 (shutdown), and > soft reboot cycle. > > The deadlock occurs at the absolute end of the platform teardown > sequence; after the kernel has completely unmounted all local storage. > Motherboard power rails remain fully active and fans spin continuously, > requiring a physical power button reset. Because this happens post > unmount and after the video terminates, standard runtime logs (pstore/ > dmesg) remain entirely empty. > > While sleep and shutdown hang forever, the soft reboot path has multiple > severe failure modes: hanging indefinitely, stalling for several minutes > before completing, or forcing a hard reset that corrupts the subsequent POST > phase. Standard kernel parameters like reboot=EFI, reboot=PCI, or cold boot > do not mitigate the issue. > > The deadlock does not happen immediately after a recent cold boot or > reboot. The system must run for a number of hours before the condition > occurs. > > 1. Reproduction > The failure state can be made consistently repeatable via kernel > initialization parameters and modprobe.d blacklist: > > - Test A (Fail State): Booting with standard parameters. Triggering an > S3 sleep, S5 shutdown, or reboot results in a guaranteed, hardware freeze. > > - Test B (Pass State): Booting with the command line parameter: > ‘modprobe.blacklist=tpm_crb’ and modprobe.d conf with ‘blacklist tpm_crb’ > When the tpm_crb driver is completely prevented from initializing, the > system executes S3 suspend, S5 shutdown, and reboot sequences flawlessly > 100% of the time. > > - Other end users suffering from this problem have found a repeatable > fix by going into the UEFI and disabling the PTT. My particular system > lacks that option. > > 2. Supporting Data > This bug appears to be unique to the Intel PTT controllers powering the > 6th through 10th Generation Intel CPU families (Skylake through Comet > Lake), spanning mobile, desktop, and HEDT platforms. The bulk of the > data also implies that this isn’t isolated to a specific OEM. > > - Bugzilla #217890: > chriscjsus: MSI GS40 6QE | Intel i7-6700HQ > mahasler: Intel NUC7i3BNB | Intel Core i3-7100U > Boris Carvajal: MSI Z370 Tomahawk | Intel i5-8400 > Serhii Tsynailo: Intel i5-8250u laptop > Sergio: ASUS ZenBook UX310UQK | Intel i7-7500U > My System: ASUS ROG GL703VM | HM175 Chipset | Intel i7-7700HQ | MEI FW > v11.9.1.3010 | Running Arch Linux vanilla stable kernel 7.2.4 (stock > package) > > - Community Threads: > Arch Forum (ID: 303082): Solved exclusively by disabling Intel PTT in > BIOS (Gigabyte B460 | Intel 10th Gen) > Reddit (r/archlinux): Widespread tracking detailing identical S3/S5 > deadlocks (X299/Z370) > > 3. Additional Details > An unmerged diagnostic patch submitted by another user (Adam Alves, > Patchwork ID: [email protected]) previously > presumed that this late freeze on certain motherboards occurs because > the driver leaves the fTPM/PTT hardware interface in an unreleased, non- > zero locality state upon teardown. The author suggested that the > platform firmware's pre-OS and ACPI transition environments expect the > TPM to be sitting strictly in Locality 0, causing the firmware to enter > an infinite timeout wait-state when control is passed back to it. > > I am not qualified to audit the driver. Whether this belongs in the DMI, > is a mistake in the driver logic, or is a bug in the PTT I can’t answer. > I can only point to the unfailing success of a growing number of public > end users who can instantly fix the problem by disabling the PTT in > firmware or blacklisting the TPM driver. I have included the ACPI > team in this e-mail in the hopes that they can provide additional clarity. > > I have never compiled a custom kernel before, but I am set up to > reproduce this and am entirely willing to act as a tester for any > diagnostic patches the maintainers would like to provide. > > Thank you for your time and patience, > Sean
Has this appeared within some timeframe or has been like this "forever"? BR, Jarkko
