On Wed, Oct 12, 2016 at 03:16:06PM +0300, Jarkko Sakkinen wrote: > On Tue, Oct 11, 2016 at 08:01:09PM +0200, Peter Huewe wrote: > > > > > > Hi > > Am 11. Oktober 2016 19:13:13 MESZ, schrieb Jason Gunthorpe > > <[email protected]>: > > >On Tue, Oct 11, 2016 at 03:01:01PM +0300, Jarkko Sakkinen wrote: > > >> From: Peter Huewe <[email protected]> > > >> > > >> In some weird cases it might be possible that the TPM does not set > > >> STS.VALID within the given timeout time (or ever) but sets STS.EXPECT > > >> (STS=0x0C) In this case the driver gets stuck in the while loop of > > >> tpm_tis_send_data and loops endlessly. > > > > > >Doesn't that exchange mean the TPM has lost synchronization with the > > >driver? Or maybe it crashed executing a command or something.. > > > > I saw that in the field on quite a few (similar) systems with our lpc tpms > > - so it affects end users. > > Yes it is caused by some desynchronization or something similar. > > > > If you manually send a commandReady by mmaping the memory region you can > > un-stuck the driver and the situation was never seen again on that system. > > > > The exact reason how this happens is yet unknown, but the driver should > > definitely not be stuck in an endless loop (which zombies the application > > too) in that case but bail out as defined in the TIS protocol. The next > > access sends the cr which cures the unsynchronization. > > Even as a sanity check return codes should be checked so in > any case I leaned towards applying this patch. It makes the > driver more robust.
I applied this. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
