[ANNOUNCE] MPT Fusion driver 3.02.06 update

[ANNOUNCE] MPT Fusion driver 3.02.06 update

[Moore, Eric Dean]

All,

We are pleased to announce the MPT Fusion release candidate for lk 2.6

Highlights of this release:
·	SAS Support - 1064, 1066, 1068
·	mpi headers v1.5.2
·	csmi ioctl support
·	MSI Support
·	fc_transport support
·	several patches incorporated from Christoph Hellwig 


This patch applied against bk://linux-scsi.bkbits.net/scsi-misc-2.6

Here is a link to this patch:
ftp://ftp.lsil.com/HostAdapterDrivers/linux/Fusion-MPT/2.6-kernel/3.02.06/mp
tlinux-3.02.06.patch


Full source and release notes are also provided at link above.

Eric Moore
LSI Logic Corporation



-
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: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Masao Fukuchi]

Hi Eric,

I installed Fusion MPT driver 3.02.06 into my tiger4(SR870BN4).
But I have some problems.

1.compile error
  When I compiled your driver with kernel 2.6.9, compile operation
  failed with error.
  I checked mptbase.c(and mptbase.h) and found your code shows:
   #if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,8))
         pci_save_state(pdev);
   #else
         pci_save_state(pdev, ioc->PciState);
   #endif
  But pci_save_state() in kernel 2.6.9 has two parameters.
  (I don't know which kernel version has 1 parameter)

2.startup sequence fail
  I fixed above problem temporarily and compiled it.
  The compile operation finished with no error.
  Then I started Linux, but the startup sequence failed with
  following error.
  >mptbase: Initiating ioc0 bringup
  >mptbase: ioc0: ERROR - Diagnostic reset FAILED! (142h)
  >mptbase: ioc0 NOT READY WARNING!
  >mptbase: WARNING - ioc0 did not initialize properly! (-1)
  >mptbase: probe of 0000:04:02.0 failed with error -1

  This message shows, IOC didn't become ready.
  The LSI53C1030 on Tiger4 has no flash ROM, I think the cause
  of the problem was fusion MPT driver didn' execute  Firmware
  Download Boot operation.

If you have any questions or comments, please let me know.

Thanks,
M.Fukuchi

Moore, Eric Dean wrote:
>All,
>
>We are pleased to announce the MPT Fusion release candidate for lk 2.6
>
>Highlights of this release:
>キ	SAS Support - 1064, 1066, 1068
>キ	mpi headers v1.5.2
>キ	csmi ioctl support
>キ	MSI Support
>キ	fc_transport support
>キ	several patches incorporated from Christoph Hellwig 
>
>
>This patch applied against bk://linux-scsi.bkbits.net/scsi-misc-2.6
>
>Here is a link to this patch:
>ftp://ftp.lsil.com/HostAdapterDrivers/linux/Fusion-MPT/2.6-kernel/3.02.06/mp
>tlinux-3.02.06.patch
>
>
>Full source and release notes are also provided at link above.
>
>Eric Moore
>LSI Logic Corporation
>
>
>
>-
>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: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Douglas Gilbert]

Moore, Eric Dean wrote:
> All,
> 
> We are pleased to announce the MPT Fusion release candidate for lk 2.6
> 
> Highlights of this release:
> ·	SAS Support - 1064, 1066, 1068

Eric,
Perhaps this would be a good time to define a
generic sas_transport layer.

> ·	mpi headers v1.5.2
> ·	csmi ioctl support
> ·	MSI Support
> ·	fc_transport support
> ·	several patches incorporated from Christoph Hellwig 
> 
> 
> This patch applied against bk://linux-scsi.bkbits.net/scsi-misc-2.6
> 
> Here is a link to this patch:
> ftp://ftp.lsil.com/HostAdapterDrivers/linux/Fusion-MPT/2.6-kernel/3.02.06/mp
> tlinux-3.02.06.patch
> 
> 
> Full source and release notes are also provided at link above.

Doug Gilbert
-
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: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Christoph Hellwig]

On Mon, Oct 25, 2004 at 07:32:35PM -0400, Moore, Eric Dean wrote:
> All,
> 
> We are pleased to announce the MPT Fusion release candidate for lk 2.6
> 
> Highlights of this release:
> ·	SAS Support - 1064, 1066, 1068
> ·	mpi headers v1.5.2
> ·	csmi ioctl support
> ·	MSI Support
> ·	fc_transport support
> ·	several patches incorporated from Christoph Hellwig 

Care to split it into small and reviewable per-topic patches that we have been
asking driver writers to provide for a long time?

-
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: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Christoph Hellwig]

