Folks,
I'm about to get a new motherboard or two for a large personal
fileserver with min 4 parallel 120G IDE disks using Linux RAID5. I am
trying to decide which MB and what additional components to use. Current
favorite is the MSI KT6-Ultra FISR, which uses a Broadcom chip for GigE
(good?) but with a Promise 20378 providing additional IDE (not sure).
These days it seems more motherboards that have additional IDE ports use
Promise chips, with a few using HPT ones. I note the advent of the
Promise GPL SATA drivers and Jeff's libata. I am also aware that my
current setup ( Linux 2.4.22 and onboard 20276) does occasionally cause
me grief, with lost interrupts making me wonder if all is well. I have 2
Promise 20267 IDE cards available should that be useful.
Should I steer clear of the Promise chips and use HPT ones (either MB,
or the RocketRAID, or Adaptec 1200 cards) or have folks got them licked
now?
Thanks for any help,
Ruth
"Ruth Ivimey-Cook" <[email protected]> writes:
> These days it seems more motherboards that have additional IDE ports use
> Promise chips, with a few using HPT ones. I note the advent of the
> Promise GPL SATA drivers and Jeff's libata. I am also aware that my
> current setup ( Linux 2.4.22 and onboard 20276) does occasionally cause
> me grief, with lost interrupts making me wonder if all is well. I have 2
> Promise 20267 IDE cards available should that be useful.
One big problem with the Promise drivers is that they are not 64bit
clean. Trying them in a 64bit x86-64 kernel fails quickly.
Fixing them is unfortunately a lot of work because of the weird
Windows like programming style in the CAM layer in there.
Also at least some released versions of them had gapping security holes
in the ioctl handlers.
-Andi
On Mer, 2003-09-24 at 02:27, Andi Kleen wrote:
> One big problem with the Promise drivers is that they are not 64bit
> clean. Trying them in a 64bit x86-64 kernel fails quickly.
> Fixing them is unfortunately a lot of work because of the weird
> Windows like programming style in the CAM layer in there.
>
> Also at least some released versions of them had gapping security holes
> in the ioctl handlers.
Looking at the BSD drivers you may well be able to do a minimal mmio
version of the 2026x driver for the chips as a stopgap. That wouldn't be
as good as the full libata thing once it is done but it would make it go