svn commit: r287934 - head/sys/boot/efi/loader

Edward Tomasz Napierała trasz at FreeBSD.org
Fri Oct 9 17:59:13 UTC 2015


On 0917T1630, John Baldwin wrote:
> On Thursday, September 17, 2015 10:30:15 PM Bjoern A. Zeeb wrote:
> > 
> > > On 17 Sep 2015, at 20:43 , John Baldwin <jhb at freebsd.org> wrote:
> > > 
> > > On Thursday, September 17, 2015 08:36:47 PM John Baldwin wrote:
> > >> Author: jhb
> > >> Date: Thu Sep 17 20:36:46 2015
> > >> New Revision: 287934
> > >> URL: https://svnweb.freebsd.org/changeset/base/287934
> > >> 
> > >> Log:
> > >>  The EFI boot loader allocates a single chunk of contiguous memory to
> > >>  hold the kernel, modules, and any other loaded data.  This memory block
> > >>  is relocated to the kernel's expected location during the transfer of
> > >>  control from the loader to the kernel.
> > >> 
> > >>  The GENERIC kernel on amd64 has recently grown such that a kernel + zfs.ko
> > >>  no longer fits in the default staging size.  Bump the default size from
> > >>  32MB to 48MB to provide more breathing room.
> > > 
> > > I believe that this should work fine for any system with 64MB of RAM.  One
> > > downside of the static size is that the loader fails if it can't allocate
> > > a contiguous staging size (it isn't able to grow the staging area on
> > > demand).
> > 
> > how do md_images work in that case?
> 
> The md_image has to fit into the same staging area (kernel plus any other
> files loaded by the loader including modules and md_images all have to fit
> in the staging area).  That was the original motivation for making the
> staging area a build-time tunable rather than always hardcoded at 32MB so
> that people who wished to deploy a large md_image can use a make flag to
> build a loader with a larger staging size (I tested this with a 200+MB
> mfsroot).

What would be required to get rid of that limitation altogether, ie make
it dynamic?  Right now it's quite a regression compared to the usual
(non-UEFI) loader.



More information about the svn-src-head mailing list