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

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

[Sean Meadows]

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

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

[Jarkko Sakkinen]

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

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

[Sean Meadows]

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

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

[Jarkko Sakkinen]

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

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

[Sean Meadows]

On 9/25/26 11:05, Jarkko Sakkinen wrote:
> 
> 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.
> 
> 
> Br, Jarkko

Acknowledged.

Disabling HWRNG via kernel cmdline failed, and since my research implied
that path would require a custom kernel, I shifted my efforts toward
forward-porting Mr. Alves's 2024 patch to 7.2.7. It took some work, but
I have successfully compiled it and got it booting on my machine.

The patch appears to sort out the issue so far, but I'm only 43 hours
into the test. As we discussed previously, this bug can take days to
manifest, so I will reply again once I cross a week of sleep cycles
without a crash.

I also have a USB3 debug cable on the way in hope of capturing the
hardware state during the power transition. That said, if Mr. Alves's
patch continues to work as well as it has so far, there may not be any
need for that.

Sean

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

[Jarkko Sakkinen]

On Tue, Sep 29, 2026 at 01:44:29PM -0400, Sean Meadows wrote:
> 
> On 9/25/26 11:05, Jarkko Sakkinen wrote:
> > 
> > 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.
> > 
> > 
> > Br, Jarkko
> 
> Acknowledged.
> 
> Disabling HWRNG via kernel cmdline failed, and since my research implied
> that path would require a custom kernel, I shifted my efforts toward
> forward-porting Mr. Alves's 2024 patch to 7.2.7. It took some work, but
> I have successfully compiled it and got it booting on my machine.
> 
> The patch appears to sort out the issue so far, but I'm only 43 hours
> into the test. As we discussed previously, this bug can take days to
> manifest, so I will reply again once I cross a week of sleep cycles
> without a crash.
> 
> I also have a USB3 debug cable on the way in hope of capturing the
> hardware state during the power transition. That said, if Mr. Alves's
> patch continues to work as well as it has so far, there may not be any
> need for that.
> 
> Sean

There's a commit with title "tpm: Call cmd_ready/go_idle for each command
transmission", which is strongest contender to make a difference to this
long running issue.

I.e. I think it will improve firmware behavior given full release of
resources per TPM command.

I'm including it to v7.4 pull request.

Br, Jarkko

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

[Sean Meadows]

On 9/29/26 18:25, Jarkko Sakkinen wrote:
> There's a commit with title "tpm: Call cmd_ready/go_idle for each command
> transmission", which is strongest contender to make a difference to this
> long running issue.
> 
> I.e. I think it will improve firmware behavior given full release of
> resources per TPM command.
> 
> I'm including it to v7.4 pull request.
> 
> Br, Jarkko

Hi Jarkko,

I have to break some bad news.

Testing Mr. Alves’s patch first led to a failure at the 60-hour mark.

Mario’s patch—"tpm: Call cmd_ready/go_idle for each command
transmission"—failed at 55 hours.

To give additional details: with Alves’ patch, I ported it forward and
tested it on kernel 7.2.7.

With Mario’s patch, I downloaded the 7.3-rc5 mainline tree from Linus,
git-grabbed your tree to get the TPM patches, and then cherry-picked
Mario’s commit. It was applied and built without issue. If being cherry-
picked onto 7.3-rc5 left it deficient in some way, please let me know.

I then proceeded to run 7.2.8 with my new USB3 debug cable.

I initiated an S3 sleep after a fresh power-on to get a baseline. I have
complete logs saved, but I’ll simplify here to keep the message short
and succinct.

1. systemd-logind[483]: Lid closed.
2. rtkit-daemon[648]: Successfully demoted thread 1001 of process 993.
3. systemd-logind[483]: The system will suspend now!
4. Kernel enters device suspend phase | driver callbacks | many lines of
confirmation as drivers and hardware transitioned

45 hours later, I tested the next S3 sleep and the following occurred:

1. systemd-logind[483]: Lid closed.
2. rtkit-daemon[648]: Successfully demoted thread 1001 of process 993.
3. Deadlock | USB3 DbC link drops immediately

I don’t know what all can be captured through this debug cable, and this
next thought might be nonsensical as a result. Would you benefit from me
installing Windows and snooping on what the Microsoft TPM driver is
doing to prevent this deadlock?

Thank you for your time and patience,

Sean

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

[Jarkko Sakkinen]

