On Thu, Nov 17, 2016 at 07:35:05AM -0500, Stefan Berger wrote: > On 11/16/2016 03:07 PM, Jason Gunthorpe wrote: > > On Wed, Nov 16, 2016 at 12:07:23PM -0500, Stefan Berger wrote: > > > The culprit seems to be 'tpm: fix the missing .owner in > > > tpm_bios_measurements_ops' > > That is unlikely, it is probably the patch before which calls read_log > > unconditionally now. That suggests the crashing is a little random.. > > I ran the vtpm driver test suite (with -j32) a few times at that patch and > it didn't crash. It crashes severely with later patches applied. Here's the > current experimental patch that fixes these problems: > > iff --git a/drivers/char/tpm/tpm_acpi.c b/drivers/char/tpm/tpm_acpi.c > index 0cb43ef..a73295a 100644 > --- a/drivers/char/tpm/tpm_acpi.c > +++ b/drivers/char/tpm/tpm_acpi.c > @@ -56,6 +56,9 @@ int tpm_read_log_acpi(struct tpm_chip *chip) > > log = &chip->log; > > + if (!chip->acpi_dev_handle) > + return 0; > + If there is a problem in the TPM driver, this does not fix the problem. It will mask the problem. Maybe there's an ACPI regression in the rc tree? This is a funky situation because those lines need to be there but I do not want them before it is root caused that it is not a TPM bug. /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
