Topic: Highpoint 2310 RAID adapter drivers

[brookes]

Hello,

Has anyone compiled the drivers for this card for SME 7.1.3? Anyone got the card running?

Cheers

Stephan.

PS. I am aware this card could be "fake" RAID.

[brookes]

Actually, I'm close to loading the driver just is that they have compiled so many I cannot work out which one to use. Can someone tell me which is the equivilant version of RH to use? The kernel is correct at 2.6.9-42 and I am trying the smp version. I don't know if I should be using RH 3 or 4 or i686 or i386?

[brookes]

All sorted, working perfectly.

[brookes]

Well not exactly working perfectly. The partition table seems to be getting corrupted on reboot. I have got the driver loading at start according to the Highpoint instruction and I have managed to partition and format the partition. I have also managed to mount the partition and copy data to it but upon reboot I get:

1st reboot:
Mar 31 08:33:00 peter kernel: rr2310_00: module license 'Proprietary' taints kernel.
Mar 31 08:33:00 peter kernel: rr2310_00:0: RocketRAID 231x/230x controller driver v2.0 (Mar 22 2007 07:29:27)
Mar 31 08:33:00 peter kernel: ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 169
Mar 31 08:33:00 peter kernel: PCI: Setting latency timer of device 0000:02:00.0 to 64
Mar 31 08:33:00 peter kernel: rr2310_00:0: adapter at PCI 2:0:0, IRQ 169
Mar 31 08:33:00 peter kernel: rr2310_00:0: start channel [0,0]
Mar 31 08:33:00 peter kernel: rr2310_00:0: start channel [0,1]
Mar 31 08:33:00 peter kernel: rr2310_00:0: start channel [0,2]
Mar 31 08:33:00 peter kernel: rr2310_00:0: start channel [0,3]
Mar 31 08:33:00 peter kernel: rr2310_00:0: channel [0,0] started successfully
Mar 31 08:33:00 peter kernel: rr2310_00:0: channel [0,1] started successfully
Mar 31 08:33:00 peter kernel: rr2310_00:0: channel [0,3] started successfully
Mar 31 08:33:00 peter kernel: rr2310_00:0: channel [0,2]: failed to perform Hard Reset
Mar 31 08:33:00 peter kernel: scsi2 : rr2310_00
Mar 31 08:33:00 peter kernel:   Vendor: HPT       Model: DISK_2_0          Rev: 4.00
Mar 31 08:33:00 peter kernel:   Type:   Direct-Access                      ANSI SCSI revision: 00
Mar 31 08:33:00 peter kernel: SCSI device sdc: 976486400 512-byte hdwr sectors (499961 MB)
Mar 31 08:33:00 peter kernel: SCSI device sdc: drive cache: write through
Mar 31 08:33:00 peter kernel: SCSI device sdc: 976486400 512-byte hdwr sectors (499961 MB)
Mar 31 08:33:00 peter kernel: SCSI device sdc: drive cache: write through
Mar 31 08:33:01 peter kernel:  sdc: sdc1
Mar 31 08:33:01 peter kernel: Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0

