On Fri, 2002-02-08 at 15:50, [EMAIL PROTECTED] wrote: > Jeremy Katz <[EMAIL PROTECTED]> wrote: > > > > Do this with the "uppermem" command, so instead of your entry looking > > > like the following: > > [snip] > > > ...so I *think* it would instead look like this: > > > > > > title Red Hat Linux (2.4.7-10smp) > > > uppermem 259072 > > > root (hd0,0) > > > kernel /boot/vmlinuz-2.4.7-10smp ro root=/dev/sda1 > > > initrd /boot/initrd-2.4.7-10smp.img > > > > You also still need to pass mem= on the kernel command line if you go > > this route. Having grub pass its detected memory to the kernel by > > default with a 2.4 kernel leads to problems due to not taking into > > account any holes which you may have in your memory layout, thus is > > disabled in the Red Hat Linux packages. > > What? OK, I'm confused. Do you mean, removed from the Red Hat Linux > *GRUB* package?
We run configure with --disable-auto-linux-mem-opt (as do most distros shipping 2.4 kernels from my looking through others' packages). > I looked at the Red Hat kernel source, and it seemed clear that the > kernel already handles this just fine. > > It parses the "mem=" option as just one memory region. I even tested > this out on one of my huge memory boards recently (from recent GRUB > CVS), and it worked perfectly fine, restricting one memory region > while allowing for the others. > > GRUB's "mem=" option it passes takes into account memory holes just > fine, but not putting anything above the first hole into there, which > is what the kernel source expects. > > Maybe I'm missing something here? >From what I understand from talking with our kernel folks, using mem= without passing along the complete e820 memory map info is not guaranteed to give proper memory information in all cases. Thus, passing mem= by default without an e820 map can cause problems. But, IANAKH (I am not a kernel hacker :) and instead just listen to what those who in theory know more about these things give me information :-) Cheers, Jeremy _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
