[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