2nd reboot after disabled fstab:
Mar 31 08:45:56 peter kernel: rr2310_00: module license 'Proprietary' taints kernel.
Mar 31 08:45:56 peter kernel: rr2310_00:0: RocketRAID 231x/230x controller driver v2.0 (Mar 22 2007 07:29:27)
Mar 31 08:45:56 peter kernel: ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 169
Mar 31 08:45:56 peter kernel: PCI: Setting latency timer of device 0000:02:00.0 to 64
Mar 31 08:45:56 peter kernel: rr2310_00:0: adapter at PCI 2:0:0, IRQ 169
Mar 31 08:45:56 peter kernel: rr2310_00:0: start channel [0,0]
Mar 31 08:45:56 peter kernel: rr2310_00:0: start channel [0,1]
Mar 31 08:45:56 peter kernel: rr2310_00:0: start channel [0,2]
Mar 31 08:45:56 peter kernel: rr2310_00:0: start channel [0,3]
Mar 31 08:45:56 peter kernel: rr2310_00:0: channel [0,0] started successfully
Mar 31 08:45:56 peter kernel: rr2310_00:0: channel [0,1] started successfully
Mar 31 08:45:56 peter kernel: rr2310_00:0: channel [0,3] started successfully
Mar 31 08:45:56 peter kernel: rr2310_00:0: channel [0,2]: failed to perform Hard Reset
Mar 31 08:45:56 peter kernel: scsi2 : rr2310_00
Mar 31 08:45:56 peter kernel:   Vendor: HPT       Model: DISK_2_0          Rev: 4.00
Mar 31 08:45:56 peter kernel:   Type:   Direct-Access                      ANSI SCSI revision: 00
Mar 31 08:45:56 peter kernel: SCSI device sdc: 976486400 512-byte hdwr sectors (499961 MB)
Mar 31 08:45:56 peter kernel: SCSI device sdc: drive cache: write back
Mar 31 08:45:56 peter kernel: SCSI device sdc: 976486400 512-byte hdwr sectors (499961 MB)
Mar 31 08:45:56 peter kernel: SCSI device sdc: drive cache: write back
Mar 31 08:45:56 peter kernel:  sdc: unknown partition table

The server actually drops out to filesystem repair when booting and I need to disable the mount in fstab. After that need to format the partition again. As far as I can see the card is working perfectly and it presents the array ok but somehow the partition table is being corrupted. I have tried:

1. Disabling the controller cache (change to write-through)
2. Trying EXT2 (mkfs -t ext2 /dev/sdc1) and EXT3 (tune2fs -j /dev/sdc1) from the fstab. Plain EXT2 does not get recognised and EXT3 will get corrupted.

When I prepare the partition it mounts just fine and I can umount it and load it via mount -a but upon reboot it's cactus. I can even reboot with the line commented out in the fstab and mount it on reboot fine manually. There seems to be a timing issue trying to mount the drive at that particular time of the startup sequence.

Would anyone have any ideas ?

[CharlieBrady]

PS. I am aware this card could be "fake" RAID.

So why bother?

[brookes]

So why bother?

Thanks for your input Charlie. If anyone else has as little to add please don't bother.

Stephan.

[CharlieBrady]

So why bother?

Thanks for your input Charlie. If anyone else has as little to add please don't bother.

It was a serious question, Stephan. My advice to you is to not use that card. You've already spent quite some time and it has caused you nothing but grief. Cut your losses and use the builtin software RAID.

[brookes]

Charlie,

You assume too much. You assume that I don't need an additional card in my server to support the additional drives. You assume that I don't want to perfect this configuration. You assume that software RAID is the best solution (still out for debate but I support the hardware argument) and most importantly you assume I haven't considered my options and chosen what I consider is the best one for me. I added the comment about the "fake" RAID adapter in an effort to exclude this debate on using the card, a debate that I consider to be a waste of time.

I want to point out that this card does not appear to be "fake" as Linux does not see the drives as separate, which I understand is the problem with "fake" cards.

Finally, by me trying the card and getting it working or not builds this knowledgebase and the skills of the people (me) accessing it. Your advice is a distraction and to be frank unhelpful.

Stephan (without the "e")

[Wilson]

Is the software RAID SME Server 7.1 uses independent of the motherboard? (e.g. if the board fails, can I just substitute any other board that has the requisite number of SATA ports?)

If I change upgrade SME Server, or change distros (most likely CentOS or RHEL) will the data remain addressable and intact?


I also have a HPT 2310 that was a working pull from a windows box aside from slightly lower CPU Utilization (2% instead of 5% in HDTach). And slightly faster read/write times (compared to NF4 onboard RAID) As well as the inability for the chosen motherboard at the time to come with 8 SATA ports and RAID 5 support..

