SATA PCI controllers for Debian. Highpoint RocketRaid 1520 bad experience. Promise SATAII 150 TX4 works.
Hi,
I have set up 2 servers in the last week. I am setting up the storage via
linux software Raid, using mdadm and md kernel module. I am using Asus A8v
motherboards.
The motherboard comes with 2 SATA channels, supported by the VIA VT8237 chip
on my motherboard hat are supported by Debian Sarge out of the box.
I needed some more SATA channels, and considered the 3ware and Adaptec
solutions, but they were pricey. I don't need hardware raid, and have been
burned in the past...
I like Linux software raid: in Linux I have a vendor that I can trust!
So I looked at Highpoint RocketRaid 1520. about $50, with 2 SATA channels.
It seemed to be supported according to Linuxmafia Sata page. Highpoint web
site also claims support for linux via their proprietary drivers they
distribute.
This is not correct, in my opinion.
The linux kernels 2.6.8 - 2.6.14, with native kernel modules do not support
the Highpoint 1520. If you have hard drives attached to a Hihgpoint 1520 and
you power up your system linux will crash (oops) during boot.
The proprietary driver Highpoint distributes on their website called
hpt3xx-opensource-v2.0.tgz.gz will not compile with the kernel linux 2.6.14.
Moreover while it does compile with the 2.6.8-2 debian kernel there are
kernel error messages on boot : vis:
hpt37x2: module license 'Proprietary' taints kernel.
hpt37x2: Unknown symbol scsi_remove_host
hpt37x2: Unknown symbol scsi_unregister
hpt37x2: Unknown symbol __scsi_iterate_devices
hpt37x2: Unknown symbol scsi_register
hpt37x2: Unknown symbol scsi_device_put
hpt37x2: Unknown symbol scsi_scan_host
hpt37x2: Unknown symbol scsi_add_host
hpt37x2: no version for "scsi_remove_host" found: kernel tainted.
HPT37x2 RAID Controller driver
Version 2.0, Compiled Dec 27 2005 09:34:08
scsi0 : hpt37x2
Vendor: WDC WD40 Model: 00YR-01PLB0 Rev: 01.0
Type: Direct-Access ANSI SCSI revision: 00
Vendor: WDC WD40 Model: 00YR-01PLB0 Rev: 01.0
Type: Direct-Access ANSI SCSI revision: 00
Vendor: WDC WD40 Model: 00YR-01PLB0 Rev: 01.0
Type: Direct-Access ANSI SCSI revision: 00
Vendor: WDC WD40 Model: 00YR-01PLB0 Rev: 01.0
Type: Direct-Access ANSI SCSI revision: 00
SCSI device sda: 781422767 512-byte hdwr sectors (400088 MB)
sda: asking for cache data failed
sda: assuming drive cache: write through
/dev/scsi/host0/bus0/target0/lun0: p1
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 781422767 512-byte hdwr sectors (400088 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
/dev/scsi/host0/bus0/target1/lun0: p1
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
SCSI device sdc: 781422767 512-byte hdwr sectors (400088 MB)
sdc: asking for cache data failed
sdc: assuming drive cache: write through
/dev/scsi/host0/bus0/target2/lun0: p1
Attached scsi disk sdc at scsi0, channel 0, id 2, lun 0
SCSI device sdd: 781422767 512-byte hdwr sectors (400088 MB)
sdd: asking for cache data failed
sdd: assuming drive cache: write through
/dev/scsi/host0/bus0/target3/lun0: p1
Attached scsi disk sdd at scsi0, channel 0, id 3, lun 0
sata_via(0000:00:0f.0): routed to hard irq line 10
ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xB802 bmdma 0xA800 irq 185
ata2: SATA max UDMA/133 cmd 0xB400 ctl 0xB002 bmdma 0xA808 irq 185
ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023
88:407f
ata1: dev 0 ATA, max UDMA/133, 781422768 sectors: lba48
ata1: dev 0 configured for UDMA/133
scsi1 : sata_via
ata2: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023
88:407f
ata2: dev 0 ATA, max UDMA/133, 781422768 sectors: lba48
ata2: dev 0 configured for UDMA/133
scsi2 : sata_via
Vendor: ATA Model: WDC WD4000YR-01P Rev: 01.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sde: 781422768 512-byte hdwr sectors (400088 MB)
SCSI device sde: drive cache: write back
/dev/scsi/host1/bus0/target0/lun0: p1
Attached scsi disk sde at scsi1, channel 0, id 0, lun 0
Vendor: ATA Model: WDC WD4000YR-01P Rev: 01.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdf: 781422768 512-byte hdwr sectors (400088 MB)
SCSI device sdf: drive cache: write back
/dev/scsi/host2/bus0/target0/lun0: p1
Attached scsi disk sdf at scsi2, channel 0, id 0, lun 0
raid1: raid set md0 active with 2 out of 2 mirrors
md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwith (but not more than 200000 KB/sec)
for reconstruction.
md: using 128k window, over a total of 390711296 blocks.
md: bind<sda>
md: bind<sdb>
raid1: raid set md1 active with 2 out of 2 mirrors
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwith (but not more than 200000 KB/sec)
for reconstruction.
md: using 128k window, over a total of 390711296 blocks.
md: bind<sdc>
md: bind<sdd>
raid1: raid set md2 active with 2 out of 2 mirrors
md: syncing RAID array md2
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwith (but not more than 200000 KB/sec)
for reconstruction.
md: using 128k window, over a total of 390711296 blocks.
**********************
Notice in addition to the
symbol missing errors we have errors about cache data
sdc: asking for cache data failed
sdc: assuming drive cache: write through
Notice that the via driver is fine.
Also there is a major performance hit with Highpoint relative to Via on
motherboard.
It takes 100 minutes to sync a Raid 1 volume consisting of 2 400GB WD drives
on the 2 channels of the via controller VT8237.
However It takes 300 minutes to sync those same two drives on the Highpoint.
It takes just 125 minutes on the SATAII150 TX4.
Compare the SATAII150 TX4.
1) It is cheaper -get 4 channels not 2! for 50 dollars
2) It has native open source support in kernel 2.6.12 and 2.6.14 (debian
kernels)
3) 125 minute sync of Raid 1 for 400GB drives - almost as fast on the native
motherboard SATA controller.
Advice to Highpoint. You should help Alan Cox write better drivers for your
equipment. You are falling behind. I used your Highpoint Pata controllers in
the past for my servers.
I enclose a email from Alan Cox that I got, cross posted from the Linux kernel
list about these issues.
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Mitchell Laks <mlaks@verizon.net>
CC: linux-kernel@vger.kernel.org
Date: Yesterday 12:51:44 pm
On Maw, 2005-12-27 at 02:19 -0500, Mitchell Laks wrote:
> to use as simple block devices for linux software raid purposes. I thought
> they were supported on Linux, because of highpoint web site and my previous
> experience with highpoint pata controllers was ok.
Some are, although there are problems remaining in things like clock
timing and PLL stabilization. In addition the ide/pci/hpt366.c driver
never supported the SATA bridge variants of the chipsets at all. These
require certain modes are used.
What may work if the HPT card has the onboard BIOS enabled and fitted is
to compile in the generic IDE PCI driver, say N to the HPT driver and
boot with the option "all-generic-ide".
I've been working on a new HPT372N/302N driver for libata/SATA but it
isn't yet production ready and it also does not know about the SATA
bridge rules for that chip.
> I tried to compile the hpt3xx-opensource-v2.0.tgz against latest stable
> kernel 2.6.14.4. After minor corrections I have failure to compile their
> driver due to scsi_cmnd structure "has no member abort_reason". Has their
> been a change in scsi subsystem?
Several
Alan
Reply to: