Intro:
Ok, some time ago, I ordered a Promise FastTrak SX4000. Major cause was it's cheap price, and it's support for Linux...well, since then, I had to redefine the word "Support".

Linux Support means just some closed-source drivers, which are not even acessible the way described in the manual. It was a pain in the ass to find 'em. Not enough, loading them (even if the kernel version matched) caused a lovely segfault.

Hours of searchin the web, using different modules and much more were done. Nothing but the anger and disappointment of countless SX4k users.
(End intro)

Well, last days, I decided to try again and mailed to promise support with a kindly request to build a driver against 2.4.20 - surprise! They answered few minutes later with the beta open source driver as attachment (Im just wondering why I didn't found this driver on the net).

From there on, everything went easy: compiling the module, loading scsi modules first (scsi_mod, sd_mod) then loading the FastTrak module - everything went fine.

Mounting and Formatting worked too. There was only a lil' strange thing: The SX BIOS recognizes 3 drives at boot (2 in RAID1, 1 in RAID0), but Tux only sees 2 Drives - apparently with the same RAID size specified in the SX BIOS. This contravences with other user's experiences - they had to do the raid job via linux (all drives were seen by Tux).

This evening, I'll check if the RAID setups work the way I've set them up, what happens if a drive fails etc.

Anyone out there who has smiliar problems / made similar efforts ?

Ok, so far I unplugged the power cord of one drive in a RAID1 array: 3 seconds without any action, then about 1-2 seconds freeze (guess the controller looked for the lost drive) and then everything continued - but the controller did AWFULLY beep all the time (I recommend to cut the lil' beeper off the PCB). Syslog showed that the controller lost connection to the drive. I was able to use the filesystem w/o any problems. Fine! Then I was about to plug in the drive's power wire again - but made a stupid stupid mistake and shortcut wires which should not be shortcutten - *poof* power off. God thanks nothing happened and I could fire the computer up again, with all drives attached.

This caused the system replaing the fs-log (ext3), so all the files I deleted while one drive was off were back again due to this, and not due to the controller.

Next time, i'll try to check what happens if I unplug one drive, modify the filesystem, force a sync and plug the drive back in while the system is running. Or did anyone else this before ? Then please reply.

Damnit! Things were lookin' good, so moved on to the next step, upgrading the BIOS (had a some HDD which caused the sx4k to fail) - but even though the tool gave me an "OK", it wasn't, and the new sx4k bios caused my computer to hang at boot...well, looks like i've got to bother my dealer now

NOTE: If you want to have the open-source driver I mentioned above, PLEASE FIRST WRITE AN EMAIL TO PROMISE SUPPORT before you ask me. Promise must learn that there is a need for open-source drivers. And don't flame them, just give a clear subject and be kindly.

I have a similar tail of woe trying to install an SX4000 in a Dell Poweredge server running RedHat 9.0. At first there was a conflict with an Adaptec scsi card that prevented both cards from being installed at the same time. Finally Promise released a new bios update which seems to have fixed that problem. They also released the initial drivers for RedHat 8/9. I was able to get the system installed and all seemed well with the world. Next I applied all the latest RedHat updates (except kernel) and bam segmentation faults like crazy. So bad I couldn't recover. After many hours of trial and error, I narrowed the problem down to the glibc updates. I seem to be able to apply other updates without a problem, but lately I'm noticing an occasional segfault. Enough to make me nervous about putting this server back into production. I send several e-mails to support@promise.com but so far no response, not even to acknowledge they received any thing.

Do you use the binary drivers ? I encountered similar problems when using the those (well, ok, i did a complete kernel upgrade).

Try to send a support request at other countries. .com seems to be a bit overloaded.

If you still have serious probs, I could send the beta open-source drivers to you. You should be able to run the server and use the array, though you got absolutely NO support by promise or anyone regarding those drivers. For example, they rendered my linux almost unusable (flooded syslog) as soon as I loaded the kernel module (fastrack.o) when an specific IBM HDD was attached. Guess that was a BIOS problem, since I read something with "IBM xxx HDD support fixed" in the description of the newer BIOS.

But the drivers allowed me to use promise's CLU (command line utilty)...after installing some strange libraries (libstdc++6.2blahblah). However, this CLU's isn't a good piece of programming art...even assembler programmers create better user interfaces. At least it works.

Dunno if you really want such tentative bytes on a production system.

I downloaded the drivers for RedHat 8/9 from the Promise website, created a driver disk and then installed it during boot with "linux dd".

I can't figure out why changing glibc would cause the segmentation faults. I can see where changing the kernel would possibly cause problems so I didn't try to change it.

Back on the road again, with the driver available for download and a finally running sx4k.
http://www.roeme.ch/thread.php?threadid=12&boardid=8

/edit: Link updated.