On Fri, Feb 07, 2025 at 09:47:13AM +0000, Jonathan McDowell wrote: > 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 It's backported to the frankenkernel already so it would not help this particular case. Unfortunately, it's not clear what the userspace task does, and why it would not complete after the first failure. Would need to come up with some way of tracing it. Thanks Michal
