request to add aic94xx to -mm

request to add aic94xx to -mm

[James Bottomley]

Hi Andrew,

I'd like to see aic94xx added to -mm to get it wider exposure subject to
the following caveats:

1. Hotplug is still a bit of a mess
2. SATA attachment doesn't work

Could you send any bugs found back to linux-scsi (not the kernel
bugzilla)?

The tree is at

master.kernel.org:/pub/scm/linux/kernel/git/jejb/aic94xx-sas-2.6.git

It's pretty much a working tree (as in most of the patches don't have
proper commit logs), so I'm going to flatten it once we get agreement
that it should go forwards into scsi-misc.

Thanks,

James

Re: request to add aic94xx to -mm

[Douglas Gilbert]

James Bottomley wrote:
> Hi Andrew,
> 
> I'd like to see aic94xx added to -mm to get it wider exposure subject to
> the following caveats:
> 
> 1. Hotplug is still a bit of a mess
> 2. SATA attachment doesn't work

3. my whole SCSI subsystem locked up a couple of times.

If that is still a problem then I would recommend other
testers place their root file system on a PATA disk :-)

> Could you send any bugs found back to linux-scsi (not the kernel
> bugzilla)?
> 
> The tree is at
> 
> master.kernel.org:/pub/scm/linux/kernel/git/jejb/aic94xx-sas-2.6.git
> 
> It's pretty much a working tree (as in most of the patches don't have
> proper commit logs), so I'm going to flatten it once we get agreement
> that it should go forwards into scsi-misc.

Doug Gilbert

Re: request to add aic94xx to -mm

[Mike Anderson]

Douglas Gilbert <dougg@torque.net> wrote:
> > 1. Hotplug is still a bit of a mess
> > 2. SATA attachment doesn't work
> 
> 3. my whole SCSI subsystem locked up a couple of times.
> 
> If that is still a problem then I would recommend other
> testers place their root file system on a PATA disk :-)

Can you provide information on your configuration? Is there anything in
the logs prior to the lock up?

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: request to add aic94xx to -mm

[James Bottomley]

On Fri, 2006-04-28 at 13:16 -0400, Douglas Gilbert wrote:
> James Bottomley wrote:
> > Hi Andrew,
> > 
> > I'd like to see aic94xx added to -mm to get it wider exposure subject to
> > the following caveats:
> > 
> > 1. Hotplug is still a bit of a mess
> > 2. SATA attachment doesn't work
> 
> 3. my whole SCSI subsystem locked up a couple of times.

Well, no, the above is supposed to be the list of things I'm not
interested in bug reports on unless accompanied by code fixes.  If it
locks up the scsi subsystem I am interested in that ... I do run two of
these machines as SCSI test/build machines with no problems like
this ... do you have a bug report?

James

Re: request to add aic94xx to -mm

[Christoph Hellwig]

On Fri, Apr 28, 2006 at 11:54:05AM -0500, James Bottomley wrote:
> Could you send any bugs found back to linux-scsi (not the kernel
> bugzilla)?

not a bug strictly speaking, but it should stop including the firmware
blob and use request_firmware, similar to the discussion we had about
qla2xxx recently.  It would be even nicer if adaptec continued publishing
their sequencer code as with aic7xxx and aic79xx which look remarkably
similar, of course.

Re: request to add aic94xx to -mm

[Mike Anderson]

Christoph Hellwig <hch@infradead.org> wrote:
> On Fri, Apr 28, 2006 at 11:54:05AM -0500, James Bottomley wrote:
> > Could you send any bugs found back to linux-scsi (not the kernel
> > bugzilla)?
> 
> not a bug strictly speaking, but it should stop including the firmware
> blob and use request_firmware, similar to the discussion we had about
> qla2xxx recently.  It would be even nicer if adaptec continued publishing
> their sequencer code as with aic7xxx and aic79xx which look remarkably
> similar, of course.

I added Rob to this thread so he could comment on this.

It would also be good before we put another card through this process that
at least a few distros have the request_firmware infrastructure fully
functional. I have seen indications that there where a few bumps in the
road in getting this working.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: request to add aic94xx to -mm

[Christoph Hellwig]

On Fri, Apr 28, 2006 at 10:55:21AM -0700, Mike Anderson wrote:
> I added Rob to this thread so he could comment on this.
> 
> It would also be good before we put another card through this process that
> at least a few distros have the request_firmware infrastructure fully
> functional. I have seen indications that there where a few bumps in the
> road in getting this working.

at least suse has it working now after some initial problems.  let's hope
the supposedly market leader doesn't fall behind their competition here :)

Re: request to add aic94xx to -mm

[Hannes Reinecke]

Christoph Hellwig wrote:
> On Fri, Apr 28, 2006 at 10:55:21AM -0700, Mike Anderson wrote:
>> I added Rob to this thread so he could comment on this.
>>
>> It would also be good before we put another card through this process that
>> at least a few distros have the request_firmware infrastructure fully
>> functional. I have seen indications that there where a few bumps in the
>> road in getting this working.
> 
> at least suse has it working now after some initial problems.  let's hope
> the supposedly market leader doesn't fall behind their competition here :)

