x86 efi: Fill all reserved memmap entries if add_efi_memmap specified.
in [Kernel]
|
Prev: [PATCH 04/11] Fix find_unbound_irq in presence of ioapic irqs.
Next: dynamic_debug: allow to set dynamic debug flags right at module load time
From: H. Peter Anvin on 26 May 2010 14:30 On 05/26/2010 10:42 AM, Mike Travis wrote: > > I'm open for suggestions on how to improve this, but we are shipping > systems very soon and I don't think we'll get any other change into > the system until the next update. > You know you've been using that excuse for two years when it comes to not fixing the bootloader, and I'm starting to be a bit frustrated with that. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Travis on 26 May 2010 14:50 H. Peter Anvin wrote: > On 05/26/2010 10:42 AM, Mike Travis wrote: >> I'm open for suggestions on how to improve this, but we are shipping >> systems very soon and I don't think we'll get any other change into >> the system until the next update. >> > > You know you've been using that excuse for two years when it comes to > not fixing the bootloader, and I'm starting to be a bit frustrated with > that. > > -hpa 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?] Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 26 May 2010 15:10 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Travis on 26 May 2010 15:20 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 26 May 2010 16:20
On 05/26/2010 12:09 PM, Mike Travis wrote: > > 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. > I'm referring to the collective you as in "the community of large-machine producers". -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |