RAID controller blues

[Taz]

I've been running a Promise FaskTrak SX4000 with 3 x 120Gb PATA drives RAID 5 for yonks and had no problems with it, but 240Gb doesn't go very far these days. I didn't see the point in getting larger PATA drives so decided to see if I could get a decent SATA RAID card cheap on eBay. Eventually got a Promise FastTrak S150-SX4, which is virtually identical to the SX4000 except it has 4 Marvell SATA bridges to make it a SATA controller. I also bought 3 x Seagate Barracuda 7200.10 500Gb SATA drives to go with it.

The system didn't want to boot up with both RAID cards in so I connected a seperate SATA drive to the on-board Silicon Image SATA controller and copied everything from the old array onto that. Checked Windows booted up Ok, which it did. Removed old card, installed new card and created a new RAID 5 array. Rebooted and it hung just after the RAID BIOS reported the array was functional. Wiped the array and Windows boots fine. Created the array using the Windows utility and that worked and Windows saw the new logical drive. Rebooted and again it hung just past the RAID controllers BIOS screen.

Made sure the BIOS on the motherboard and RAID card were up to date, which they were. The S150-SX4 uses the same BIOS as the SX4000 and both cards had the same version.

Checked settings in the BIOS to do with boot order and hard drives, made no difference.

Put the controller and drives in another system and they work fine so they must be Ok.

Tried created a single JBOD array with one of the 500Gb drives, no difference. A mirrored pair again no difference.

The motherboard is a Gigabyte GA-7A8DW with 2 x Opteron 244's, 2Gb PC3200 ECC memory, ATI Radeon X1950Pro, Samsung SATA DVD-RW, Pioneer PATA DVD-RW, Quantum DLT-V4 SATA tape drive.

Seems like the Gigabyte board doesn't like the controller, which seems strange seeing how close it is to the old one

[VJ]

I had issues after adding a RAID controller due to the fact that the amount of bios memory where bootable cards copy their ROM is limited. In my case, there were 2 bootable scsi cards, a bootable network card and then the raid controller. As I boot from an onboard scsi card, it puts its ROM last in that boot area; as there wasn't enough space, if failed to load the bios of the scsi card and refused to boot.
The only way to get it to work was to disable the bios of the raid card (my boot drive is scsi). Alternatively, on some mainboards (also on mine), it is possible to set in the mainboard bios which cards are allowed to copy their ROM (this is a per slot setting).

A few months after, Promise released a bios update for the raid card, and it was apparently small enought to be loaded together with all the other ones.

Perhaps you are running into a similar issue? Try disabling the bios of the raid card, or try to disable boot functionality for that slot (in the mainboard bios). If you don't boot from network, it could prove sufficiant to disable bootfunctionality of that card (possibly freeing up enought space for the raid).


Jörg

[Taz]

Just to let you know you were right

In then end I had to copy everything on the standalone SATA drive onto a PATA drive and then from that onto the new array, disabling the on-board SATA controller before doing so.

[VJ]

Cool!
Glad it is solved.

When I ran into the issue, I didn't know where to start and called the Supermicro support; they immediately identified the problem. The thing is: the OS can access the drives on the cards where the bios has been disabled. The only downside is that you cannot see the status of the raid at boot time, nor perform maintenance operations directly (on my raid, I needed to resort to the web interface).

I would suggest keeping an eye out for bios updates of the controller manufacturers, it is possible an update could allow you to re-enable the bios.

Jörg