On Wed, Oct 07, 2026 at 12:27:01PM -0400, Sean Meadows wrote:
> On 9/29/26 18:25, Jarkko Sakkinen wrote:
> > There's a commit with title "tpm: Call cmd_ready/go_idle for each command
> > transmission", which is strongest contender to make a difference to this
> > long running issue.
> > 
> > I.e. I think it will improve firmware behavior given full release of
> > resources per TPM command.
> > 
> > I'm including it to v7.4 pull request.
> > 
> > Br, Jarkko
> 
> Hi Jarkko,
> 
> I have to break some bad news.
> 
> Testing Mr. Alves’s patch first led to a failure at the 60-hour mark.
> 
> Mario’s patch—"tpm: Call cmd_ready/go_idle for each command
> transmission"—failed at 55 hours.
> 
> To give additional details: with Alves’ patch, I ported it forward and
> tested it on kernel 7.2.7.
> 
> With Mario’s patch, I downloaded the 7.3-rc5 mainline tree from Linus,
> git-grabbed your tree to get the TPM patches, and then cherry-picked
> Mario’s commit. It was applied and built without issue. If being cherry-
> picked onto 7.3-rc5 left it deficient in some way, please let me know.
> 
> I then proceeded to run 7.2.8 with my new USB3 debug cable.
> 
> I initiated an S3 sleep after a fresh power-on to get a baseline. I have
> complete logs saved, but I’ll simplify here to keep the message short
> and succinct.
> 
> 1. systemd-logind[483]: Lid closed.
> 2. rtkit-daemon[648]: Successfully demoted thread 1001 of process 993.
> 3. systemd-logind[483]: The system will suspend now!
> 4. Kernel enters device suspend phase | driver callbacks | many lines of
> confirmation as drivers and hardware transitioned
> 
> 45 hours later, I tested the next S3 sleep and the following occurred:
> 
> 1. systemd-logind[483]: Lid closed.
> 2. rtkit-daemon[648]: Successfully demoted thread 1001 of process 993.
> 3. Deadlock | USB3 DbC link drops immediately
> 
> I don’t know what all can be captured through this debug cable, and this
> next thought might be nonsensical as a result. Would you benefit from me
> installing Windows and snooping on what the Microsoft TPM driver is
> doing to prevent this deadlock?
> 
> Thank you for your time and patience,

The patch I pointed out this in bugzilla but the patch I had in mind is:

"tpm: Call cmd_ready/go_idle for each command transmission"

Link: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=9154aa6c4b789d23e59d599c330cab2c4e915401

The reason is that the commit message highlight a bit similar issues as
reported in the bug.

Note commit IDs do change in my master branch so best is to look it up from: 

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/

Right another reason is that then the driver always the TPM in the state
as it is when the driver starts.

I'm not sure about Windows but neither disregard it as sometimes we do
pick behavior basing it on how Window does it. I'd still try Mario's
patch at first.

> 
> Sean

Br, Jarkko

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

[Mario Limonciello]

On 10/8/26 12:47, Jarkko Sakkinen wrote:
> On Wed, Oct 07, 2026 at 12:27:01PM -0400, Sean Meadows wrote:
>> On 9/29/26 18:25, Jarkko Sakkinen wrote:
>>> There's a commit with title "tpm: Call cmd_ready/go_idle for each command
>>> transmission", which is strongest contender to make a difference to this
>>> long running issue.
>>>
>>> I.e. I think it will improve firmware behavior given full release of
>>> resources per TPM command.
>>>
>>> I'm including it to v7.4 pull request.
>>>
>>> Br, Jarkko
>>
>> Hi Jarkko,
>>
>> I have to break some bad news.
>>
>> Testing Mr. Alves’s patch first led to a failure at the 60-hour mark.
>>
>> Mario’s patch—"tpm: Call cmd_ready/go_idle for each command
>> transmission"—failed at 55 hours.
>>
>> To give additional details: with Alves’ patch, I ported it forward and
>> tested it on kernel 7.2.7.
>>
>> With Mario’s patch, I downloaded the 7.3-rc5 mainline tree from Linus,
>> git-grabbed your tree to get the TPM patches, and then cherry-picked
>> Mario’s commit. It was applied and built without issue. If being cherry-
>> picked onto 7.3-rc5 left it deficient in some way, please let me know.
>>
>> I then proceeded to run 7.2.8 with my new USB3 debug cable.
>>
>> I initiated an S3 sleep after a fresh power-on to get a baseline. I have
>> complete logs saved, but I’ll simplify here to keep the message short
>> and succinct.
>>
>> 1. systemd-logind[483]: Lid closed.
>> 2. rtkit-daemon[648]: Successfully demoted thread 1001 of process 993.
>> 3. systemd-logind[483]: The system will suspend now!
>> 4. Kernel enters device suspend phase | driver callbacks | many lines of
>> confirmation as drivers and hardware transitioned
>>
>> 45 hours later, I tested the next S3 sleep and the following occurred:
>>
>> 1. systemd-logind[483]: Lid closed.
>> 2. rtkit-daemon[648]: Successfully demoted thread 1001 of process 993.
>> 3. Deadlock | USB3 DbC link drops immediately
>>
>> I don’t know what all can be captured through this debug cable, and this
>> next thought might be nonsensical as a result. Would you benefit from me
>> installing Windows and snooping on what the Microsoft TPM driver is
>> doing to prevent this deadlock?
>>
>> Thank you for your time and patience,
> 
> The patch I pointed out this in bugzilla but the patch I had in mind is:
> 
> "tpm: Call cmd_ready/go_idle for each command transmission"
> 
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=9154aa6c4b789d23e59d599c330cab2c4e915401
> 
> The reason is that the commit message highlight a bit similar issues as
> reported in the bug.
> 
> Note commit IDs do change in my master branch so best is to look it up from:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/
> 
> Right another reason is that then the driver always the TPM in the state
> as it is when the driver starts.
> 
> I'm not sure about Windows but neither disregard it as sometimes we do
> pick behavior basing it on how Window does it. I'd still try Mario's
> patch at first.
> 
>>
>> Sean
> 
> Br, Jarkko