On Mon, Oct 25, 2004 at 07:32:35PM -0400, Moore, Eric Dean wrote:
> All,
> 
> We are pleased to announce the MPT Fusion release candidate for lk 2.6

Some things that come to mind immediately:

> 
> 
> Highlights of this release:
> ·	SAS Support - 1064, 1066, 1068

there's still tons of ioc->chip_type checks for SPI vs FC vs SAS - 
please always use the new bus_type member


> ·	csmi ioctl support

rejected, this ioctl interface is completely horrible, even worse than
the fc hbaapi.  Please help to provide a proper sas transport class similar
to the fc one.

> ·	fc_transport support

please don't put this under all kinds of ifdefs, also it's not working with
current mainline anymore anyway.

Any reason there's no SPI transport attribute support, it's rather asymetric
this way..

-
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: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Moore, Eric Dean]

On Tuesday, October 26, 2004 4:38 AM, Christoph Hellwig wrote:
> On Mon, Oct 25, 2004 at 07:32:35PM -0400, Moore, Eric Dean wrote:
> > All,
> > 
> > We are pleased to announce the MPT Fusion release candidate 
> for lk 2.6
> 
> Some things that come to mind immediately:
> 
> > 
> > 
> > Highlights of this release:
> > ·	SAS Support - 1064, 1066, 1068
> 
> there's still tons of ioc->chip_type checks for SPI vs FC vs SAS - 
> please always use the new bus_type member
> 

I will fix this.

> 
> > ·	csmi ioctl support
> 
> rejected, this ioctl interface is completely horrible, even worse than
> the fc hbaapi.  Please help to provide a proper sas transport 
> class similar
> to the fc one.

This code code is ifdef'd with CPQ_CIM.  We currently have this is enabled
in the fusion Makefile. Instead would it be possible to have this disabled
for inclusion 
in the kernel?  Applications are in place now used by several customers
using this
interface, and it would be difficult to have this remove at this stage, as
our 
customers are so close to shipment of product. 

> 
> > ·	fc_transport support
> 
> please don't put this under all kinds of ifdefs, also it's 
> not working with
> current mainline anymore anyway.

I don't know what you mean.  The fc_transport stuff was just added two weeks
ago.  This was added by request of Jeremy Higdon.  This reports
the port_id, port_name, and node_name.  This support is enabled in
the fusion Makefile by MPT_ENABLE_FC_TRANSPORT. Its currently disabled for
reason (1) the transport layer is only available after 2.6.6 kernel, and
we are supporting kernels older such as SUSE 9.1 and SLES9, (2)
we would not be able to build driver update disks due to the dependancy
of fc_transport.ko. 

> 
> Any reason there's no SPI transport attribute support, it's 
> rather asymetric
> this way..
> 

We are investigating into this, such as domain validation.  
What other attributes do you suggest?
 
-
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: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Christoph Hellwig]

> This code code is ifdef'd with CPQ_CIM.  We currently have this is enabled
> in the fusion Makefile. Instead would it be possible to have this disabled
> for inclusion 
> in the kernel?  Applications are in place now used by several customers
> using this
> interface, and it would be difficult to have this remove at this stage, as
> our 
> customers are so close to shipment of product. 

This code isn't acceptable for kernel inclusion at all, dito for the
hooks it needs (e.g. the sas device list)

> > please don't put this under all kinds of ifdefs, also it's 
> > not working with
> > current mainline anymore anyway.
> 
> I don't know what you mean.  The fc_transport stuff was just added two weeks
> ago.  This was added by request of Jeremy Higdon.  This reports
> the port_id, port_name, and node_name.  This support is enabled in
> the fusion Makefile by MPT_ENABLE_FC_TRANSPORT. Its currently disabled for
> reason (1) the transport layer is only available after 2.6.6 kernel, and
> we are supporting kernels older such as SUSE 9.1 and SLES9, (2)
> we would not be able to build driver update disks due to the dependancy
> of fc_transport.ko. 

But the policy is to keep such ifdefs out of kernel drivers.  If SuSE
wants current FC drivers backported they'll need to backpor the full
transport attr infrastructure.

Also as I mentioned this code doesn't compile on 2.6.10-rc at all.

> > Any reason there's no SPI transport attribute support, it's 
> > rather asymetric
> > this way..
> > 
> 
> We are investigating into this, such as domain validation.  
> What other attributes do you suggest?

if possible all that are define, see include/scsi/scsi_transport_spi.h
in a current kernel.

RE: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Moore, Eric Dean]

