Bug 55046
Summary: | (SCSI AACRAID)Upgrading from 2.4.2 to 2.4.9-6 kernel causes SCSI boot errors and system crashing | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | David Bristol <dbristol> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 7.1 | CC: | jefferson.ogata, slberger |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-30 15:39:12 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Bristol
2001-10-24 20:18:24 UTC
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. Jefferson.Ogata: "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 exist ? 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 running system. 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 ------------------------- scsi3: percraid 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 Partition check: 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 persists. 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/ |