Who is working on the Marvell SATA Chipset?

Who is working on the Marvell SATA Chipset?

[Tom Dickson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Who is in charge of the "in progress" driver for the Marvell 88SX5040?

Thank you!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBbCvW2dxAfYNwANIRAsyZAJ9JPEVhetIY91y/XNCUwZw4yv2C4gCdGeaQ
+UZSfJy22bIVxDEA5VazFu8=
=KtNL
-----END PGP SIGNATURE-----

Re: Who is working on the Marvell SATA Chipset?

[Jeff Garzik]

Tom Dickson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Who is in charge of the "in progress" driver for the Marvell 88SX5040?

I have a skeleton driver locally, need to get on to finishing it.

	Jeff

Re: Who is working on the Marvell SATA Chipset?

[Andy Warner]

Jeff Garzik wrote:
> Tom Dickson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Who is in charge of the "in progress" driver for the Marvell 88SX5040?
> 
> I have a skeleton driver locally, need to get on to finishing it.

Marvell also have drivers for 2.4 and 2.6, but they are under NDA
etc etc, and ignore libata (they also pre-date libata), so if
you have hardware that you _must_ get working; they might be
a useful stopgap.

I'll repeat my eagerness to test anything for the 88SX50xx or 88SX60xx,
regardless of how primitive it is. My benchmarking with the Marvell
driver shows the throughput to be excellent.
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

Re: Who is working on the Marvell SATA Chipset?

[Joel Jaeggli]

On Tue, 12 Oct 2004, Andy Warner wrote:

> Jeff Garzik wrote:
>> Tom Dickson wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Who is in charge of the "in progress" driver for the Marvell 88SX5040?
>>
>> I have a skeleton driver locally, need to get on to finishing it.
>
> Marvell also have drivers for 2.4 and 2.6, but they are under NDA
> etc etc, and ignore libata (they also pre-date libata), so if
> you have hardware that you _must_ get working; they might be
> a useful stopgap.
>
> I'll repeat my eagerness to test anything for the 88SX50xx or 88SX60xx,
> regardless of how primitive it is. My benchmarking with the Marvell
> driver shows the throughput to be excellent.

I would love to be buying the 8 port pci-x marvells for nas boxes where 
we're doing JBOD or software raid.

http://www.supermicro.com/products/accessories/addon/DAC-SATA-MV8.cfm

which is running around $110 at this point.


-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu 
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

Re: Who is working on the Marvell SATA Chipset?

[linux]

> I would love to be buying the 8 port pci-x marvells for nas boxes where 
> we're doing JBOD or software raid.

Me too, but I'm really trying to get hardware with NCQ support.  Some of
the Seagate 7200.7 series (the ST3xxx8xxAS drives, to be precise; look
for the 8 in the part number) support NCQ, are reasonably priced, and
have 5-year warranties.  So that part's easy.

My problem is finding an *88SX6040*-based adapter card.
All the ones I can find (the SuperMicro DAC-SATA-MV8 and the
Highpoint RocketRaid 1820A) are non-NCQ 88SX5040 designs.

Even if the software support isn't there now, it's nice to buy
future-proof hardware, and NCQ should help a file or database server
a lot.

So at the moment I'm waiting for the Promise SATAII150 SX8 to come
available, but I'm open to other suggestions.

(Note that the Marvell binary driver poperly designed as a Marvell-
supplied chipset access library and and source-supplied device driver
wrapper.  So it shouldn't be too brittle in the face of kernel changes.)

Anyway, does anyone have any suggestions for a PCI-X 8-port SATA controller
with NCQ support?

Thanks!

Re: Who is working on the Marvell SATA Chipset?

[Mark Hahn]

> future-proof hardware, and NCQ should help a file or database server
> a lot.

has anyone tried this experimentally?  such loads are seek-oriented,
but the kernel's normal request scheduling should provide most of the 
benefits of NCQ, regardless of disk/controller support.  or do you 
have a workload where the kernel's head-scheduling doesn't have enough
data to optimize properly?  (for instance, lots of activity within a 
single cylinder of disk.)

thanks, mark hahn.