Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 62496 - Promise 20267 Raid Controller not seen/used
Promise 20267 Raid Controller not seen/used
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-04-01 15:07 EST by Troy Dawson
Modified: 2007-04-18 12:41 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-27 18:33:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
errors from doing a modprobe pdcraid (396 bytes, text/plain)
2002-04-01 17:52 EST, Troy Dawson
no flags Details
dmesg of bootable machine (unedited) (10.67 KB, text/plain)
2002-04-01 17:55 EST, Troy Dawson
no flags Details

  None (edit)
Description Troy Dawson 2002-04-01 15:07:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205

Description of problem:
I have several machines with a built in Promise Raid controller
Promise Technology, Inc. 20267 (rev 02)
On the machines where all of the drives are on the controller (Raid 1) the
installer doesn't see any disks (even with a driver disk, and/or expert mode)
On a machine that has a drive on the normal ide controller, the install goes
fine on that one drive, but even after an install, the drives on the raid
controller are never seen.  But the controller is seen (by doing a lspci)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Put all hard drives on a Promise Technology 20267 Raid Card
2.Make all drives a raid 1 (I believe any type of raid would do)
3.Try to do an install

Actual Results:  The installer said that I had no drives to install to

Expected Results:  It should have just used the drives like normal drives

Additional info:

These machines work fine under RedHat 7.1, with the 2.4.3 kernel (and the
standard one as well)
Comment 1 Arjan van de Ven 2002-04-01 15:46:24 EST
I assume you've already tried the pdcraid driver.
could you attach the dmesg of a machine booting but not seeing it ?
(preferably one where you modprobe pdcraid)
Comment 2 Troy Dawson 2002-04-01 17:52:51 EST
Created attachment 51704 [details]
errors from doing a modprobe pdcraid
Comment 3 Troy Dawson 2002-04-01 17:54:48 EST
Yes, I had tried the pdcraid driver, but always without success.
I am attaching both /var/log/dmesg from the machine that boots, and the error
output I get when I try a modprobe pdcraid.  I don't have anything in the
/etc/modules.conf relating to the pdcraid, so something there might be needed,
but all of my searching hasn't brought up anything.
Comment 4 Troy Dawson 2002-04-01 17:55:48 EST
Created attachment 51705 [details]
dmesg of bootable machine (unedited)
Comment 5 Alan Cox 2002-04-02 16:25:39 EST
Arjan - I thought our pdcraid driver still only supported raid0 ?
Comment 6 Troy Dawson 2002-04-02 17:26:09 EST
I am sorry, this was a Raid 0 (striping).  I always get the two mixed up.  But
since said that, I went and tried all of the different settings that were
available, on the machine that two disks on the normal ide, and two on the raid
I tried Stripping-all disks, Stripping-each disk it's own stripe, Spanning-all
disks, Spanning-each disk it's own span, Mirroring, No raid arrays at all, and
turned the thing off in the bios.  
All of them (except turning it off in the bios) showed the same results in the
dmesg, /proc/partitions, and modprobe pdcraid.  Turning it off, and then I
didn't even get anything in the dmesg or lspci.

Comment 7 Troy Dawson 2002-04-02 17:31:08 EST
I don't know if this will help, but here is the snippit from dmesg from the
2.4.18 kernel (from skipjack) and from the 2.4.3-12 kernel

PDC20267: IDE controller on PCI bus 00 dev 18
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
PDC20267: ROM enabled at 0xfeae0000
PDC20267: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
PDC20267: neither IDE port enabled (BIOS)

PDC20267: IDE controller on PCI bus 00 dev 18
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
PDC20267: ROM enabled at 0xfeae0000
PDC20267: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
    ide0: BM-DMA at 0xdf00-0xdf07, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xdf08-0xdf0f, BIOS settings: hdc:pio, hdd:pio

I don't know if that will help at all, but it might.
Comment 8 Troy Dawson 2002-04-09 10:42:29 EDT
Is there a web page, or someplace I can look to see what parameters to put in
modules.conf, or pass in lilo (I currently don't know how to pass parameters in
grub) to make this work where I have it half and half.  I've done plenty of
searches but all I get is either old pages (dealing with 2.2 or 2.4.2) or very
indepth discussions about the code in the kernel.  I am not finding anything in
Comment 9 Troy Dawson 2002-04-15 12:55:56 EDT
It is working now with Skipjack Beta2 for the system with half the drives on,
and half off.  It still doesn't see the drives during install, and I don't see
the ataraid or pdcraid during install.  But after install I can now load those
modules and it let's me use the drives.  So one part of the problem is working now.
Comment 10 Alan Cox 2003-06-05 13:45:26 EDT
PDC raid drive detect was problematic in some older kernels. Its fine in current
ones. The trace shows a kernel which didnt have the needed PDC options. 

If this is still a problem with current kernels please re-open
Comment 11 Troy Dawson 2003-06-28 08:55:56 EDT
I am sorry for not responding, I should have responded a while ago.
Yes, It is working now with the latest errata kernels.  
I'm not positive exactly which one started working correctly with it, but I know
the one I started using was the 2.4.18-9.  
I have put RedHat 9 on the machines and they work perfectly, with it's standard
kernel as well as the latest errata kernel 2.4.20-18.

Note You need to log in before you can comment on or make changes to this bug.