Message-ID: <4BFD7206.9070203@sgi.com>
Date:	Wed, 26 May 2010 12:09:58 -0700
From:	Mike Travis <travis@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jens Axboe <jens.axboe@...cle.com>,
	Jack Steiner <steiner@....com>,
	LKML <linux-kernel@...r.kernel.org>, jkosina@...ell.com
Subject: Re: [Patch 1/1] x86 efi: Fill all reserved memmap entries if 	add_efi_memmap
 specified.



H. Peter Anvin wrote:
> On 05/26/2010 11:47 AM, Mike Travis wrote:
>> I didn't know bootloader had a problem two years ago  And as I mentioned,
>> I'm open to suggestions but what I've heard is "fix the bootloader". What
>> I don't know is how to do that.
>>
>> I see that BIOS sets up an e820 compatible memory map and extra memmap
>> entries "somewhere".  EFI seems to pick this up via ELILO and somehow
>> the kernel finds these extra memmap entries.
>>
>> So my question is what is broken?  Should the bootloader not use the
>> standard e820 memmap at all, and invent another way of passing the
>> memmap entries?  And what about EFI grub, shouldn't that also change?
>> And how does this affect compatibility?
>>
>> I'm in the dark here as to how the bootloader manages to pass these
>> entries from BIOS to the kernel, and how far I can go modifying these
>> things when I don't completely understand them.  The last problem I
>> worked on in ELILO I couldn't even print messages as that invalidated
>> the "magic key" and it would loop endlessly between ELILO and BIOS.
>>
>> The other thing is priorities.  If something is working and not
>> causing undue problems, it does not get higher priority than issues
>> that cause complete system failure.  I've suggested a workable
>> (maybe short term solution), that gets us past the boot, and on to
>> the other potentially far more important problems.
>>
>> And p.s. it's been way longer than two years... ;-)  [the other thing
>> to consider is we haven't had real hardware that long, and many, many,
>> many problems have surfaced since then.  The memmap problem only
>> showed up when we ran over 128 entries.  When has that happened before?
>> And how was it handled then?] 
>>
> 
> The 128-entry limit (caused by the fixed array in struct setup_info) was
> brought to our attention in 2007.  At that time, a number of
> alternatives were discussed; Linus in particular was adamant that this
> should be handled in the bootloader, and not by the kernel.
> 
> The result was that we added a facility to the kernel to supply
> arbitrary information via a linked list.  That has been in there since
> at least early 2008.  However, noone who cares about this issue has
> bothered stepping up and put the support into the bootloaders --
> instead, we got suckered into accepting a "temporary hack" which only
> has had the effect of giving you guys yet another excuse not to do what
> you signed off to do in the first place.
> 
> Accordingly, the right answer for me to do is to veto this and any
> further patches which enable you to skirt your responsibility, and I'm
> getting damned close to doing so.
> 
> 	-hpa


Ahh, so you aren't referring to me personally, but someone else?  I'll
do some digging into finding that mail thread to at least come up to
speed.  Had it been tossed to me in 2007 I would have dealt with it,
but it's on my todo list now.

Thanks,
Mike

--
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