Description of problem:
I'm setting up Red Hat Linux 8.0 on a Dell PowerEdge 2650. The PE has 3 disks
on a AIC7XXX controller. The first disk is the system disk; it's not using RAID
in any form. I want create a software RAID mirror using the second and third
disks and mount it on /data.
Figuring out how to create the mirror was easy enough. But since this was my
first experience with Linux software RAID, I wanted to play around with it
before I tossed the box into production. So I've spent the last week doing
things like simulating failures, performing replacements and rebuilds, etc.
I'm up-to-date with the latest errata packages. Nonetheless, I've found the
Linux software RAID to be disturbingly brittle. I've managed to make it Oops at
3 times so far, and I'm not even trying particularly hard.
Are there known problems with software RAID in kernel-2.4.18-19.8.0 on RH8? If
so, are there any work-arounds you can suggest?
Version-Release number of selected component (if applicable):
Created attachment 89615 [details]
This is the ksymoops report for the latest Oops I generated.
(I'm not sure what the reason is for the "cannot stat" errors. If you can tell
me how to correct that, I'll re-generate the report.)
Ok, a little more information.
The oops is related to triggering recovery processes. For example, the
following command (which simulates a failure and replacement) frequently causes
$ mdadm /dev/md0 -f /dev/sdc1 -r /dev/sdc1 -a /dev/sdc1
(I can cause oopses to occur with the raidtools commands as well.)
I generated two more oops reports this afternoon; I'll attach them in a moment.
Created attachment 89627 [details]
Created attachment 89628 [details]
Uhhh... the previous oops report isn't a patch, obviously. Oops. :p
Ok, from pondering the 3 oops I've made so far, they're all clearly the same
problem, so I won't bother to attach any more oops. (Unless I can get an oops
in a different location, that is.)
I've updated the summary of this bug to more accurately reflect the problem.
I've skimmed through /usr/src/linux-2.4.18-19.8.0/drivers/md/md.c, but alas, I
have little kernel hacking experience; whatever the bug, it isn't immediately
apparent to me.
I'm no stranger to building customized Red Hat kernels. If this oops is a known
bug, and there's a patch, smack it in here and I'll go build my own kernel and
In the meantime, I'll compare md.c from 2.4.18-19.8.0 again Phoebe's kernel, and
against vanilla 2.4.20. Perhaps something will leap out from the diffs...
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/