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
