Description of problem:
Systems are Dell PowerEdge 2650 with PERC 3/Di (aacraid) doing RAID5 and dual
2.4 Xeon with HyperThreading. 3 identical PE2650's all exhibit this problem.
After loading down each logical CPU with a process (eg. setiathome) the aacraid
SCSI device will eventually reset and cause a kernel panic. Note that there is
no significant disk load required to reproduce. Seeing as how it is
reproducible on 3 machines on RAID5, it is not likely related to defective
disks even though it appears that way.
Version-Release number of selected component (if applicable):
From a fresh 7.3 installed on reiserfs, try running multiple setiathome
processes (1 per logical CPU). Come back in a few hours (overnight?).
Steps to Reproduce:
1. Basic install of Red Hat 7.3, upgrade and boot kernel-2.4.18-27.7.xsmp
(i686). Also upgraded to glibc-2.2.5-43 (i686), but nothing else installed or
changed other than that. Filesystems are reiserfs. (/dev/sda1
= /boot, /dev/sda2 = /, /dev/sda3 = /usr, /dev/sda4 = not mounted yet).
2. Put load on each logical CPU (eg. setiathome).
3. Come back later (duration undetermined however overnight seems to be long
enough). Machine will be frozen. Have been able to reproduce this several
aacraid: Host adapter reset request. SCSI hang ?
SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 6000000
kernel BUG at prints.c:344!
invalid operand: 0000
EIP is at reiserfs_panic .....
[ See attachments ]
No process should be able to reliably panic the kernel. Also expect file
system to be intact or at least repairable on reboot.
Attached are screen captures of the kernel panic message taken from the remote
console. 2 machines are represented here and JPG's are numbered in order. dev
08:02 is the root filesystem, where the setiathome process is running from.
BIOS and firmware are updated to newest (A10 and PERC 3/Di = 2.7-1). Also is
important to note that one particular time this happened the filesystems became
corrupted beyond repair. That particular time I was using LVM in /dev/sda4 and
that volume became unusable (would segfault vgscan), not to mention
that /dev/sda2 was unrecoverable by reiserfsck.
Created attachment 91366 [details]
Kernel panic (page 1)
Created attachment 91367 [details]
Kernel panic (page 2)
Created attachment 91368 [details]
Kernel panic (page 3)
Created attachment 91369 [details]
Kernel panic (page 4)
This completes the first 4 pages from the first kernel panic. I have captures
from the other machine but they're pretty close to the same thing. Available
on request. Sorry for the multiple JPG attachments, this was the only way to
retrieve the kernel panic from the machine in this state.
Jpegs are fine. Currently testing newer aacraid drivers with adaptec
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/