FWIW the issue my patch fixed manifested at bootup; but I definitely 
agree with Jarkko's hypothesis that it could apply to other TPM 
implementations and at different times.

When you tested Adam's patch I would like to point out it only 
automatically applies to one board: "TUF GAMING B460M-PLUS".

If that doesn't match your board you would need to set 
tpm.sleep_locality_preserve=1 for it to apply.

If you're sure my patch alone isn't enough to fix it you might try 
combining patches and setting that.

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

[Sean Meadows]

On 10/8/26 16:00, Mario Limonciello wrote:
>> The patch I pointed out this in bugzilla but the patch I had in mind
>> is:
>> 
>> "tpm: Call cmd_ready/go_idle for each command transmission"
>> 
>> Link: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux- 
>> tpmdd.git/commit/?id=9154aa6c4b789d23e59d599c330cab2c4e915401
>> 
>> The reason is that the commit message highlight a bit similar issues
>> as reported in the bug.
>> 
>> Note commit IDs do change in my master branch so best is to look it
>> up from:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux- tpmdd.git/
>> log/
>> 
>> Right another reason is that then the driver always the TPM in the
>> state as it is when the driver starts.
>> 
>> I'm not sure about Windows but neither disregard it as sometimes we
>> do pick behavior basing it on how Window does it. I'd still try
>> Mario's patch at first.

Checking my notes, I cherry-picked commit 
19931faa1d75fb858d86aaf5b0e79d34a2379094, which I understood to be v3 of 
the patch.

Assuming I made a mistake there, I've started from scratch and applied 
commit 9154aa6c4b789d23e59d599c330cab2c4e915401 instead, which should be v6.

Once the compile and install are complete, it will take at least a 
couple of days of testing to determine whether it prevents the corrupted 
state.

> FWIW the issue my patch fixed manifested at bootup; but I definitely agree
> with Jarkko's hypothesis that it could apply to other TPM implementations
> and at different times.
> 
> When you tested Adam's patch I would like to point out it only 
> automatically applies to one board: "TUF GAMING B460M-PLUS".
> 
> If that doesn't match your board you would need to set 
> tpm.sleep_locality_preserve=1 for it to apply.
> 
> If you're sure my patch alone isn't enough to fix it you might try 
> combining patches and setting that.

When I ported Mr. Alves's patch forward, I altered it to enable globally 
rather than targeting a specific board, so I was cognizant of that 
hardware-matching pitfall. After booting, I also verified via `cat 
/sys/...` that the parameter was live.

That said, I am not entirely confident that Mr. Alves's patch is the 
correct path forward. Even he discovered that it merely extended the 
time until failure:

https://lore.kernel.org/all/
CAHwaaX8bWOFW2bi6tKpxgf2Cp_vKg5Eqhq618VEur98s+OmD=A@mail.gmail.com/

His last message on the topic indicated he was heading in a different
direction—stating he would submit a separate patch if it bore fruit. As
far as I can tell, that follow-up patch never materialized, though I
cannot say whether he simply got busy or if it ultimately failed to
solve the problem:

https://lore.kernel.org/all/CAHwaaX-
j37rq4+DCNSRAgPmeQmrYZiX2sLv4ugBjPJSj9LPxcg@mail.gmail.com/#t

Sean