> > This code code is ifdef'd with CPQ_CIM.  We currently have 
> this is enabled
> > in the fusion Makefile. Instead would it be possible to 
> have this disabled
> > for inclusion 
> > in the kernel?  Applications are in place now used by 
> several customers
> > using this
> > interface, and it would be difficult to have this remove at 
> this stage, as
> > our 
> > customers are so close to shipment of product. 
> 
> This code isn't acceptable for kernel inclusion at all, dito for the
> hooks it needs (e.g. the sas device list)
> 

We have to ship with these IOCTLS. Are there any compromise?
Sounds like you shot down my backup idea; e.g putting this code into 
seperate file which isn't provided for inclusion, but can be recompiled 
to link into mptctl?  I don't think we time to pursue your the idea of 
re-invent everything into the sas-transport layer.
 
> > > please don't put this under all kinds of ifdefs, also it's 
> > > not working with
> > > current mainline anymore anyway.
> > 
> > I don't know what you mean.  The fc_transport stuff was 
> just added two weeks
> > ago.  This was added by request of Jeremy Higdon.  This reports
> > the port_id, port_name, and node_name.  This support is enabled in
> > the fusion Makefile by MPT_ENABLE_FC_TRANSPORT. Its 
> currently disabled for
> > reason (1) the transport layer is only available after 
> 2.6.6 kernel, and
> > we are supporting kernels older such as SUSE 9.1 and SLES9, (2)
> > we would not be able to build driver update disks due to 
> the dependancy
> > of fc_transport.ko. 
> 
> But the policy is to keep such ifdefs out of kernel drivers.  If SuSE
> wants current FC drivers backported they'll need to backpor the full
> transport attr infrastructure.
> 
> Also as I mentioned this code doesn't compile on 2.6.10-rc at all.
> 


Jeremy Higdon asked me to add this, not SuSE.

We provide pre-built drivers to customers that ship Suse on
their servers, and having fc attributes enabled in the driver
means the driver fail's to compile in the older versions of the
kernel.  

The failures to compiled in 2.6.10-rc is due to someone changing
the defines in scsi_transport_fc.h.

2.6.9				2.6.10-rc				
---------			---------
fc_port_id			fc_starget_port_id
fc_node_name		fc_starget_node_name
fc_port_name		fc_starget_port_name
		

Re: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Christoph Hellwig]

> > hooks it needs (e.g. the sas device list)
> > 
> 
> We have to ship with these IOCTLS. Are there any compromise?
> Sounds like you shot down my backup idea; e.g putting this code into 
> seperate file which isn't provided for inclusion, but can be recompiled 
> to link into mptctl?  I don't think we time to pursue your the idea of 
> re-invent everything into the sas-transport layer.

No way.  This is similar to the hbaapi situation with qlogic and emulex.
If you had worked with us early on on an API like I told you multiple times
we'd have something sane now.

Btw, what part of HP badly wants this?  I'm sure Grant and Matthew
could explain them internally what a bad idea this is.

>
> Jeremy Higdon asked me to add this, not SuSE.

Jeremy, can you make sure SuSE has an uptodate transport attribute
implementation ?

RE: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[James.Smart]

> The failures to compiled in 2.6.10-rc is due to someone changing
> the defines in scsi_transport_fc.h.
> 
> 2.6.9				2.6.10-rc				
> ---------			---------
> fc_port_id			fc_starget_port_id
> fc_node_name		fc_starget_node_name
> fc_port_name		fc_starget_port_name

