[illumos-Advocates] RTI 834 need support for Areca 1880 6Gbps

[Gordon Ross]

I've talked with Garrett at some length about this integration request,
and I believe it should get a "go" for the following reasons:

- It fixes a panic in the current driver.
- It adds support for the "C" hardware (1880 6G cards)
- It has passed stress tests in Nexenta's labs.
- It is architecturally very similar to what Areca has in the field.

Garrett put some work into separating out his architectural
changes, which later will among other things eliminate the
evil use of mutex_owned, and other poor design issues.

So while this code not everything we might want it to be yet,
it's better than what we have, and satisfies a current need
to support the later Areca cards.

Gordon

On Sat, Mar 26, 2011 at 1:11 AM, Garrett D'Amore <garrett at damore.org> wrote:
> webrev is at http://mexico.purplecow.org/gdamore/webrev/arcmsr-delta/
>
> (Note that that's a webrev relative to another, which is here:
> http://mexico.purplecow.org/gdamore/webrev/arcmsr/
>
> However you'll just want to read the "New" file, its a lot easier to
> grok if you're reviewing.)
>
> Full disclosure: richlowe is concerned about the use of mutex_owned() to
> test for mutex ownership.  I believe, that as *ugly* as I think this
> code is, its safe -- the code doing it wants to ensure that the
> isr_mutex is not owned to prevent a deadlock, but unfortunately on the
> abort path it calls the relevant function.  Dropping the mutex here is
> safe.  richlowe is asking for approval (based of my statements below)
> from either gwr or trisk.
>
> I will be redesigning this aspect of the code in a follow on push, and
> I'd be happy to have an outstanding bug filed for this issue.
>
> For the record, this integration also would fix a nasty panic when disk
> failure or detach occurs, and it would address a ugly/incorrect of the
> legacy pm_create_components() interface, in addition to a few other
> issues.  So this code is actually an improvement (significant) over the
> existing driver, even as ugly as some of the code is.
>
> I will be following up with some additional work to refactor the code to
> address the worst complaints in this driver.  This is just step 1 of the
> process.
>
>
> garrett at thinkpad{48}> hg outgoing -v
> running ssh anonhg at hg.illumos.org "hg -R illumos-gate serve --stdio"
> comparing with ssh://anonhg@hg.illumos.org/illumos-gate
> searching for changes
>
> changeset:   13305:fb26af81b9b2
> tag:         tip
> user:        Garrett D'Amore <garrett at nexenta.com>
> date:        Fri Mar 25 22:14:56 2011 -0700
>
> description:
>        834 need support for Areca 1880 6Gbps
>        Reviewed by: Dan McDonald <danmcd at nexenta.com>
>        Reviewed by: Albert Lee <trisk at nexenta.com>
>        Reviewed by: Richard Lowe <richlowe at richlowe.net>
>
> modified:
>   usr/src/uts/intel/io/scsi/adapters/arcmsr/arcmsr.c
>   usr/src/uts/intel/io/scsi/adapters/arcmsr/arcmsr.h
>
>
>
> garrett at thinkpad{49}> hg pbchk
> Copyright check:
>
> C style check:
>
> Header format check:
>
> Java style check:
>
> Mapfile comment check:
>
> File permission check:
>
> Keywords check:
>
> Comments check:
>
> Checking for new tags:
>
> Checking for multiple heads (or branches):
>
> Checking for branch changes:
>
> Checking for uncommitted changes:
>
> Checking for merges:
>
>
>
> Testing:  This code has been tested on both an Areca 1880 and a an Areca
> 1200 card by Nexenta.  Testing included basic ioperf, zpool usage, and
> hotplug usage.
>
>
>
> _______________________________________________
> Advocates mailing list
> Advocates at lists.illumos.org
> http://lists.illumos.org/m/listinfo/advocates
>