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

[Jarkko Sakkinen <jarkko@kernel.org>]

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