Promise PDC20276 array nonexistant?

[oDii]

I'm having a little trouble with my old GA-7VAXP motherboard, its RAID controller and Debian (2.6.18-4-k7). I've created a RAID0 array (they're old disks that aren't going to store anything important) and while Debian can correctly detect the individual drives in the array, it doesn't detect the array itself. Here is the relevant stuff from dmesg:

Code: Select all

PDC20276: IDE controller at PCI slot 0000:00:0f.0
ACPI: PCI Interrupt 0000:00:0f.0[A] -> GSI 19 (level, low) -> IRQ 177
PDC20276: chipset revision 1
PDC20276: 100% native mode on irq 177
    ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
8139too Fast Ethernet driver 0.9.27
Probing IDE interface ide3...
hdg: ST340016A, ATA DISK drive
hdh: WDC WD400EB-00CPF0, ATA DISK drive
ide3 at 0xcc00-0xcc07,0xd002 on irq 177
VP_IDE: IDE controller at PCI slot 0000:00:11.1
ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:11.1[A] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 185
PCI: VIA IRQ fixup for 0000:00:11.1, from 255 to 9
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1
    ide0: BM-DMA at 0xe400-0xe407, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xe408-0xe40f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hdg: max request size: 128KiB
hdg: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdg: cache flushes not supported
 hdg: unknown partition table
hdh: max request size: 128KiB
hdh: Host Protected Area detected.
        current capacity is 78163247 sectors (40019 MB)
        native  capacity is 78165360 sectors (40020 MB)
hdh: Host Protected Area disabled.
hdh: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdh: cache flushes not supported
 hdh: unknown partition table
hda: WDC WD800BB-60JKA0, ATA DISK drive
hdb: ST3120023A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: Host Protected Area detected.
        current capacity is 156299375 sectors (80025 MB)
        native  capacity is 156301488 sectors (80026 MB)
hda: Host Protected Area disabled.
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 >
hdb: max request size: 128KiB
hdb: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdb: cache flushes supported
 hdb: hdb1
Probing IDE interface ide1...
hdc: SAMSUNG DVD-ROM SD-616Q, ATAPI CD/DVD-ROM drive

and lsmod:

Code: Select all

Module                  Size  Used by
vmnet                  28588  10
parport_pc             32612  0
parport                33672  1 parport_pc
vmmon                 167180  0
button                  6928  0
ac                      5508  0
battery                 9924  0
ipv6                  228064  12
dm_snapshot            15904  0
dm_mirror              19600  0
dm_mod                 50776  2 dm_snapshot,dm_mirror
loop                   15496  0
via_ircc               23956  0
irda                  163580  1 via_ircc
crc_ccitt               2560  1 irda
rtc                    12788  0
i2c_viapro              8596  0
serio_raw               6980  0
floppy                 53668  0
i2c_core               20096  1 i2c_viapro
psmouse                35336  0
shpchp                 33312  0
pci_hotplug            29056  1 shpchp
via_agp                 9984  1
agpgart                30216  1 via_agp
pcspkr                  3392  0
evdev                   9408  0
ext3                  120584  7
jbd                    52968  1 ext3
mbcache                 8644  1 ext3
ide_cd                 36576  0
cdrom                  33056  1 ide_cd
8139cp                 22336  0
generic                 5764  0 [permanent]
ide_disk               15168  10
8139too                25600  0
mii                     5696  2 8139cp,8139too
via82cxxx               8708  0 [permanent]
pdc202xx_new            8256  0 [permanent]
ide_core              110984  5 ide_cd,generic,ide_disk,via82cxxx,pdc202xx_new
skge                   35152  0
thermal                13896  0
processor              29128  1 thermal
fan                     5124  0

Does anyone have any suggestions as to how I can get the array to work correctly? All other tools (Partition Magic etc.) I've tried correctly detect a single array of 80GB. Also, go easy on me please , I'm still new Debian...

[oDii]

My apologies, I forgot to add the following:

• My RAID Controller is the "Promise PDC20276.
• The RAID is configured in the RAID BIOS and is not software RAID.
• I haven't installed any drivers - what you see above is simply what happened when I enabled the RAID controller and booted Debian (ie. the module used is possibly out of date, but I'm unsure of how to check/do anything about it).

Many thanks.

[Guest]

It's likely that the card is running fake RAID - where the RAID logic itself is handled by the card's drivers and not by the card's own hardware or software explicitly. This means that the linux module itself has to run the RAID independently of other tools (such as mdadm or the card's onboard hardware). The net result is that debian recognises the controller and the block devices attached to it, but it does not have support for the RAID components themselves.

This was the case with my Promise SX4 M S150 SATA controller (drives were detected and were usable but the XOR accelerator and the rest of the RAID functionality was not). It was also the case with my Silicon Image 3112 and 3114 chips, but I understand the latest drives have support for this now.

Unfortunately it's been so long since I researched this, I can't find any of the original links I used. I have found this, which seems to agree with me. mdadm was always the winner in the absence of mega hardware arrays of death.

That sounds like an awefully feasible explanation.

[oDii]

It's likely that the card is running fake RAID - where the RAID logic itself is handled by the card's drivers and not by the card's own hardware or software explicitly. This means that the linux module itself has to run the RAID independently of other tools (such as mdadm or the card's onboard hardware). The net result is that debian recognises the controller and the block devices attached to it, but it does not have support for the RAID components themselves.

This was the case with my Promise SX4 M S150 SATA controller (drives were detected and were usable but the XOR accelerator and the rest of the RAID functionality was not). It was also the case with my Silicon Image 3112 and 3114 chips, but I understand the latest drives have support for this now.

Unfortunately it's been so long since I researched this, I can't find any of the original links I used. I have found this, which seems to agree with me. mdadm was always the winner in the absence of mega hardware arrays of death.

That sounds like an awefully feasible explanation.

For anyone else looking for an explanation, the above is confirmed by this:

#1)The promise controller doesn't do hardware raid. All raid occurs in the driver. The only hardware support is some bios code that allows you to boot off a raid 0 array.

#2)You don't want any promise raid configured for linux md raid.

#3)Linux software raid is better than promise's raid driver.

--http://www.redaht.com/archives/ataraid- ... 00027.html.