Re: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM
Hello all, Just wanted to give you a quick update now that I got my hands on an OEM Windows version of the same machine. I can confirm that Windows is able to use the TPM to some extent; confirmation and some of the output of some of the TPM Powershell cmdlets is at https://gist.github.com/hlieberman-gov/915fda005e3297570e9e6e68e1708bc6 Sincerely, -- Harlan Lieberman-Berg Defense Digital Service
Re: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM
On Sat, Aug 11, 2018 at 5:42 AM, Tomas Winkler wrote: > What platform is this? This is not regular 0xfed4 address space. I > guess this is BYT or CHT. It's better to get dmideoce dump as well. Hello Tomas, Jarkko, all, I'm not sure what's up with that. I've updated the firmware to the latest version (with no fix, sadly), and re-dumped the ACPI tables. They now process correctly through isl v20180629. I've also saved the output of dmidecode for you. https://gist.github.com/hlieberman-gov/83fa708d41051bafccc553cf0147db4f Sincerely, -- Harlan Lieberman-Berg Defense Digital Service
Re: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM
On Sat, Aug 11, 2018 at 12:45 AM Jarkko Sakkinen wrote: > > On Fri, Aug 10, 2018 at 07:57:35PM +0300, Jarkko Sakkinen wrote: > > On Tue, Aug 07, 2018 at 02:43:10PM -0400, Harlan Lieberman-Berg wrote: > > > (Resending as it seems to have been spamfiltered out from the ml; > > > sorry Peter, Jarkko for the duplicate) > > > > I came on Monday from four week leave and have been basically been > > catching up with my emails :-) I'll look into this next week with > > time. > > The error message is saying that someone else has reserved the resource > (-EBUSY). > > This looks odd: > > e78bf000-e7bbefff : ACPI Non-volatile Storage > e7bb6000-e7bb9fff : MSFT0101:00 > e7bba000-e7bbdfff : MSFT0101:00 > > Why would be TPM registers mapped inside ACPI NV? > > I would *guess* that what is happening is that perhaps drivers/acpi/nvs.c > maps the address space. This looks like a firmware bug, and such that we > cannot do anything about it. > > I'm having a weird issue with the ACPI tables: > > $ acpixtract acpidump.txt > > Intel ACPI Component Architecture > ACPI Binary Table Extraction Utility version 20180105 > Copyright (c) 2000 - 2018 Intel Corporation > > DSDT - 31048 bytes written (0x7948) - dsdt.dat > SSDT - 349 bytes written (0x015D) - ssdt1.dat > SSDT - 18086 bytes written (0x46A6) - ssdt2.dat > SSDT -5225 bytes written (0x1469) - ssdt3.dat > SSDT -1082 bytes written (0x043A) - ssdt4.dat > SSDT -1017 bytes written (0x03F9) - ssdt5.dat > SSDT -5369 bytes written (0x14F9) - ssdt6.dat > > $ iasl -d *.dat > > Intel ACPI Component Architecture > ASL+ Optimizing Compiler/Disassembler version 20180105 > Copyright (c) 2000 - 2018 Intel Corporation > > Input file dsdt.dat, Length 0x7948 (31048) bytes > Table [DSDT] is too long for file - needs: 0x815D, remaining in file: 0x7948 > Could not get ACPI tables from dsdt.dat, AE_BAD_HEADER > > This has not happened to me before. What platform is this? This is not regular 0xfed4 address space. I guess this is BYT or CHT. It's better to get dmideoce dump as well. It looks more like a BIOS issue. Please forward the complete data. Thanks Tomas
Re: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM
On Fri, Aug 10, 2018 at 07:57:35PM +0300, Jarkko Sakkinen wrote: > On Tue, Aug 07, 2018 at 02:43:10PM -0400, Harlan Lieberman-Berg wrote: > > (Resending as it seems to have been spamfiltered out from the ml; > > sorry Peter, Jarkko for the duplicate) > > I came on Monday from four week leave and have been basically been > catching up with my emails :-) I'll look into this next week with > time. The error message is saying that someone else has reserved the resource (-EBUSY). This looks odd: e78bf000-e7bbefff : ACPI Non-volatile Storage e7bb6000-e7bb9fff : MSFT0101:00 e7bba000-e7bbdfff : MSFT0101:00 Why would be TPM registers mapped inside ACPI NV? I would *guess* that what is happening is that perhaps drivers/acpi/nvs.c maps the address space. This looks like a firmware bug, and such that we cannot do anything about it. I'm having a weird issue with the ACPI tables: $ acpixtract acpidump.txt Intel ACPI Component Architecture ACPI Binary Table Extraction Utility version 20180105 Copyright (c) 2000 - 2018 Intel Corporation DSDT - 31048 bytes written (0x7948) - dsdt.dat SSDT - 349 bytes written (0x015D) - ssdt1.dat SSDT - 18086 bytes written (0x46A6) - ssdt2.dat SSDT -5225 bytes written (0x1469) - ssdt3.dat SSDT -1082 bytes written (0x043A) - ssdt4.dat SSDT -1017 bytes written (0x03F9) - ssdt5.dat SSDT -5369 bytes written (0x14F9) - ssdt6.dat $ iasl -d *.dat Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20180105 Copyright (c) 2000 - 2018 Intel Corporation Input file dsdt.dat, Length 0x7948 (31048) bytes Table [DSDT] is too long for file - needs: 0x815D, remaining in file: 0x7948 Could not get ACPI tables from dsdt.dat, AE_BAD_HEADER This has not happened to me before. /Jarkko