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.
