View Full Version : Two add-in RAID controllers won't play nice
I.M.O.G.
03-08-04, 10:20 PM
Only whichever controller that is placed in the highest priority PCI slot will work.
The Sil3112 sata RAID is in PCI 2 with IRQ 10.
The Promise pata RAID is in PCI 3 with IRQ 11.
Neither are sharing resources with other devices.
After mobo bios post, the sata bios will post, then windows loads.
If I switch the cards, the promise bios will post.
Both controllers can be seen in device manager, only the sata raptor can be seen in disk management. Both have arrays created.
I have tried playing with PCI slot configuration and IRQ assignments. No luck.
How can I get my PATA RAID operational?
shadowdr
03-09-04, 05:55 AM
Have you tried the "enable delay for ide"? It might give the bios time to detect both before giving control back to windows.
Is there a problem with disk numbers? I know that most arrays like to number their disks as 0 and 2.This might be confusing windows.I am assuming that windows is not on either array(or both).Have you tried installing on one and making it the low priority pci slot?
Only other thing i can think of offhand would be pci latency.If it is set to high or low it may not be giving up the bus in time for detection in bios.
I have also been considering that setup for my own mobo only because I have three extra drive lying around.Please let us know if you get her working and what you had to do.
I.M.O.G.
03-09-04, 04:14 PM
shadowdr: I don't have the option for "delay IDE"... And nothing is connected to my onboard controllers. XP is on the Sil3112. If it is in the higher PCI slot, XP loads. If the promise is in the higher PCI slot, the boot dies after the promise bios posts - it doesn't look to the Sil3112.
I think I have finally figured out the problem however, thanks to some help.
I take back anything negative I ever said about the [H].
I have threads posted on this problem here, EOC, SR, and OCP forums and I was just checking them today. Snugglebear over at the [H] explained how things work, and this may also help you in what you are considering shadowdr. This is what he said:
The way the system BIOS works - detection starts with integrated controllers, works its way to integrated special controllers (e.g. ATA33->ATA100/RAID), then down the PCI slots. When you have multiple PCI controllers you need to disable their ability to boot on all but the boot device. This is a very common thing to do with SCSI controllers, and SCSI cards have a `disable boot rom` or `disable SCSI bios` option in their bios menus. However, with el cheapo ATA units this isn't too common, and as a result running multiple controllers isn't always possible. Those units tend to be built on the assumption that you'll be using that one controller in addition to whatever is integrated onto the board. As such many don't seperate the ability to scan the channels and initialize arrays from the boot sequence, so rather than scanning, initializing, and letting the next controller take over, they scan, initialize, and boot regardless of anything else.
I've actually had lots of run-ins with this over the years, trying to use multiple ATA and SCSI controllers at once. It was really upsetting to be able to use multiple SCSI controllers together quite easily, but then as soon as I dropped in an ATA RAID controller ****->fan. I actually lucked out a few years back when I bought an ST6 with an onboard HPT37x - not sure if it's because it uses an Intel bootloader or what, but the HPT37x and Promise 100TX coexist peacefully. Both run their detect routines at boot, but the system boot target itself is the HPT, so the order is POST -> HPT init -> Promise init -> HPT boot. This doesn't happen in any other machine of mine, even other HPT-integrated boards.
So, in the end, dig through your controller bioses. What you need is to let the controllers scan their channels and initialize disks/arrays, but not try to boot. You may be able to disable booting through an explicit option, or simply something like not selecting a boot drive in them. Do not be surprised if nothing you do works, though. You are, after all, using SOHO equipment in a more professional/enterprise capacity.
So I now know where I need to go from here... Whether the cards have the capabilities or not is the question.
I.M.O.G.
03-09-04, 06:39 PM
Welp, looks like this problem was laid to rest:
I flashed the bios of the Sil3112 successfully and it made no difference... Somewhat expected. So I rebooted and went back into my mobo bios... Decided to set everything to optimized defaults for the kick of it. Went through and made a few essential customizations (turned off onboard sound, unused IDE channel, etc.), and saved and rebooted.
Upon boot, mobo bios posted, sil bios posted... PROMISE BIOS POSTED! This is about the time when I did a full backflip and jumped around my room. Windows loaded and, sure enough, there's my disk I've been working so hard for... Went into disk management and formatted the partitions again. Works like there never was a problem.
I investigated the changes I made... The boot devices needed to NOT be set to boot from SCSI - I disabled everything and left the first boot device as HDD-0. This allows both bios to post and initialize.
I would be wrong not to mention the guys at the [H] and SR forums for the knowledge they shared with me on the boot process and controllers. If you ever need storage help, their data storage and computer forums are very helpful and friendly.
shadowdr
03-10-04, 06:13 AM
Good job!
Now to find another card.
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.