From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Ed Swierk <eswierk@skyportsystems.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 14:59:28 -0600 [thread overview]
Message-ID: <20160713205928.GA28234@obsidianresearch.com> (raw)
In-Reply-To: <CAO_EM_=9ON4vAxOCvUJ3Z+pic_An6wkriZrh4csZ_0DibHSQYQ@mail.gmail.com>
On Wed, Jul 13, 2016 at 01:00:28PM -0700, Ed Swierk wrote:
> 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.
Is it is possible whatever causes the 'reserve RAM buffer' behavior in
the kernel is wonky with your BIOS? That seems to be a special Linux
action..
Could it be Xen related? The Xen hypervisor replaces the physical ram
map for the dom0 guest, which is why you get these sorts of prints:
Xen: [mem 0x0000000000000000-0x000000000005ffff] usable
and not:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable
Jason
next prev parent reply other threads:[~2016-07-13 20:59 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
2016-07-13 20:58 ` Eric W. Biederman
2016-07-13 20:59 ` Jason Gunthorpe [this message]
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=20160713205928.GA28234@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=eswierk@skyportsystems.com \
--cc=jarkko.sakkinen@linux.intel.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).