From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Harlan Lieberman-Berg <harlan@dds.mil>
Cc: Peter Huewe <peterhuewe@gmx.de>,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM
Date: Sat, 11 Aug 2018 00:44:48 +0300 [thread overview]
Message-ID: <20180810214433.GA15044@linux.intel.com> (raw)
In-Reply-To: <20180810165735.GT4692@linux.intel.com>
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 (0x00007948) - dsdt.dat
SSDT - 349 bytes written (0x0000015D) - ssdt1.dat
SSDT - 18086 bytes written (0x000046A6) - ssdt2.dat
SSDT - 5225 bytes written (0x00001469) - ssdt3.dat
SSDT - 1082 bytes written (0x0000043A) - ssdt4.dat
SSDT - 1017 bytes written (0x000003F9) - ssdt5.dat
SSDT - 5369 bytes written (0x000014F9) - 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
next parent reply other threads:[~2018-08-10 21:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAO-sURTngN_mnpJp9rvutpDfz80Nq4K8JOH4fnZG2NaTafkx+g@mail.gmail.com>
[not found] ` <CAO-sURTs1dc_5iY+b34Jqj4hxZFdUj9LZxTWhDdvqM8AbEqMAw@mail.gmail.com>
[not found] ` <20180810165735.GT4692@linux.intel.com>
2018-08-10 21:44 ` Jarkko Sakkinen [this message]
2018-08-11 9:42 ` Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM Tomas Winkler
2018-08-11 18:29 ` Harlan Lieberman-Berg
2018-08-15 18:02 ` Harlan Lieberman-Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180810214433.GA15044@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=harlan@dds.mil \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=peterhuewe@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).