Re: [BUG] tpm_crb/Intel PTT: Late S3/S5/Reboot ACPI power management deadlock

[Jarkko Sakkinen <jarkko@kernel.org>]

On Tue, Sep 22, 2026 at 04:42:47AM -0400, Sean Meadows wrote:
> On 9/17/26 21:28, Jarkko Sakkinen wrote:
> > 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: 20240307000331.14848-2-adamoa@gmail.com) 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
> 
> Hi Jarkko,
> 
> Regarding whether this has been a bug forever, I suspect the answer is
> yes, though with a few caveats. My pacman.log shows I made the shift
> from Windows to Arch Linux in August 2022. Vaguely I recall reboots, S3,
> and S5 working initially, but I am an unreliable narrator after dealing
> with this issue for years - and the various technical threads I
> referenced do note regressions cropping up across the 6.x kernel series.
> 
> I also need to update my previous notes regarding blacklisting tpm_crb.
> It is not a complete fix; rather, it extends the timeframe of the
> failure from hours to days, but the deadlock will eventually happen
> anyway. That leaves the only foolproof fixes as running Windows or
> having a UEFI that allows disabling the PTT.
> 
> My working hypothesis is that these older PTT implementations require a
> specific state cleanup during OS teardown. Since the issue occurs even
> without the driver loaded, the problem isn't isolated to driver
> teardown; rather, it implies that background ACPI firmware routines
> interact with the PTT, gradually desynchronizing the hardware state until
> the final power-down handoff traps it.
> 
> My testing hasn't stopped. I am currently trying to modify my UEFI to
> force-disable the PTT, though customizing the ROM and flashing it with a
> CH341A programmer and micrograbbers is slow, tedious work. I am also
> hampered by the Asus UEFI being very fragile and the hidden TPM options
> tested so far turning out to be dead entries.
> 
> As I noted before, I am fully prepared to test patches or gather
> hardware data, though I suspect this laptop lacks any accessible serial
> debugging headers to catch logs post-unmount.
> 
> Thank you for your time and patience,

Thanks for providing the information.

Bugzilla bug under discussion: https://bugzilla.kernel.org/show_bug.cgi?id=217890

I also found fix attempt of which 3rd version somehow went past me:

https://lore.kernel.org/all/20240308145313.40932-1-adamoa@gmail.com/

Does this or disabling hwrng sort out the issue?

I got one other idea too with no empirical basis (just hypothesis):
perhaps release memory mapping on suspend could help firmware.

> 
> Sean

Br, Jarkko