From: Matt Fleming <matt@console-pimps.org>
To: "Mantas Mikulėnas" <grawity@gmail.com>
Cc: Harald Hoyer <harald@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-efi@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>,
Matt Fleming <matt.fleming@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Loading initrd above 4G causes freeze on boot
Date: Mon, 25 Aug 2014 13:53:06 +0100 [thread overview]
Message-ID: <20140825125306.GS29733@console-pimps.org> (raw)
In-Reply-To: <CAPWNY8V8D74CNXGhDwp2gpPpeV2F=Qao32i-0Mhq=9zhvDXLLw@mail.gmail.com>
On Mon, 25 Aug, at 02:08:59PM, Mantas Mikulėnas wrote:
>
> Well, all I could find is:
>
> > Freeing initrd memory: 5552K (ffff8800be22e000 - ffff8800be79a000)
>
> Attaching the entire log.
Here we go,
> [ 0.000000] RAMDISK: [mem 0xbe22e000-0xbe799fff]
OK, we're out of options here. Yinghai, we're going to have to revert
your patch, 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G")
We could conceivably add a boot parameter option to attempt loading
inirds above 4G, but we can't turn the feature on by default because of
all these buggy EFI implementations - things must work out of the box.
But the boot parameter would be useful for those people that a) know
their firmware isn't buggy and b) need to leave < 4G memory available
for use by other things. Yinghai, can you provide some justification for
your original commit? Do you have concrete use cases where loading
initrds above 4G is critical? How important is it that we enable this
functionality as opposed to reverting it?
It might also make sense to bump the default max initrd address
(hdr->initrd_addr_max) from 0x7fffffff to 0xffffffff at this point.
Peter, do you forsee any problem with this change?
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-08-25 12:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-09 14:23 Loading initrd above 4G causes freeze on boot Mantas Mikulėnas
2014-08-09 16:44 ` Yinghai Lu
2014-08-09 19:23 ` Matt Fleming
2014-08-09 22:45 ` Mantas Mikulėnas
2014-08-10 5:55 ` Yinghai Lu
2014-08-10 18:43 ` Mantas Mikulėnas
2014-08-13 14:02 ` Matt Fleming
2014-08-13 16:38 ` Mantas Mikulėnas
2014-08-13 18:44 ` Matt Fleming
2014-08-20 17:05 ` Matt Fleming
2014-08-20 19:05 ` Mantas Mikulėnas
2014-08-20 19:53 ` Michael Brown
2014-08-20 20:30 ` Matt Fleming
2014-08-21 20:23 ` [edk2] " Laszlo Ersek
2014-08-22 14:24 ` Harald Hoyer
2014-08-22 14:43 ` Mantas Mikulėnas
2014-08-24 19:19 ` Mantas Mikulėnas
2014-08-25 10:55 ` Matt Fleming
2014-08-25 11:08 ` Mantas Mikulėnas
2014-08-25 12:53 ` Matt Fleming [this message]
2014-08-25 18:22 ` Yinghai Lu
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=20140825125306.GS29733@console-pimps.org \
--to=matt@console-pimps.org \
--cc=grawity@gmail.com \
--cc=harald@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=yinghai@kernel.org \
/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