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
