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 
> <jguntho...@obsidianresearch.com>:
> >On Tue, Oct 11, 2016 at 03:01:01PM +0300, Jarkko Sakkinen wrote:
> >> From: Peter Huewe <peterhu...@gmx.de>
> >> 
> >> 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.


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

Reply via email to