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

[Sean Meadows <Hellfire@unspacy.com>]

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,

Sean