On Sat, Dec 28, 2019 at 9:17 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > On Sat, Dec 28, 2019 at 7:15 AM Jarkko Sakkinen > <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > > > On Fri, Dec 27, 2019 at 08:11:50AM +0200, Jarkko Sakkinen wrote: > > > Dan, please also test the branch and tell if other patches are needed. > > > I'm a bit blind with this as I don't have direct access to the faulting > > > hardware. Thanks. [*] > > > > > > [*] https://lkml.org/lkml/2019/12/27/12 > > > > Given that: > > > > 1. I cannot reproduce the bug locally. > > 2. Neither of the patches have any appropriate tags (tested-by and > > reviewed-by). [*] > > > > I'm sorry but how am I expected to include these patches? > > Thanks for the branch, I'll get it tested on the failing hardware. > Might be a few days due to holiday lag. This looked like the wrong revert to me, and testing confirms that this does not fix the problem. As I mentioned in the original report [1] the commit that bisect flagged was: 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's That commit moved tpm_chip_start() before irq probing. Commit 21df4a8b6018 "tpm_tis: reserve chip for duration of tpm_tis_core_init" does not appear to change anything in that regard. Perhaps this hardware has always had broken interrupts and needs to be quirked off? I'm trying an experiment with tpm_tis_core.interrupts=0 workaround. [1]: https://lore.kernel.org/linux-integrity/CAA9_cmeLnHK4y+usQaWo72nUG3RNsripuZnS-koY4XTRC+mwJA@xxxxxxxxxxxxxx/
