From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932248AbaHYMxN (ORCPT ); Mon, 25 Aug 2014 08:53:13 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:34302 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755839AbaHYMxK (ORCPT ); Mon, 25 Aug 2014 08:53:10 -0400 Date: Mon, 25 Aug 2014 13:53:06 +0100 From: Matt Fleming To: Mantas =?utf-8?Q?Mikul=C4=97nas?= Cc: Harald Hoyer , Linux Kernel Mailing List , linux-efi@vger.kernel.org, Yinghai Lu , Matt Fleming , "H. Peter Anvin" Subject: Re: Loading initrd above 4G causes freeze on boot Message-ID: <20140825125306.GS29733@console-pimps.org> References: <53E62EEF.9040801@gmail.com> <53F752A2.7080604@redhat.com> <20140825105559.GQ29733@console-pimps.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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