Re: [edk2] Corrupted EFI region

From: jerry . hoemann
Date: Fri Sep 13 2013 - 16:38:49 EST


On Thu, Aug 08, 2013 at 11:17:30AM +0100, Matt Fleming wrote:
> > Is it possible to have a switch to turn off the not required behavior
> > (hiding EFI implementation bugs) so that bad platforms could be
> > detected? This would be a good thing to try on platforms at the
> > upcoming UEFI Plugfest hosted by the Linux Foundation and the UEFI
> > Forum, so the bad behavior can be detected and the vendors can fix the
> > issue.
>
> We don't tend to provide switches for the kernel to turn off workarounds
> because users run the risk of inadvertently stopping their machines from
> booting correctly. Also, because the major distributions will always
> enable the workarounds, the kernel would need to be built manually to
> see any kind of informative error message.
>

...

>
> > PS Also maybe it would be possible to key this work around behavior on
> > the EFI/UEFI version. So for example no work-around after UEFI v2.3.1?
>
> That would really depend on who has seen this bug and on which
> platforms. Is there a particular reason that mapping the boot services
> regions as-is would cause problems?
>

Matt,

We have hit an issue on our new platform in development related to the
call of efi_reserve_boot_services() from setup_arch().

The reservation can interfere with allocation of the crash kernel.

In pre 3.9(?) kernels, the crash kernel is required to be allocated from
physically contiguous memory below 896 MB.

Our new platforms are large in both the amount of memory and the amount
of IO. This requires large crash kernels for kdump to work. This is even
after the work done for makedumpfile v 1.5 to allow it to work with a
smaller foot print.


One of the problems is that drivers will allocate memory as boot code and/or
data in the region < 896 that effectively fragments this memory.
With the reservation, we can't reuse the memory when needed for the
crash kernels. If we remove the reservation and allow the kernel
to reuse the memory, we the reservation of the crash kernel succeeds.

This is definitely a problem for distros that are pre 3.9. Probably less
so for top of tree, but i haven't been focused there.

So we are definitely interested in finding a mechanism to not
do this reservation on platforms that don't have the issues described
earlier in this thread.

thanks,

Jerry

--

----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett-Packard

3404 E Harmony Rd. MS 57 phone: (970) 898-1022
Ft. Collins, CO 80528 FAX: (970) 898-XXXX
email: jerry.hoemann@xxxxxx
----------------------------------------------------------------------------

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/