Well, _I_ for one wouldn't mind :-)

Speaking of which:
Rob, Mike, there are some PCI IDs missing in the driver.
Please make sure all cards are really supported.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux Products GmbH		S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: request to add aic94xx to -mm

[Arjan van de Ven]

On Fri, 2006-04-28 at 10:55 -0700, Mike Anderson wrote:
> Christoph Hellwig <hch@infradead.org> wrote:
> > On Fri, Apr 28, 2006 at 11:54:05AM -0500, James Bottomley wrote:
> > > Could you send any bugs found back to linux-scsi (not the kernel
> > > bugzilla)?
> > 
> > not a bug strictly speaking, but it should stop including the firmware
> > blob and use request_firmware, similar to the discussion we had about
> > qla2xxx recently.  It would be even nicer if adaptec continued publishing
> > their sequencer code as with aic7xxx and aic79xx which look remarkably
> > similar, of course.
> 
> I added Rob to this thread so he could comment on this.
> 
> It would also be good before we put another card through this process that
> at least a few distros have the request_firmware infrastructure fully
> functional. I have seen indications that there where a few bumps in the
> road in getting this working.

that's also a chicken-and-egg problem. Sometimes someone needs to start
to make an omelette ;)

Re: request to add aic94xx to -mm

[Christoph Hellwig]

There's also various issues around the sas code which aic94xx needs:

 - all the code should be renamed to libsas to make sure this is helpers
   for a host-based sas implementation, including the config option
 - the sas* headers should go directly to include/scsi/
 - sas_frames*.h need to be changed to avoid on the wite bitfields which
   are completely non-portable.  That'll cause quite a bit of churn all
   over the codebase unfortuantely.  some of those headers should be merged
   with the current scsi_transport_sas.h, e.g. the latter should lose various
   constants that are in sas.h
 - list_for_each_entry_reverse_safe from sas_discover.h should go to
   linux/list.h instead
 - struct domain_device is totally misnamed
 - sas_init_dev shouldn't be inline
 - in the sas headers generic on the wire stuff should be separated from
   libsas internals, e.g. most of sas_disocvery.h should become
   libsas_discovery.h or merged into libsas.h, but the smp defintions should
   go into a sas_smp.h or merged with sas_frames.h (why not sas_frame.h btw?)
   similar for sas_task.h
   generally I'd say all the headers currently in include/scsi/sas/ should
   probably be merged into just two:

    * include/scsi/sas.h for on the wire SAS defintions, best annotate with
      reference to what section in the standard they correspond to
    * include/scsi/libsas.h for all structures and prototypes of the host
      based sas code
 - drivers/scsi/sas/README needs to be updated to match reality and move
   to Documentation/
 - expander_conf.c should go away from the kernel tree.
 - sas_common.c seems to only contain duplicate code
   from scsi_transport_sas.c
 - all these //depot SCM comments should go
 - the priority queue implementation the long comment in sas_event.c
   talks about doesn't exist anymore, so kill it.  Also there's not a lot
   left in that file, and what's left doesn't make a lot of sense, as
   the one-element local sas_ha_event_fns array.  I'd suggest merging it
   into another
 - libsas should implement all methods in the sas_function_template.  They're
   supporting functionality that's in the SAS spec and are expected by
   userland to be present.  There should be no driver code involvded here,
   just libsas.  I'd move the actual template to the driver, though so
   a driver could override it, similar to what we do with the host template.
 - Various functions marked inline that shouldn't.  there's rarely a use
   for inlines except for ver ysmall functions
 - why don't sas_queue_event and as_begin_event use bitops?


this was just a quick 15 minute skip through the driver, once those are
addresses I'll do a real review.

Re: request to add aic94xx to -mm

[Jeff Garzik]

Christoph Hellwig wrote:
> There's also various issues around the sas code which aic94xx needs:
[snip]

Agree with most of these.  I think these would be best done in tree, 
rather than delaying the driver another year :)


> more comments on the actual aic94xx driver:
[snip

Agree with most of these.  Except for the debugging helper comment, IMO 
these should be handled pre-merge, while it's in -mm.

James, what is the canonical aic94xx home now?

	Jeff

Re: request to add aic94xx to -mm

[James Bottomley]

On Tue, 2006-05-02 at 11:07 -0400, Jeff Garzik wrote:
> James, what is the canonical aic94xx home now?

There's currently no canonical form.  The home of the development tree
that's feeding into -mm is aic94xx-sas-2.6.git but that will be
flattened before being merged into scsi-misc-2.6

James

Re: request to add aic94xx to -mm

[Christoph Hellwig]

more comments on the actual aic94xx driver:

 - the README file wouldn't contain much anymore after the outdated
   bits are removed, I'd suggest killing it and listing the supported
   hardware in the Kconfig instead
 - lots of inline abuse that should go away
 - please use the pci_iomap api to support pio and mmio transparently
   instead of the local wrappers
 - no need to handle signle-element SG lists anymore
 - CLEAR_NEXUS_PRE and CLEAR_NEXUS_POST should become real functions instead
   of context-sensitive macros
 - what about replacing ASD_DPRINTK with the standard debugging helpers?