lkml.org 
[lkml]   [2010]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch 1/1] x86 efi: Fill all reserved memmap entries if add_efi_memmap specified.
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


\
 
 \ /
  Last update: 2010-05-26 21:07    [W:0.059 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site