From: Ed Swierk <eswierk@skyportsystems.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Stefan Berger <stefanb@us.ibm.com>
Subject: Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override
Date: Wed, 13 Jul 2016 13:00:28 -0700 [thread overview]
Message-ID: <CAO_EM_=9ON4vAxOCvUJ3Z+pic_An6wkriZrh4csZ_0DibHSQYQ@mail.gmail.com> (raw)
In-Reply-To: <20160713173613.GD19657@obsidianresearch.com>
On Wed, Jul 13, 2016 at 10:36 AM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> I think your bios is broken?
The BIOS is broken in many ways. I already have to pass
memmap=256M$0x80000000, otherwise PCIe extended config space
(MMCONFIG) is inaccessible. Also I found memmap=0x7000$0x7a7d0000
works around "APEI: Can not request [mem 0x7a7d0018-0x7a7d0067] for
APEI ERST registers", as the BIOS seems to be mistakenly reserving
0x7b7d0000-7b7d7000 instead.
> A working BIOS will look like this:
>
> $ cat /proc/iomem | grep -i fed400
> fed40000-fed44fff : pnp 00:00
>
> It sets aside the struct resource during pnp:
>
> [ 0.097318] pnp: PnP ACPI init
> [ 0.097366] system 00:00: [mem 0xfed40000-0xfed44fff] has been reserved
>
> What did your system do?
>
> You should see prints like this:
>
> printk(KERN_DEBUG
> "e820: reserve RAM buffer [mem %#010llx-%#010llx]\n",
> start, end);
>
> Which only happen if E820_RAM is set, which is certainly not right for
> TPM memory.
On my system I see
e820: reserve RAM buffer [mem 0x0009b000-0x0009ffff]
e820: reserve RAM buffer [mem 0x75b02000-0x77ffffff]
e820: reserve RAM buffer [mem 0x7a1f6000-0x7bffffff]
e820: reserve RAM buffer [mem 0x7b800000-0x7bffffff]
e820: reserve RAM buffer [mem 0xfed30000-0xffffffff]
e820: reserve RAM buffer [mem 0x505deb000-0x507ffffff]
which doesn't make a whole lot of sense, as several of those areas
overlap each other, never mind devices.
> I don't know what kernel convention is to handle these sorts of
> defects?
>
> Is the use of the memmap kernel command line an appropriate work
> around?
It works for me, though I would like to know if there's another approach.
--Ed
next prev parent reply other threads:[~2016-07-13 20:01 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 0:45 [PATCH v4 0/4] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-08 0:45 ` [PATCH v4 1/4] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-08 0:45 ` [PATCH v4 2/4] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-08 0:45 ` [PATCH v4 3/4] tpm: Allow TPM chip drivers to override reported " Ed Swierk
2016-06-08 19:05 ` [tpmdd-devel] " Jason Gunthorpe
2016-06-08 20:41 ` Ed Swierk
2016-06-08 0:45 ` [PATCH v4 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-08 23:00 ` [PATCH v5 0/4] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-08 23:00 ` [PATCH v5 1/4] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-08 23:00 ` [PATCH v5 2/4] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-08 23:00 ` [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported " Ed Swierk
2016-06-10 12:19 ` Jarkko Sakkinen
2016-06-10 17:34 ` Ed Swierk
2016-06-10 19:42 ` Jarkko Sakkinen
2016-06-11 1:54 ` Ed Swierk
2016-06-08 23:00 ` [PATCH v5 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-11 1:55 ` [PATCH v6 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-11 1:55 ` [PATCH v6 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-11 1:55 ` [PATCH v6 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-11 1:55 ` [PATCH v6 3/5] tpm: Factor out reading of timeout and duration capabilities Ed Swierk
2016-06-16 20:20 ` Jarkko Sakkinen
2016-06-19 12:12 ` Jarkko Sakkinen
2016-06-11 1:55 ` [PATCH v6 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-16 20:26 ` Jarkko Sakkinen
2016-06-11 1:55 ` [PATCH v6 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-21 1:53 ` [PATCH v7 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-21 1:53 ` [PATCH v7 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-21 1:53 ` [PATCH v7 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-21 1:54 ` [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-06-21 20:52 ` Jarkko Sakkinen
2016-06-22 0:21 ` Ed Swierk
2016-06-22 10:46 ` Jarkko Sakkinen
2016-06-21 1:54 ` [PATCH v7 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-21 20:54 ` Jarkko Sakkinen
2016-06-21 1:54 ` [PATCH v7 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-21 20:55 ` Jarkko Sakkinen
2016-06-22 1:10 ` [PATCH v8 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-22 1:10 ` [PATCH v8 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-24 18:25 ` Jason Gunthorpe
2016-06-24 20:21 ` Jarkko Sakkinen
2016-06-24 20:23 ` Jarkko Sakkinen
2016-06-24 20:26 ` Jason Gunthorpe
2016-06-25 15:24 ` Jarkko Sakkinen
2016-06-25 15:47 ` Jarkko Sakkinen
2016-06-27 17:55 ` Jason Gunthorpe
2016-06-22 1:10 ` [PATCH v8 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-24 18:27 ` Jason Gunthorpe
2016-06-24 20:24 ` Jarkko Sakkinen
2016-06-22 1:10 ` [PATCH v8 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-06-22 1:10 ` [PATCH v8 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-22 1:10 ` [PATCH v8 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-07-13 16:19 ` [PATCH v9 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-07-13 16:19 ` [PATCH v9 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-07-13 16:19 ` [PATCH v9 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-07-13 16:19 ` [PATCH v9 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-07-18 18:15 ` Jarkko Sakkinen
2016-07-18 18:19 ` Jarkko Sakkinen
2016-07-18 18:20 ` Jarkko Sakkinen
2016-07-13 16:19 ` [PATCH v9 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-07-13 17:04 ` kbuild test robot
2016-07-18 18:40 ` Jarkko Sakkinen
2016-07-13 16:19 ` [PATCH v9 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-07-13 16:44 ` [PATCH v9 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-07-13 17:36 ` Jason Gunthorpe
2016-07-13 20:00 ` Ed Swierk [this message]
2016-07-13 20:58 ` Eric W. Biederman
2016-07-13 20:59 ` Jason Gunthorpe
2016-07-18 18:07 ` Jarkko Sakkinen
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='CAO_EM_=9ON4vAxOCvUJ3Z+pic_An6wkriZrh4csZ_0DibHSQYQ@mail.gmail.com' \
--to=eswierk@skyportsystems.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=stefanb@us.ibm.com \
--cc=tpmdd-devel@lists.sourceforge.net \
/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).