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.. tpm_read_log_acpi should check if the chip has a acpi_dev_handle before running, but it also shouldn't crash - so there are two bugs here I guess.. Please do that instead of the checking the virual flag. Jarkko, you know acpi better, we switched ppi to search starting from the acpi_dev_handle for its data - can we do the same for event log? > The crash looks like this: > [ 173.608722] [<ffffffff8140ca11>] dump_stack+0x63/0x82 > [ 173.608722] [<ffffffff8106b99f>] iounmap.part.1+0x7f/0x90 > [ 173.608722] [<ffffffff8106b9dc>] iounmap+0x2c/0x30 > [ 173.608722] [<ffffffff81496c75>] acpi_os_map_cleanup.part.10+0x31/0x3e > [ 173.608722] [<ffffffff8179629c>] acpi_os_unmap_iomem+0xcb/0xd2 > [ 173.608722] [<ffffffffa00e1b28>] read_log+0xc8/0x19e [tpm] This seems really strange ACPI should not crash like this - yes it will wrongly read the log for the system into the vtpm, but that *should* work. Are you doing anything special with this test like high parallism or something? Any chance you can look at little more? The tpm code looks OK to me, the map and unmap are properly paired - but the bad address from the iounmap suggests the refcounting in acpi is not working or something along those lines? Jason ------------------------------------------------------------------------------ _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
