From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-22 i686)
Description of problem:
On a Dell Poweredge 2500, upgraded from the stock RH 7.1 with the 2.4.2
kernel to the 2.4.9-6 kernel using rpm -ivh. Verified that the initrd and
lilo changes had been made, recreated mkinitrd and reran lilo -v, but when
system rebooted, it came up with:
-blk:q iolimit=4095 mask 0xffffffff (not present in 2.4.2 or 2.4.3-12)
-(After starting xfs [OK]) AAC:RAID:aborting command due to time out:pid0
scsi3 id0 lun0 raid(10)... AACRAID:0 abort interrupt_status:0 (repeats with
various hex numbers, aborts, resets, and then hangs)
-System (if it boots) gives various segmentation fault errors in various
Loaded the 2.4.3-12 kernel and system encountered no errors.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install RedHat 7.1 on Dell Poweredge 2500
2.Upgrade to the 2.4.9-6 kernel
Actual Results: See description
Expected Results: System would boot up to new kernel and everything would
work as it did under previous kernels.
Similar behavior on a Dell PowerEdge 6450 with 4 cpus and 4GB RAM, SCSI raid 0+1
on PERC 3/DC.
Probing SCSI cards see multiple errors logged blk: I/O limit 4095. System gets
to pivotroot stage, reports error 19 on mounting root filesystem, pivotroot
fails, system hangs. No such problems, and no blk error messages with 2.4.3 or
2.4.2 kernels from Red Hat 7.1 install.
"blk: I/O limit 4095" is not an error just informative.
so did you 1) update the filesystem RPM package and 2) does a /initrd directory
Yes, the /initrd directory existed and filesystem was updated. This was not that
problem. All patches were applied. I searched Bugzilla thoroughly for anything
else related and nothing useful turned up (I did find the /initrd bugs and
verified that that was not my problem).
In addition, setting the Dell BIOS "OS Install Mode" feature made no difference
in boot behavior; this feature supposedly makes only 256MB available to the
My company was the one that reported this problem to Red Hat. We are now
working on a different Dell PowerEdge 2500 and have tried to install kernel
2.4.9-12 with the same results. We have had to remain on 2.4.2-2 from the 7.1
CDs. When we opened the call with Red Hat we were told there would be some
kind of fix within a week. That was over a month ago and there doesn't appear
to be much activity on this bug.
Could someone please address this and let me know when we might have a fix for
this problem? This bug is holding up the installation of Oracle 9i on our
servers as that product needs a newer kernel than comes on the 7.1 CDs.
We're finishing a rewrite of the aacraid driver (Adaptec is testing it in their
testlab now). Do you know who told you the "in a week"?
I see that kernel 2.4.9-21 includes a rewritten aacraid driver so I tried
installing it on a new Dell PowerEdge 4400 that I was setting up. After
booting I got a slew of errors similar to those from previous kernels. We
really need to be able to use a newer kernel with our Dell servers. Am I doing
something wrong or is this driver that badly broken? Here are the errors I
received during boot:
blk: queue f7792618, I/O limit 4095Mb (mask 0xffffffff)
Loading aacraid module
Red Hat/Adaptec aacraid driver, Jan 17 2002
----------- the next three lines were repeated three times ------------
PCI: found IRQ 11 for device 06:04.1
IRQ routing conflict for 06:04.1, have irq 10, want irq 11
IRQ routing conflict for 07:04.0, have irq 10, want irq 11
Vendor: DELL Model: PERCRAID RAID10 Rev: 0001
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi3, channel 0, id 0, lun 0
SCSI device sda: 284365824 512-byte hdwr sectors (145595 MB)
sda: Write Protect is off
sda: sda1 sda2 <sda5 sda6 sda7 sda8 sda9 sda10 sda11>
(the boot hangs at this point)
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/