Am 11. Juli 2018 22:39:05 MESZ schrieb James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>: >On Wed, 2018-07-11 at 14:01 -0600, Jason Gunthorpe wrote: >> On Wed, Jul 11, 2018 at 12:08:53PM -0700, James Bottomley wrote: >> > On Wed, 2018-07-11 at 12:21 -0600, Jason Gunthorpe wrote: >> > > On Wed, Jul 11, 2018 at 10:11:14AM -0700, James Bottomley wrote: >> > > > tpm_tis regressed recently to the point where the TPM being >> > > > driven >> > > > by >> > > > it falls off the bus and cannot be contacted after some hours >> > > > of >> > > > use. >> > > > This is the failure trace: >> > > > >> > > > jejb@jarvis:~> dmesg|grep tpm >> > > > [ 3.282605] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, >> > > > rev-id >> > > > 2) >> > > > [14566.626614] tpm tpm0: Operation Timed out >> > > > [14566.626621] tpm tpm0: tpm2_load_context: failed with a >> > > > system >> > > > error -62 >> > > > [14568.626607] tpm tpm0: tpm_try_transmit: tpm_send: error -62 >> > > > [14570.626594] tpm tpm0: tpm_try_transmit: tpm_send: error -62 >> > > > [14570.626605] tpm tpm0: tpm2_load_context: failed with a >> > > > system >> > > > error -62 >> > > > [14572.626526] tpm tpm0: tpm_try_transmit: tpm_send: error -62 >> > > > [14577.710441] tpm tpm0: tpm_try_transmit: tpm_send: error -62 >> > > > ... >> > > > >> > > > The problem is caused by a change that caused us to poke the >> > > > TPM >> > > > far >> > > > more often to see if it's ready. Apparently something about >> > > > the >> > > > bus >> > > > its on and the TPM means that it crashes or falls off the bus >> > > > if >> > > > you >> > > > poke it too often and once this happens, only a reboot will >> > > > recover >> > > > it. >> > > >> > > I wonder if something about triggering ETIME even once breaks the >> > > driver so it can't talk to the chip at all thereafter.. >> > > >> > > Ie it doesn't abort the command properly and becomes desynced >> > > with the TIS execution protocol. >> > >> > Yes, I wondered about this, but I don't understand the bus protocol >> > well enough. The tpm-interface:tpm_try_transmit() which throws the >> > first ETIME says after we get that we send chip->ops->cancel() >> > which tpm_tis simply translates to tpm_tis_ready() which also times >> > out. Is there a bigger hammer I can hit it with? >> >> I don't remember off hand.. But this is, IMHO, a better guess than >> the firmware crashes from reading the status register.. > >Oh, actually, I think the bus crashes or wedges, not the TPM. I just >don't have any tools to probe the LPC. > I doubt that your fTPM is actually attached to LPC. And usually if lpc wedges it takes down your pc with it (from my experience) I wonder what the contents of the acc and sts registers actually are. If you want i can send you a small tis 'debug' tool tomorrow. >James > > >> Perhaps reducing the timeout to force a ETIME would prove the theory? -- Sent from my mobile
