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

[Mario Limonciello <mario.limonciello@amd.com>]

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.