Bug 149092 - Kernel panic when using vmalloc=256m in grub.conf
Summary: Kernel panic when using vmalloc=256m in grub.conf
Alias: None
Product: Fedora
Classification: Fedora
Component: grub   
(Show other bugs)
Version: 3
Hardware: i686 Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-18 16:57 UTC by Gabriel Labelle
Modified: 2008-02-06 23:43 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-06 23:43:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Gabriel Labelle 2005-02-18 16:57:03 UTC
Description of problem:

When I try to append vmalloc=256m to my grub.conf I get a kernel panic
on reboot.

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.

How reproducible:

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
2. reboot
Actual results:

Kernel panic

Expected results:

Boot normally

Additional info:

I'm trying this following to this post:

Comment 1 Dave Jones 2005-02-24 04:18:23 UTC
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.

Comment 2 Warren Chartier 2005-03-15 01:55:51 UTC
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.

Comment 3 Peter Jones 2005-03-15 15:08:07 UTC
We already build with that option, and have since 0.95-1.

Comment 4 Warren Chartier 2005-03-15 15:51:53 UTC
Then it must be a bug in 0.95 as building 0.96 vanilla solves.

Comment 5 Chris Tracy 2005-04-13 20:12:41 UTC
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.

Comment 6 Chris Tracy 2005-04-13 20:22:06 UTC
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?

Comment 7 Peter Jones 2005-04-14 15:36:03 UTC
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?

Comment 8 Chris Tracy 2005-04-17 00:03:09 UTC
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)

Comment 9 Peter Jones 2005-04-19 16:06:33 UTC
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...)

Comment 10 Chris Tracy 2005-04-19 16:15:09 UTC
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)

Comment 11 Peter Lawler 2005-07-19 00:41:45 UTC
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.

Comment 12 Peter Lawler 2005-07-19 00:43:11 UTC
gak, I just noticed this is an FC3 reported bug. Should I open another, or would
that make a dupe?

Comment 13 petrosyan 2008-02-06 23:43:34 UTC
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
Fedora version.

Note You need to log in before you can comment on or make changes to this bug.