[SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[Moore, Eric Dean]

Highlights for this release:

In addition to SAS support =>

* Christoph's Requested Changes:

·	Changing how command line options are passed, 
passing the mptscsih string has been removed. Use modinfo
to see usage and description of the new parameters.
·	Removed IOCTL mptctl_hba_pciinfo 
·	Removed mptscsih_slave_destroy vdev != NULL check fixed 
by removing the DEVICE_NOT_THERE calling of same function.
. 	Replaced ioc_chip with bus_type.
. 	kill one MPTSCSIH_DBG_TIMEOUT in ->queuecommand
. 	removed TRUE/FALSE defines in mptctl.h

Please review, and send me your suggestions for other changes.


This patch applied against bk://linux-scsi.bkbits.net/scsi-misc-2.6
ftp://ftp.lsil.com/HostAdapterDrivers/linux/Fusion-MPT/2.6-kernel/3.02.07.02
/mptlinux-3.02.07.02.patch

Regards,
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: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[James Bottomley]

On Fri, 2004-11-12 at 17:15, Moore, Eric Dean wrote:
> Highlights for this release:
> 
> In addition to SAS support =>
> 

Actually, before we begin on a SAS implementation, I'd rather like us to
get the architecture and design correct.  Reading all the SAS and SATA
documentation is still on my todo list.  However, this is my brief take
on the architecture:

SAS itself is a bit of a monster because the PHY layer characteristics
are identical to those of SATA.  Therefore, it seems like we need two
separate transport classes, one for the PHY layer which would control
the PHY transport characteristics and would be shareable with SATA and
one for SAS only which would cover a large swath of the SAS specific
ioctls and the useful bits of CMSI.

As far as the controller and expander protocols to which Doug Gilbert
has been referring, I really have no current idea how to do them, but if
anyone else does now would be a good time to say something.

So does the above look like an acceptable way to move forward? (having a
PHY transport class is going to mean changes in both SCSI and SATA and
probably block as well, since this may ultimately not be a SCSI specific
transport class).

James

RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[Moore, Eric Dean]

Here are my concerns:

(1) In addition to PHY, there is a link layer. How about
a transport layer for that?  Some of the things we report
are { Current/Previous Negotiated Link Rate, Phy enable/disable, SATA OOB
complete,
Invalid Dword Count, Loss  Dword Sync Count, Phy Reset Problem Count }.

(2) Reporting PHYS that are not direct attached to HBA; e.g. SMP Protocal
for Exander Management.  This SMP passthru is addressed by the SAS Address. 
How can the SAS address be sent down to the LLDs?

(3) SATA Drives in SAS topology - STP/SATA Passthru Protocal need to report
such
things as SMART DATA, Identify DATA, etc.   This is address by target, bus,
channel.
How SATA/IDE info be made available to upper transport layers?

(4) Douglas concern on dual ported SAS drives in /dev/sg?? multipath eh?

Eric

Monday, November 15, 2004 11:01 AM, James Bottomley wrote:

> 
> 
> On Fri, 2004-11-12 at 17:15, Moore, Eric Dean wrote:
> > Highlights for this release:
> > 
> > In addition to SAS support =>
> > 
> 
> Actually, before we begin on a SAS implementation, I'd rather 
> like us to
> get the architecture and design correct.  Reading all the SAS and SATA
> documentation is still on my todo list.  However, this is my 
> brief take
> on the architecture:
> 
> SAS itself is a bit of a monster because the PHY layer characteristics
> are identical to those of SATA.  Therefore, it seems like we need two
> separate transport classes, one for the PHY layer which would control
> the PHY transport characteristics and would be shareable with SATA and
> one for SAS only which would cover a large swath of the SAS specific
> ioctls and the useful bits of CMSI.
> 
> As far as the controller and expander protocols to which Doug Gilbert
> has been referring, I really have no current idea how to do 
> them, but if
> anyone else does now would be a good time to say something.
> 
> So does the above look like an acceptable way to move 
> forward? (having a
> PHY transport class is going to mean changes in both SCSI and SATA and
> probably block as well, since this may ultimately not be a 
> SCSI specific
> transport class).
> 
> James
> 
> 

RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[James Bottomley]

On Mon, 2004-11-15 at 16:15, Moore, Eric Dean wrote:
> (1) In addition to PHY, there is a link layer. How about
> a transport layer for that?  Some of the things we report
> are { Current/Previous Negotiated Link Rate, Phy enable/disable, SATA OOB
> complete,
> Invalid Dword Count, Loss  Dword Sync Count, Phy Reset Problem Count }.

This isn't an exercise to expose all the layers in the transport, merely
to separate them out logically when it's useful to do so.  Thus, it
would make sense to expose the link layer separately only if something
other than a PHY were going to be using it.  If that's not the case,
then link transport parameters can be safely stashed in the PHY layer.

> (2) Reporting PHYS that are not direct attached to HBA; e.g. SMP Protocal
> for Exander Management.  This SMP passthru is addressed by the SAS Address. 
> How can the SAS address be sent down to the LLDs?

That was what this bit of my email was about:

> As far as the controller and expander protocols to which Doug Gilbert
> has been referring, I really have no current idea how to do 
> them, but if
> anyone else does now would be a good time to say something.

Although really, the simplest way is a protocol to allow direct
attachment of a remote PHY (sort of like a variant of the scan interface
under the scsi_host class).

> (3) SATA Drives in SAS topology - STP/SATA Passthru Protocal need to report
> such
> things as SMART DATA, Identify DATA, etc.   This is address by target, bus,
> channel.
> How SATA/IDE info be made available to upper transport layers?

surely if we have a SATA device at the end (even if we reach the end
point traversing a SAS domain) then you simply use SG_IO to transport
the device native commands and the HBA does the correct thing for
encapsulation.

> (4) Douglas concern on dual ported SAS drives in /dev/sg?? multipath eh?

Well, that's identical to FC drives which are also dual ported, so the
solution should be the same (dm-multipath).

James

RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[Moore, Eric Dean]

On Monday, November 15, 2004 3:51 PM, James Bottomley wrote:

> This isn't an exercise to expose all the layers in the 
> transport, merely
> to separate them out logically when it's useful to do so.  Thus, it
> would make sense to expose the link layer separately only if something
> other than a PHY were going to be using it.  If that's not the case,
> then link transport parameters can be safely stashed in the PHY layer.

I open to debate on this.  The link info is going to be providing properties
between two phys.

> Although really, the simplest way is a protocol to allow direct
> attachment of a remote PHY (sort of like a variant of the 
> scan interface
> under the scsi_host class).
> 

Would the "scan interface" be able to call the LLD drivers
with a SAS Address?  Here is our SMP passthru struct:

typedef struct _MSG_SMP_PASSTHROUGH_REQUEST
{
    U8                      PassthroughFlags;   /* 00h */
    U8                      PhysicalPort;       /* 01h */
    U8                      ChainOffset;        /* 02h */
    U8                      Function;           /* 03h */
    U16                     RequestDataLength;  /* 04h */
    U8                      ConnectionRate;     /* 06h */
    U8                      MsgFlags;           /* 07h */
    U32                     MsgContext;         /* 08h */
    U32                     Reserved1;          /* 0Ch */
    U64                     SASAddress;         /* 10h */
    U32                     Reserved2;          /* 18h */
    U32                     Reserved3;          /* 1Ch */
    SGE_SIMPLE_UNION        SGL;                /* 20h */
} MSG_SMP_PASSTHROUGH_REQUEST, MPI_POINTER PTR_MSG_SMP_PASSTHROUGH_REQUEST,
  SmpPassthroughRequest_t, MPI_POINTER pSmpPassthroughRequest_t;


> > (3) SATA Drives in SAS topology - STP/SATA Passthru 
> Protocal need to report
> > such
> > things as SMART DATA, Identify DATA, etc.   This is address 
> by target, bus,
> > channel.
> > How SATA/IDE info be made available to upper transport layers?
> 
> surely if we have a SATA device at the end (even if we reach the end
> point traversing a SAS domain) then you simply use SG_IO to transport
> the device native commands and the HBA does the correct thing for
> encapsulation.
> 

Our firmware does the SATA to SCSI translation.  Thus to the device driver
all devices in SAS domain look like SCSI devices.  Does SG_IO have
capability in sending a SATA/IDE Task Frame encapsulated in 
a FIS to a SCSI LLD?  I believe the SG_IO would end up calling 
the sh->queuecommand entry point via scsi mid layer. The input to
the LLD is struct scsi_cmnd, passing a SCSI cdb[16].  I don't see
a FIS in struct scsi_cmnd.  I guess if that is the plan, we would
need to add FIS in this structure, and the LLDs would need to differentiate
SATA from SCSI commands.

Here is our SATA/STP passthru struct:


typedef struct _MSG_SATA_PASSTHROUGH_REQUEST
{
    U8                      TargetID;           /* 00h */
    U8                      Bus;                /* 01h */
    U8                      ChainOffset;        /* 02h */
    U8                      Function;           /* 03h */
    U16                     PassthroughFlags;   /* 04h */
    U8                      ConnectionRate;     /* 06h */
    U8                      MsgFlags;           /* 07h */
    U32                     MsgContext;         /* 08h */
    U32                     Reserved1;          /* 0Ch */
    U32                     Reserved2;          /* 10h */
    U32                     Reserved3;          /* 14h */
    U32                     DataLength;         /* 18h */
    U8                      CommandFIS[20];     /* 1Ch */
    SGE_SIMPLE_UNION        SGL;                /* 30h */
} MSG_SATA_PASSTHROUGH_REQUEST, MPI_POINTER
PTR_MSG_SATA_PASSTHROUGH_REQUEST,
  SataPassthroughRequest_t, MPI_POINTER pSataPassthroughRequest_t; 

Re: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[Jeff Garzik]

Moore, Eric Dean wrote:
> On Monday, November 15, 2004 3:51 PM, James Bottomley wrote:
> 
> 
>>This isn't an exercise to expose all the layers in the 
>>transport, merely
>>to separate them out logically when it's useful to do so.  Thus, it
>>would make sense to expose the link layer separately only if something
>>other than a PHY were going to be using it.  If that's not the case,
>>then link transport parameters can be safely stashed in the PHY layer.
> 
> 
> I open to debate on this.  The link info is going to be providing properties
> between two phys.
> 
> 
>>Although really, the simplest way is a protocol to allow direct
>>attachment of a remote PHY (sort of like a variant of the 
>>scan interface
>>under the scsi_host class).
>>
> 
> 
> Would the "scan interface" be able to call the LLD drivers
> with a SAS Address?  Here is our SMP passthru struct:
> 
> typedef struct _MSG_SMP_PASSTHROUGH_REQUEST
> {
>     U8                      PassthroughFlags;   /* 00h */
>     U8                      PhysicalPort;       /* 01h */
>     U8                      ChainOffset;        /* 02h */
>     U8                      Function;           /* 03h */
>     U16                     RequestDataLength;  /* 04h */
>     U8                      ConnectionRate;     /* 06h */
>     U8                      MsgFlags;           /* 07h */
>     U32                     MsgContext;         /* 08h */
>     U32                     Reserved1;          /* 0Ch */
>     U64                     SASAddress;         /* 10h */
>     U32                     Reserved2;          /* 18h */
>     U32                     Reserved3;          /* 1Ch */
>     SGE_SIMPLE_UNION        SGL;                /* 20h */
> } MSG_SMP_PASSTHROUGH_REQUEST, MPI_POINTER PTR_MSG_SMP_PASSTHROUGH_REQUEST,
>   SmpPassthroughRequest_t, MPI_POINTER pSmpPassthroughRequest_t;


Overall, what is needed is 'host control', which can include device 
topology manipulation.


> Our firmware does the SATA to SCSI translation.  Thus to the device driver
> all devices in SAS domain look like SCSI devices.  Does SG_IO have
> capability in sending a SATA/IDE Task Frame encapsulated in 
> a FIS to a SCSI LLD?  I believe the SG_IO would end up calling 
> the sh->queuecommand entry point via scsi mid layer. The input to
> the LLD is struct scsi_cmnd, passing a SCSI cdb[16].  I don't see
> a FIS in struct scsi_cmnd.  I guess if that is the plan, we would
> need to add FIS in this structure, and the LLDs would need to differentiate
> SATA from SCSI commands.

ATA passthru CDB is specified in
http://www.t10.org/ftp/t10/document.04/04-262r6.pdf

This is what libata uses.

	Jeff

Re: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[Luben Tuikov]

Jeff Garzik wrote:
> 
> Overall, what is needed is 'host control', which can include device
> topology manipulation.
> 

Yes, I agree.

So would it be wise to conclude that an "extension" to the LLDD
methods would be needed.  I think this is what SDI would end up being.
Host/Bus/target/lun woulnd't merely be enough, albeit only in the
core of the OS.  HBTL translation is one of the points SDI addresses.

	Luben

RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[James Bottomley]

On Mon, 2004-11-15 at 18:11, Moore, Eric Dean wrote:
> On Monday, November 15, 2004 3:51 PM, James Bottomley wrote:
> 
> > This isn't an exercise to expose all the layers in the 
> > transport, merely
> > to separate them out logically when it's useful to do so.  Thus, it
> > would make sense to expose the link layer separately only if something
> > other than a PHY were going to be using it.  If that's not the case,
> > then link transport parameters can be safely stashed in the PHY layer.
> 
> I open to debate on this.  The link info is going to be providing properties
> between two phys.

Right, but phys are essentially point to point, so the link info is also
a property of the local HBA phy.

> Would the "scan interface" be able to call the LLD drivers
> with a SAS Address?  Here is our SMP passthru struct:
> 
> typedef struct _MSG_SMP_PASSTHROUGH_REQUEST
> {
[...]
> } MSG_SMP_PASSTHROUGH_REQUEST, MPI_POINTER PTR_MSG_SMP_PASSTHROUGH_REQUEST,
>   SmpPassthroughRequest_t, MPI_POINTER pSmpPassthroughRequest_t;

Actually, no.  What you're wanting is a network type of connection (open
HBA and send an addressed packet).  What I'm proposing is more like a
connected socket model: We expose in the transport class a file that
understands the addressing (like the scan file in the scsi_host class). 
You send a command to this asking for the transport specific address to
be attached and it appears as a device node.  You communicate with the
device node using SG_IO and remove it again when you've finished.  So,
the packets you send to the device node are pure commands and have no
need of any addressing or topology information (and hence can be well
understood by SCSI or SATA.

James