The reason this is a concern is because of previous scares.

I was using the 2310 in the first place, was using onboard RAID on the windows box, was scary. I've had boards die on me in the past whilst using the onboard RAID controller, and had a heck of a time finding the same revision of the same board, so I could get the data off the array (it was an Asus A8N-SLI).

Other brands of mobo didn't work, even with the same nForce 4 SLI Chipset, I tried DFI, MSI, Gigabyte, ECS even an Asus A8N32-SLI all of them couldn't address the array.

[Orlock]

Charlie,

You assume too much. You assume that I don't need an additional card in my server to support the additional drives. You assume that I don't want to perfect this configuration. You assume that software RAID is the best solution (still out for debate but I support the hardware argument) and most importantly you assume I haven't considered my options and chosen what I consider is the best one for me. I added the comment about the "fake" RAID adapter in an effort to exclude this debate on using the card, a debate that I consider to be a waste of time.

I want to point out that this card does not appear to be "fake" as Linux does not see the drives as separate, which I understand is the problem with "fake" cards.

Finally, by me trying the card and getting it working or not builds this knowledgebase and the skills of the people (me) accessing it. Your advice is a distraction and to be frank unhelpful.

Stephan (without the "e")

Stephan,

Several points i feel should be made:
The card most likely is not a true hardware raid card. They allow OS independant rebuilding and reconfiguration of the raid array.
The drivers that is uses are tainting the kernel - This may make troubleshooting more troublesome down the track, and you may find people unwilling to try and debug issues caused by a "tainted" driver

Software raid will allow your RAID configuration to be independant of any strange behavious your "hardware" raid might have, and allow you to use a wider range of controllers for recovery in case of hardware failure.

Generic software raid is better than most sorts of "fake" raid in almost all cases due to those reasons. Using an on-board controller or one on a PCI card doesnt have any bearing on the discussion.

The fact that linux sees the drives as a single drive is a function of the fakeraid driver doing its thing. Its a very different beast to a true hardware  raid card, with its own CPU, cache and battery that will perform rebuilds, etc without utilising the host CPU as this system would.

fakeraid gives you all of the bad points of hardware raid (being tied to that controller type for any recovery if the controller fails) with none of the good points (Cache, battery backed, plus its own CPU to handle the raid functionality)

It may build your knowledgebase, but its not worthwhile knowledge to have - You have already stated that you are having problems with the partitions, etc. This is almost certainly due to CHS/LBA mapping issues with the tainted driver, or just plain bugs in the tainted driver. Who provided it, and was it binary or source?

If its binary, then you had better hope that thye provide timely updates too - Hate to be held back on an update as your vendor is slack in compiling their bnary drivers...

[Wilson]

The HPT 2310 actually doesn't support OS independent rebuilding or reconfiguration. Its all OS based with their proprietary software. They do however provide both the source and the binary.

What's weird is the drivers work flawlessly in CentOS 4.4, but won't even  load during the installation phase in SME Server 7.1

Software raid will allow your RAID configuration to be independant of any strange behavious your "hardware" raid might have, and allow you to use a wider range of controllers for recovery in case of hardware failure.

So essentially any CentOS supported motherboard with the requisite number of SATA ports will be able to address the array, running SME Server or any other RHEL derivative?

[CharlieBrady]

So essentially any CentOS supported motherboard with the requisite number of SATA ports will be able to address the array, running SME Server or any other RHEL derivative?

Correct.

[brookes]

Well unfortunatly this thread has turned into the debate I was hoping it wouldn't. I tried to avoid the debate on "Hardware vs Software RAID" and also the "Fake vs Real RAID" but it seems both have surfaced here. I don't understand why we need to cover this old ground rather then just see if we can get it working.

Ok your opinion may be that Software RAID is better the Hardware RAID and I have listened and thank you. You opinion about fake RAID is also given and I have again listened and again thank you. If someone has got this card working to their satisfaction can you let me know how you did it?

Stephan.