Red Hat Bugzilla – Bug 197536
"trap divide error" x86_64 on kernel 2.6.17 with FC5
Last modified: 2007-11-30 17:11:36 EST
Description of problem:
I have a Tyan Transport GX28 (B2881) (
http://www.tyan.com/products/html/gx28b2881.html ) system with 2 dual core
opteron 285 processors and 4gb of ecc ram. (2 1gb chips on each proc)
I recently got the kernel-2.6.17-1.2139_FC5.x86_64.rpm kernel via yum update.
When I boot with this updated kernel, (as closely as I can tell) right after
the boot process has detected the disks, I see scrolling by as quickly as
init trap divide error rip:4296d7 rsp:7fff91edd2b0 error:0
as far as I can tell, this error line never changes, it just keeps scrolling as
quickly as possible.
Version-Release number of selected component (if applicable):
Stops system every boot.
Steps to Reproduce:
1. On a dual opteron server, running fc5, yum update and reboot
Error scrolls by
I did a google on the web for init trap divide error rip:4296d7
It looks like I dont have the only machine with this problem:
This post has someone receiving a very similar error running 2.6.17 on a dual
This similar post appears to be from the linux kernel archive, from someone
running FC5, x86_64, and trying to run the 2.6.17 kernel
If it's related to the disks, I'm using the on board SATA raid in a raid 1
mirror of 2 10krpm drives.
I'll be happy to provide any additional information you may need to diagnose
this issue, just let me know.
Thanks for your help,
Also, the box boots fine with 2.6.16 2111
Its fakeraid, and is isolated to Fedora.
edit init to comment out the line starting with "dm partadd",
put it back together.
Then use fakeraid the old way.
If you're booting off the fakeraid, this probably won't work.
I just want to confirm by by fakeraid, you mean the onboard sata raid.
If you mean linux software raid, I'm not using the software raid.
Yes, unfortunately in this case I'm booting from it.
Confirmed. Called fakeraid because those onboard raid cards are marketed as
"hardware raid", but there is no hardware involved. They're just regular
controllers with a bios tag that will enable their software raid drivers (for
winsucks). Additionally, they tag the DRIVES to identify the type of raid that
they are. You can actually take the fakeraid array and plug them into a regular
(non-RAID) controller, and dmraid will still work for them.
I'm seing this too (with 2.6.17-1.2145_FC5).
Also a problem for me with 2.6.17-1.2157_FC5.
Tried 2.6.17-1.2159_FC5 from testing repo. This one produces the same error.
Also no luck with kernel-2.6.17-1.2174_FC5
Exact same error for me on a dell e510: x86_64 (dual core, intel pentium 4),
fc5, dual SATA drives (hardware mirrored).
The last kernel I could boot to without this (and still boot to) is
*** Bug 203016 has been marked as a duplicate of this bug. ***
This seems like a pretty high-impact bug that's been around for a while now.
Are there any plans to address it in a FC5 errata?
(and I amend my comment #10 to say it sounds like fakeraid on my end.)
Tried kernel-2.6.17-1.2187_FC5 with the same results.
Does nobody care about this bug? Is it ever going to be fixed?
I had reported a similar (or same) problem in bug 203016.
I retested with 2.6.17-1.2187_FC5, and my machine now boots up ok, problem is
fixed for me.
In reply to comment #13, yes, we do care, and it ought to get fixed at some
point, but unfortunately, there are a lot more bugs than there are devs to look
Per comment #14, I'm not sure why one system works now and the other doesn't. My
only suspicion would be that its actually mkinitrd that is somehow at fault, and
the two systems aren't (or weren't at initrd creation time) running the same
version of mkinitrd. Can folks report back with their mkinitrd versions?
Keith, if you could, also try rebuilding your mkinitrd to eliminate the
possibility of the kernel being updated before mkinitrd, and/or try again after
upgrading mkinitrd, if an update is available. You might also want to try the
development tree version... Mostly just shooting in the dark here, but hoping to
hit something. :)
[root@kaiefast ~]# rpm -qi mkinitrd
Name : mkinitrd Relocations: (not relocatable)
Version : 5.0.32 Vendor: Red Hat, Inc.
Release : 2 Build Date: Wed 30 Aug 2006 09:06:55
Install Date: Tue 12 Sep 2006 03:28:43 PM CEST Build Host:
[root@kaiefast ~]# uname -a
Linux kaiefast 2.6.17-1.2187_FC5 #1 SMP Mon Sep 11 01:16:59 EDT 2006 x86_64
x86_64 x86_64 GNU/Linux
[root@kaiefast ~]# egrep -i "kernel|initrd" /var/log/yum.log
Sep 12 15:28:44 Updated: mkinitrd.x86_64 5.0.32-2
Sep 16 03:34:38 Installed: kernel.x86_64 2.6.17-1.2187_FC5
Jarod, it seems that you did hit something. You must have extra special night
I upgraded mkinitrd to 5.0.32-2 (I was at 5.0.32-1) and recreated the image with
that one. My machine boots up OK now. Hooray and thanks.
Go, go, magic night-vision goggles... Glad to hear that did the trick! :)
I'll twiddle the bug a bit -- reassign it to mkinitrd and close as
CURRENTRELEASE = 5.0.32-2.