On Fri, Feb 07, 2025 at 10:40:16AM +0100, Michal Suchánek wrote: > On Fri, Feb 07, 2025 at 09:26:16AM +0000, Jonathan McDowell wrote: > > So just to clarify, this more recent patch is working around a situation > > where the status register gets stuck and needs a complete retry of the > > command send - it's an Infineon errata, not something that would be > > fixed with a longer timeout. > > > > We see what looks like Michal's issue with timeouts as well, I just > > haven't made the step of instrumenting it all the way he has. > > And I haven't seen the issue that needs re-sending the command so far. Your SLB9672 is on the latest firmware, which I believe fixes the problem. > Maybe it happens even less frequently than the excessive processing > time. > > Fully restarting the syscall would fix both issues but manual restart of > the userspace task reportedly did not work so I have my doubts that > this method with returning from the syscall would be effective. Hmmm. I wonder if e3aaebcbb7c6b403416f442d1de70d437ce313a7 (tpm: Clean up TPM space after command failure) would help the userspace restart work. We saw problems with the timeouts affecting the kernel doing the cleanup of the transient handles, meaning we'd then run out of transient slots in the TPM. If you can reproduce the problem then tpm2_getcap -T device:/dev/tpm0 handles-transient will show if that is the case - if it doesn't output anything this isn't what you're hitting. J. -- Inside every living person there's a dead person trying to get out.
