Description of problem:
When I try to append vmalloc=256m to my grub.conf I get a kernel panic
I use linux soft raid on two SATA drives and it fails to find md1 (my
/ partition) on system startup.
- Asus P4C800-E Deluxe motherboard;
- ICH5-R SATA controller;
- 2 Western Digital Raptor 74GB HDD.
Everytime on both SMP non-SMP kernel (2.6.10-1.766_FC3smp and
Steps to Reproduce:
1. append vmalloc=256m to boot parameters in grub.conf
I'm trying this following to this post:
this isnt going to work in the FC3 kernel. The devel tree has a reworking of the
vmalloc= code, but its not in 2.6.10
right now theres a 128M maximum.
The problem is not with the kernel as vmalloc does actually work in the kernels
supplied by fedora, it's with grub. The issue is that the version of grub
supplied by fedora doesn't honor the initrd_addr_max header of the boot
protocol, it assumes vmalloc will be exactly 128m. Therefore when a change to
vmalloc occurs it tries to load the initrd past safe memory space and fails to boot.
Downloading, compiling and installing grub 0.96 by hand solves the problem.
Perhaps compiling grub with --disable-auto-linux-mem-opt would solve? I took a
look at how gentoo builds it's grub (which doesn't have this problem) and that's
the only real option they pass. This is how I did it.
We already build with that option, and have since 0.95-1.
Then it must be a bug in 0.95 as building 0.96 vanilla solves.
I took the grub-0.95-12 SRPM from FC4-Test2 and built it into a grub-0.96
rpm for my FC3 box. I had to massage a few of the patches to work properly, but
once I did, I found that it *still* didn't work with the 'vmalloc=' kernel arg.
Turns out, one of the patches, 'grub-0.94-initrdmax.patch' seems to disable the
code that fixes the vmalloc/initrd issue. Now, since it's for x86_64
and I'm on a P4-M it doesn't hurt me to disable it, but I'm not sure how to fix
it properly. (I wonder if the FC 0.95 package would work without that patch...)
Would it at least be possible to make the patch apply only for x86_64 builds?
If anyone's interested I'll be happy to share my modded SRPM, but beware that I'm
only dimly aware of what I'm doing, so no promises that it won't eat your data.
Well, I just pulled down the SRPM for grub-0.95-3 from FC3, commented out patch
501 (grub-0.94-initrdmax.patch), rebuilt it, and it works with 'vmalloc'. So
it's not something you need 0.96 for, it'll work with the current package, once
that patch is removed.
Is it possible to selectively apply the patch, or mod it so its changes are only
active on x86_64 systems with 4G/4G?
Just before booting the kernel, grub prints a line like " [Linux-initrd @"
followed by some more text. What does this line say for you?
Chris, can you quote me that line with and without your change on a box that's
failing with vmalloc=256?
Sorry for the delay, I forgot to add myself to the CC: list.
On my D810 with grub-0.95-3, without the patch the line reads:
[Linux-initrd @ 0x37f74000, 0x7bdc9 bytes]
(and the kernel panics...) while with the patch I get:
[Linux-initrd @ 0x1ff74000, 0x7bdc9 bytes]
and the system boots properly.
(For those wondering how to see what grub outputs before the kernel
scrolls it away, just put 'pause' on a line by itself at the end of
your kernel declaration in grub.conf)
Chris, what does /proc/mtrr say on that box?
(and which parts of comment #8 did you get backwards? Before you were saying it
worked without the patch, now you're saying it works with...)
Sorry, in comment #8, when I say "with the patch" I mean "with my patched version,
which is really nothing but grub-0.95-3 with patch 501 removed." Just to be
With the original grub package (which includes patch 501) I get the error.
With my patched version (which does NOT include patch 501) everything works.
# cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0xfeda0000 (4077MB), size= 128KB: write-through, count=1
reg02: base=0xd0000000 (3328MB), size= 64MB: write-combining, count=1
(Which I don't believe is quite right, as I actually have 128M of video RAM, but
haven't mucked about with fixing that yet. But anyway, that's how the kernel
sets it up)
Although I haven't got a copy of the panic, I'm getting a panic on FC4
2.6.12-1.1398_FC4SMP kernel when trying vmalloc=256m as well.
My grub is 0.95-13.
gak, I just noticed this is an FC3 reported bug. Should I open another, or would
that make a dupe?
Fedora Core 3 is not maintained anymore.
Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release please reopen this bug and assign it to the corresponding