Then you haven't been paying attention to linux-scsi. As part of Emulex's desire to move upstream, and commonize FC information, the transport got corrected so that the 3 attributes are target based rather than sdev based. See the following patch (http://marc.theaimsgroup.com/?l=linux-scsi&m=109663907926965&w=2). This became part of 2.6.9-bk1/2.6.10-rc. Also - I've proposed more attributes to the host to better align with FC HBAAPI management infrastructures - see the following patches: http://marc.theaimsgroup.com/?l=linux-scsi&m=109776541400698&w=2; http://marc.theaimsgroup.com/?l=linux-scsi&m=109776541525816&w=2; http://marc.theaimsgroup.com/?l=linux-scsi&m=109813309907129&w=2.

There are still more attributes coming, as the target/remote port attributes get expanded. Now that I know you're support the FC transport, I'll involve you in the discussions.

-- James

Re: [ANNOUNCE] MPT Fusion driver 3.02.06 update

[Jeremy Higdon]

On Tue, Oct 26, 2004 at 06:15:25PM +0100, Christoph Hellwig wrote:
> > > hooks it needs (e.g. the sas device list)
> > > 
> > 
> > We have to ship with these IOCTLS. Are there any compromise?
> > Sounds like you shot down my backup idea; e.g putting this code into 
> > seperate file which isn't provided for inclusion, but can be recompiled 
> > to link into mptctl?  I don't think we time to pursue your the idea of 
> > re-invent everything into the sas-transport layer.
> 
> No way.  This is similar to the hbaapi situation with qlogic and emulex.
> If you had worked with us early on on an API like I told you multiple times
> we'd have something sane now.
> 
> Btw, what part of HP badly wants this?  I'm sure Grant and Matthew
> could explain them internally what a bad idea this is.
> 
> >
> > Jeremy Higdon asked me to add this, not SuSE.
> 
> Jeremy, can you make sure SuSE has an uptodate transport attribute
> implementation ?

I doubt it.  It was recently updated from the 2.6.5 to 2.6.9 version,
and I don't think they'll be updating to the 2.6.10 version.

Eric, I guess you'll have to convert to the new 2.6.10 API.  Once
it's in the tree, any API changes should be made for you.  For the
drivers that you deliver (as opposed to the distribution), you can
just #ifdef it out, in much the same way that the drivers on Qlogic's
website have more #ifdefs.

It is annoying to have these API changes come in asynchronously.  I
would have preferred something that didn't break backward compatibility,
but linking it to the target instead of the lun probably doesn't allow
that.  Hopefully it will settle down a bit now.

jeremy

CSMI [was: Re: [ANNOUNCE] MPT Fusion driver 3.02.06 update]

[Douglas Gilbert]

Christoph Hellwig wrote:
> On Mon, Oct 25, 2004 at 07:32:35PM -0400, Moore, Eric Dean wrote:
> 
>>All,
>>
>>We are pleased to announce the MPT Fusion release candidate for lk 2.6
> 
> 
> Some things that come to mind immediately:
> 
> 
>>
>>Highlights of this release:
>>·	SAS Support - 1064, 1066, 1068
> 
> 
> there's still tons of ioc->chip_type checks for SPI vs FC vs SAS - 
> please always use the new bus_type member
> 
> 
> 
>>·	csmi ioctl support
> 
> 
> rejected, this ioctl interface is completely horrible, even worse than
> the fc hbaapi.  Please help to provide a proper sas transport class similar
> to the fc one.

Christoph,
I'm not so sure why you want to reject this ioctl
at this stage when our existing infrastructure to handle
the 4 protocols that go through this SAS HBA is weak.
Those 4 protocols are:
   a) SSP (SCSI over a SAS transport) we should be able to
      handle this one ***  ****
   b) SMP is a packet like protocol meant mainly to probe
      and control expanders (think device discovery). The
      "target" is not necessarily a SCSI device and there
      is no concept of luns. Nice candidate for the sg driver.
   c) STP: ATA/ATAPI-7 tunnelled through a SAS transport with
      a SAS/sATA bridge probably hiding in an expander
   d) sATA: direct connect of a sATA disk to this SAS HBA

The t10 meeting next week will be considering the
"Common Storage Management Interface for SAS" (CSMI)
proposal. Here is a url for it:
ftp://ftp.t10.org/t10/document.04/04-284r0.pdf
This document names 3 target platforms: Windows, Linux
(2.4 and 2.6 series) and Netware.

This seems like a serious attempt to retrofit a control
(and passthrough) interface into existing OS SCSI stacks
at the LLD level. I have no information but I would expect
the Adaptec SAS HBA (when and if its Open source driver
becomes public) to follow the same (or a similar) route.


*** The primary SAS device identifier is a 64 bit SAS address
(naa 5, world wide unique). CSMI defines mapping functions
between the <h,c,t> like tuples that most OSes use in their
SCSI stacks (thanks to SPI) and SAS addresses. In short the CSMI
proposal looks like the distilled experience of writing real
SAS HBA drivers for several existing OSes.

**** Given the BCC (bridge controller commands) draft at t10
it would appear that SAS disk enclosure designers want to
command set convert ATA/ATAPI-7 into SPC in the enclosure.
That way sATA disks will appear as SAS disks (with a SCSI-ATA
pass-through command for awkward things like SMART). Such a
move would make the STP protocol superfluous.

Doug Gilbert
-
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: CSMI [was: Re: [ANNOUNCE] MPT Fusion driver 3.02.06 update]

[Christoph Hellwig]

On Fri, Nov 05, 2004 at 10:55:27AM +1000, Douglas Gilbert wrote:
> Christoph,
> I'm not so sure why you want to reject this ioctl
> at this stage when our existing infrastructure to handle
> the 4 protocols that go through this SAS HBA is weak.

Rationale:

 a) we're not gonna add another ioctl interface at this stage, especially
    not a that clumsy one
 b) things that are common for all SAS HBAs should not be in the LLDD but
    in a transport class