Messages in this thread | | | From | Ed Swierk <> | Date | Wed, 13 Jul 2016 13:00:28 -0700 | Subject | Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override |
| |
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
| |