On Mon, Oct 19, 2026 at 04:08:27PM +0300, Jarkko Sakkinen wrote: > On Mon, Oct 19, 2026 at 03:05:42AM -0400, Sean Meadows wrote: > > > > On 10/10/26 15:39, Jarkko Sakkinen wrote: > > > > > > So the gist why I believe that this might have effect is that every > > > transmit reverts the state to the initial state. That should erase any > > > weird state that firmware might be in (usually not that great quality > > > code). > > > > > > I think Mario's patch is good overall for the stability. It looks to me > > > that we are catching some weird state inside firmware where we don't > > > have direct visibility. Or this is my guess at least. > > > > > > Br, Jarkko > > > > 7.3.0-rc6-g587527648af0 with cherry-pick > > 9154aa6c4b789d23e59d599c330cab2c4e915401 > > > > strings /lib/modules/$(uname -r)/build/vmlinux | grep "cmd_ready" > > Used to validate crb_cmd_ready responses. > > > > The patch failed at 201 hours, on the ninth drop into S3. While this > > represents an all-time high for uptime, the failure demonstrates that > > the Intel PTT can still enter a corrupt state. > > > > Where do we go from here? > > I don't know. I'd even consider finding the channel to report the > possible firmware bug to Intel. > > I don't have resources to do this but getting Windows CRB register > state captured could help. And then writing perhaps bpftrace script > to dump the live register state of tpm_crb (because you should > never trust reading code when you measure).
This leaves room open though on whether Windows does something with TPM on suspend. Probably nothing but just mentioning for completeness to point out where there is room for error. Br, Jarkko
