On Fri, 2020-02-14 at 16:04 -0500, James Bottomley wrote: > On Fri, 2020-02-14 at 14:02 -0700, Jerry Snitselaar wrote: > > On Fri Feb 14 20, James Bottomley wrote: > > > On Fri, 2020-02-14 at 10:32 -0800, Alex Guzman wrote: > > > > Looks like someone had a look on the bug tracker > > > > (https://bugzilla.kernel.org/show_bug.cgi?id=206275#c6) > > > > and they figure it's definitely a regression in the kernel and > > > > should > > > > be reverted or rectified. They advised me to come ping here > > > > once > > > > more. > > > > > > Reading the bugzilla, I don't get *what* needs to be > > > reverted. The > > > commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e isn't present in > > > upstream, so what kernel is it present in, or what is the full > > > commit message so we can find the upstream commit? > > > > > > James > > > > > > > > > > - Alex > > > > > > > > On Sat, Feb 1, 2020 at 4:19 PM Alex Guzman <alex@xxxxxxxxx> > > > > wrote: > > > > > Hey there! I reported a bug on the bug tracker a bit ago but > > > > > haven't seen any movement, so I figured I'd drop in here. My > > > > > XPS 9560 has been having issues with its TPM, and all > > > > > commands > > > > > will fail with error 1 when operating on the TPM device. I > > > > > managed to bisect it back to commit > > > > > 4d6ebc4c4950595414722dfadd0b361f5a05d37e (tpm: fix > > > > > invalid locking in NONBLOCKING mode) though it began failing > > > > > with error 14 (bad address) at that point. > > > > > > > > > > I reported the bug at > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=206275 and > > > > > attached > > > > > some dmesg logs from boot there. Does anyone have any > > > > > suggestions for additional debugging or such to figure out > > > > > what's happening here? > > > > > > > > > > - Alex > > > > d23d12484307 | 2019-12-17 | tpm: fix invalid locking in NONBLOCKING > > mode (Tadeusz Struk) > > > > There is a commit that is a fix to this commit: > > > > a430e67d9a2c | 2020-01-08 | tpm: Handle negative priv->response_len > > in tpm_common_read() (Tadeusz Struk) > > Yes, I suspected it might be that ... in which case upstream should > have the fix, can we verify that 5.6-rc1 works just fine? > > James > I just tested with 5.6_rc1. The behavior is still present: ERROR:tcti:src/tss2-tcti/tcti-device.c:290:tcti_device_receive() Failed to read response from fd 3, got errno 1: Operation not permitted ERROR:esys:src/tss2- esys/api/Esys_GetCapability.c:307:Esys_GetCapability_Finish() Received a non-TPM Error ERROR:esys:src/tss2- esys/api/Esys_GetCapability.c:107:Esys_GetCapability() Esys Finish ErrorCode (0x000a000a) ERROR: Esys_GetCapability(0xA000A) - tcti:IO failure ERROR: Unable to run tpm2_getcap
