Red Hat Bugzilla – Bug 229913
kernel immediately gets 'Bad RIP Value' with memory remap, Asus P5B 4GB Core 2
Last modified: 2008-04-04 02:58:36 EDT
Description of problem:
System installed and runs fine with the BIOS memory remap option disabled.
Running 2.6.19-1.2911.fc6 kernel and latest BIOS version (1004). Shows 3GB of
memory, but that's expected.
When I enable memory remap, it immediately gets a stack trace when the OS starts
the boot. I'm sorry, but I don't know how to capture the stack trace
information to provide it, if it's important, I will find out and do so.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Change BIOS to enable memory remap
Boot immediately fails.
Should boot and use 4GB of memory.
Could this be related to:
You can capture the stack trace by taking a picture of the screen with a digital
camera and attaching that to this bugzilla entry.
Also, please try booting with the kernel option "iommu=soft".
I have the same problem.
I tried the kernel option "iommu=soft" and no luck.
There is a fix for IOMMU-caused kernel panics in
kernel-2.6.19-1.2911.6.3.fc6 in testing, available at:
I don't know if it fixes the problem, but it might.
I have just tried the testing kernel kernel-2.6.19-1.2911.6.3.fc6 and no luck.
As far as I read in some forums this could be a kernel problem or a kernel+BIOS
Created attachment 148747 [details]
Shot of boot failure
This happened with this kernel: kernel-2.6.19-1.2911.6.3.fc6, with the
iommu=soft option specified.
Let me know if you need more information or if you want me to try anything
The interesting part of the oops has scrolled off the screen.
Try booting with kernel option "vga=1" to get 50-line mode.
And turn off the camera's flash so we can see the center of the screen.
Created attachment 148834 [details]
first shot of failure (one angle)
Created attachment 148835 [details]
first shot of failure (another angle)
Created attachment 148837 [details]
second page of stack trace
I have 3 attachments, the ones labeled "first shot" are the initial boot screen
of where is froze.
The one labeled "second page" happened in a previous boot (where I did not have
my camera ready). In this boot, a page similar to the "first shot" above
appeared, and then maybe 30 seconds later this additional stack trace appeared.
Both boots were identical everything, and with the kernel, options and h/w
described by me the most recent comments.
Just updated to the 2.6.19-1.2911.6.5.fc6 kernel and the problem persists.
Let me know if you would like me to capture the stack trace from the boot with
the new kernel.
*** Bug 230985 has been marked as a duplicate of this bug. ***
Should I file this as a bug report for kernel.org, since it seems like several
people are hitting this problem?
Having the same problem with all versions of the FC6 kernel: regular, PAE and
64-bit. I was able to boot Ubuntu 6.10 without any problems. I have not
determined what the differences are that make one work and the other fail.
Updated to kernel-2.6.19-1.2911.6.5.fc6 and the problem persists.
Sorry for my last comment!
I have updated to kernel-2.6.20-1.2925.fc6 and the problem persists
XEN version of kernel does not have this bug ?
$ dmesg | head -4
Linux version 2.6.19-1.2911.6.5.fc6xen (firstname.lastname@example.org) (gcc version
4.1.1 20070105 (Red Hat 4.1.1-51
)) #1 SMP Sun Mar 4 16:23:59 EST 2007
Command line: ro root=LABEL=ROOT video=ywrap vga=0x315
BIOS-provided physical RAM map:
Xen: 0000000000000000 - 00000000f2f86000 (usable)
$ head -1 /proc/meminfo
MemTotal: 3971352 kB
The XEN kernel as in comment 16 works fine for me as well.
Upgraded to kernel-2.6.20-1.2944.fc6 and kernel-PAE-2.6.20-1.2944.fc6.
With the memory remapping enabled:
kernel-2.6.20-1.2944.fc6 boots but only sees 2 of the 4 gig with a message to
use the PAE kernel to access the full 4 gigs. It used to kernel panic before.
kernel-PAE-2.6.20-1.2944.fc6 still kernel panics on boot up.
Have not tried the 64-bit kernel.
64-bit kernels - kernel-2.6.20-1.2944.fc6 hangs with same diagnostics
different memmap= options does not solve problem
XEN vesion of kernel boots perfectly
Could someone upload screen pictures of failure with kernel 2944?
I looked at upgrading to 4gb on my P5B-Deluxe board. I found this bug and
reconsidered. But this morning I found a forum post about Ubuntu and this same
issue. Someone had found blacklisting the Intel AGP driver fixed the issue. From
what it said it sounded like Ubuntu has the AGP drivers as modules, and hence
they can be prevented from loading. Where as it seems Fedora compiles them in.
I purchased the additional 2gb of ram and installed. Then I tried disabling the
AGP drivers in the configuration of a 2.6.20-1.2944 x86_64 kernel and
recompiled. The resulting rpm had a config with AGP enabled, but the Intel AGP
driver as a module. I then moved the module file out of the /lib/modules
directory and booted the kernel. It did successfully boot.
I then had an issue with the kernel missing the dist tag and recompiled again
with it. This time I forget to move the Intel AGP driver module out of
/lib/modules and that resulted a system reboot around the starting of udev.
My next goal is to recompile with all the AGP drivers as modules, and then
blacklist the Intel AGP driver. I will then reenable the remap option in the
bios, make sure it boots, and then check that everything else works.
As a side note, linux did seem to see all the memory, but I didn't have alot of
time to look it over.
Casn you boot stock kernel 2944 and repost the screen pictures?
I don't have debug info for the older kernels installed.
Yes, I can try later. Hopefully it doesn't just reboot like it seems to do with
the driver as a module.
I have included the kernel option agp=off and I have successfully boot with my
Ah, very nice a straight forward. What video card and driver to do you use? I am
curious if there are any side effects to disabling AGP.
I am using a NVidia 7600GT PCIe 256Mb and livna nvidia driver (nvidia-1.0.9755-4).
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GT] (rev a1)
I have just tested the agp=off kernel option. Until now I haven't found any side
effects with my video card. Actually I am using Gnome and Beryl and no problems.
If I have any problem using this options I will post here.
Additional info: I am using kernel kernel-2.6.20-1.2944.fc6.x86-64 (fc6)
[root@phantom ~]# cat /proc/meminfo
MemTotal: 4017504 kB
That is great news. I have the exact same card, and I am using the same exact
Your memory total seems to match what I saw while I had it working earlier.
Here is the url of someone who talks about some of the details of the bug:
I flashed by my bios and bricked my motherboard. Ended up getting a P5B Premium
this time. It is basically the same board, but has it's own version of the bios.
It seems to have the same issue and the same fix works.
I am only getting 4017404kb. Which is interestingly 100kb less than Hugo. It is
roughly 3.8gb. Which is 174mb, which is mentioned during boot as reserved.
Memory: 4015460k/6291456k available (2454k kernel code, 177876k reserved, 1459k
data, 316k init)
Created attachment 153431 [details]
The first image of screen from the oops of 2.6.20-1.2944
Created attachment 153432 [details]
The second image of screen from the oops of 2.6.20-1.2944
Just an FYI but adding agp=off fixes this for my Asus P5B-E and Asus P5B Deluxe
Works for me too with 'agp=off' and P5B Deluxe. (4GB with
Should be fixed in kernel 1.2952
Does not appear to be fixed in kernel-PAE-2.6.20-1.2952.fc6. Still
requires 'agp=off' to boot.
Enterprise kernel-2.6.18-8.1.15.el5 have same bug (and same solving)
But new kernel 2.6.18-53.1.4.el5 works without agp=off !!! That's just fine!
That's what we want!
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This has been fixed:
22.214.171.124-50.fc8 (probably before)
MemTotal: 4064604 kB