[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20131028102705.GI1982@console-pimps.org>
Date: Mon, 28 Oct 2013 10:27:05 +0000
From: Matt Fleming <matt@...sole-pimps.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Dave Young <dyoung@...hat.com>, linux-kernel@...r.kernel.org,
linux-efi@...r.kernel.org, x86@...nel.org, mjg59@...f.ucam.org,
hpa@...or.com, James.Bottomley@...senPartnership.com,
vgoyal@...hat.com, ebiederm@...ssion.com, horms@...ge.net.au,
kexec@...ts.fedoraproject.org, kexec@...ts.infradead.org
Subject: Re: [patch 2/6] x86 efi: reserve boot service fix
On Mon, 28 Oct, at 09:44:41AM, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 09:18:24AM +0800, Dave Young wrote:
> > There should be some people see below message with non-kexec kernel:
> > "Could not reserve boot range ..."
>
> I can find one other report like that: https://lkml.org/lkml/2013/7/16/309
>
> [ 0.000000] efi: Could not reserve boot range [0x0000000000-0x0000000fff]
>
> for
>
> efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)
>
> which is EFI_BOOT_SERVICES_CODE and
>
> efi: Could not reserve boot range [0x000005f000-0x000009ffff]
>
> for
>
> efi: mem06: type=3, attr=0xf, range=[0x000000000005f000-0x00000000000a0000) (0MB)
>
> which is of the same type.
But that doesn't look like the issue that the user was complaining
about. Rather, it's that the higher EFI regions are unable to be mapped
because of the user's mem= kernel parameter setting.
However, even though this bug isn't the main focus of the above report,
since people are hitting it (and since the fix is trivial), I agree it's
worth tagging for stable.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists