ATA_16 support on mptsas

ATA_16 support on mptsas

[Krzysztof Błaszkowski]

Hello,

I found that any HDIO_DRIVE_CMD ioctl on sata drive connected through mpsas 
and backplane will fail. Basically the scsi_host_template structure is 
missing ioctl callback. after adding it and temporary tweaking domain_device 
structure associated to scsi_device (rphy only) i reached a point where 
ata_scsi_ioctl returns EIO and this why i need some clue on a way of adding 
such support similar way to aic94 where it has been done.

I found also that mptsas leaves domain_device rather uninitialized. the 
example is rphy but there more fields i don't know if they are revelant to 
proper processing of HDIO_DRIVE_CMD.
i need additional references on libata design, call flow and structures 
relationship.

probably it would be the best to design mptsas from scratch using libsas but 
this seems to me as huge work although if i was guided i would probably 
complete this.


I tried another approach where i used SG_IO ioctl and prepared ATA_16 cdb 
(just like libata does) but this failed on mptsas connected drives too 
altough this way works on drives connected to ICH6.

Regards,
Krzysztof Blaszkowski

RE: ATA_16 support on mptsas

[Moore, Eric]

On Monday, June 23, 2008 10:00 AM, Krzysztof Błaszkowski wrote:
>
> I found that any HDIO_DRIVE_CMD ioctl on sata drive connected
> through mpsas
> and backplane will fail. Basically the scsi_host_template structure is
> missing ioctl callback. after adding it and temporary
> tweaking domain_device
> structure associated to scsi_device (rphy only) i reached a
> point where
> ata_scsi_ioctl returns EIO and this why i need some clue on a
> way of adding
> such support similar way to aic94 where it has been done.
>
> I found also that mptsas leaves domain_device rather
> uninitialized. the
> example is rphy but there more fields i don't know if they
> are revelant to
> proper processing of HDIO_DRIVE_CMD.
> i need additional references on libata design, call flow and
> structures
> relationship.
>
> probably it would be the best to design mptsas from scratch
> using libsas but
> this seems to me as huge work although if i was guided i
> would probably
> complete this.
>

We have no plans to implement HDIO ioctls in our driver.   The SATL implementation is inside the mpt fusion firmware, and from the driver, we don't care whether the underlying protocal is SAS, SATA, Fibre Channel, or SPI.   For all protocals, we send scsi commands to the controller firmware using SCSI_IO opcode, with the following struct:

typedef struct _MSG_SCSI_IO_REQUEST
{
    U8                      TargetID;           /* 00h */
    U8                      Bus;                /* 01h */
    U8                      ChainOffset;        /* 02h */
    U8                      Function;           /* 03h */
    U8                      CDBLength;          /* 04h */
    U8                      SenseBufferLength;  /* 05h */
    U8                      Reserved;           /* 06h */
    U8                      MsgFlags;           /* 07h */
    U32                     MsgContext;         /* 08h */
    U8                      LUN[8];             /* 0Ch */
    U32                     Control;            /* 14h */
    U8                      CDB[16];            /* 18h */
    U32                     DataLength;         /* 28h */
    U32                     SenseBufferLowAddr; /* 2Ch */
    SGE_IO_UNION            SGL;                /* 30h */
} MSG_SCSI_IO_REQUEST, MPI_POINTER PTR_MSG_SCSI_IO_REQUEST,
  SCSIIORequest_t, MPI_POINTER pSCSIIORequest_t;

>
> I tried another approach where i used SG_IO ioctl and
> prepared ATA_16 cdb
> (just like libata does) but this failed on mptsas connected drives too
> altough this way works on drives connected to ICH6.
>

The SG tools will work with mpt fusion if your passing the ATA_12 (opcode=0xA1) and ATA_16 (opcode=0x85).   This is implemented in fusion firmware.  If your failing, then your probably having old firmware.  I suggest that you upgrading by going to the download site  located here: http://www.lsi.com/cm/DownloadSearch.do?locale=EN.    Ken Stewart is from support, he should be able to assist you with upgrading the firmware if you encounter any problems.

Eric Moore

RE: ATA_16 support on mptsas

[Richard Scobie]

Eric Moore wrote:

 > The SG tools will work with mpt fusion if your passing the ATA_12
 > (opcode=0xA1) and ATA_16 (opcode=0x85).   This is implemented in
 > fusion firmware.  If your failing, then your probably having old
 > firmware.  I suggest that you upgrading by going to the download
 > site located here: http://www.lsi.com/cm/DownloadSearch.do?locale=EN.
 > Ken Stewart is from support, he should be able to assist you with
 > upgrading the firmware if you encounter any problems.

Hi Eric,

I have already logged a bug with Fedora, but can you think of anything 
that would have changed between 2.6.25.4 and 2.6.25.6 that would have 
broken this?

I have just updated from 2.6.25.4-30.fc9.x86_64 to 
2.6.25.6-55.fc9.x86_64 and smartmontools now causes LSISAS1068E 
controller resets, where it was working perfectly before:

mptscsih: ioc0: attempting task abort! (sc=ffff81023d0c6b40)
sd 4:0:0:0: [sdc] CDB: ATA command pass through(16): 85 08 0e 00 00 00 
01 00 00
00 00 00 00 00 ec 00
mptbase: ioc0: LogInfo(0x31140000): Originator={PL}, Code={IO Executed},
SubCode(0x0000)
mptscsih: ioc0: task abort: SUCCESS (sc=ffff81023d0c6b40)
mptscsih: ioc0: attempting task abort! (sc=ffff81023d0c6b40)
sd 4:0:0:0: [sdc] CDB: Test Unit Ready: 00 00 00 00 00 00
mptbase: ioc0: LogInfo(0x31130000): Originator={PL}, Code={IO Not Yet 
Executed},
SubCode(0x0000)
mptscsih: ioc0: task abort: SUCCESS (sc=ffff81023d0c6b40)
mptscsih: ioc0: attempting target reset! (sc=ffff81023d0c6b40)
sd 4:0:0:0: [sdc] CDB: ATA command pass through(16): 85 08 0e 00 00 00 
01 00 00
00 00 00 00 00 ec 00
mptscsih: ioc0: target reset: SUCCESS (sc=ffff81023d0c6b40)
mptscsih: ioc0: attempting task abort! (sc=ffff81023d0c6b40)
sd 4:0:0:0: [sdc] CDB: Test Unit Ready: 00 00 00 00 00 00
mptbase: ioc0: LogInfo(0x31130000): Originator={PL}, Code={IO Not Yet 
Executed},
SubCode(0x0000)
mptscsih: ioc0: task abort: SUCCESS (sc=ffff81023d0c6b40)
mptscsih: ioc0: attempting bus reset! (sc=ffff81023d0c6b40)
sd 4:0:0:0: [sdc] CDB: ATA command pass through(16): 85 08 0e 00 00 00 
01 00 00
00 00 00 00 00 ec 00
mptscsih: ioc0: bus reset: SUCCESS (sc=ffff81023d0c6b40)
mptscsih: ioc0: attempting task abort! (sc=ffff81023d0c6b40)
sd 4:0:0:0: [sdc] CDB: Test Unit Ready: 00 00 00 00 00 00
mptbase: ioc0: LogInfo(0x31130000): Originator={PL}, Code={IO Not Yet 
Executed},
SubCode(0x0000)
mptscsih: ioc0: task abort: SUCCESS (sc=ffff81023d0c6b40)
mptscsih: ioc0: attempting host reset! (sc=ffff81023d0c6b40)
mptbase: ioc0: Initiating recovery
mptscsih: ioc0: host reset: SUCCESS (sc=ffff81023d0c6b40)
sd 4:0:0:0: Device offlined - not ready after error recovery
program smartd is using a deprecated SCSI ioctl, please convert it to SG_IO

smartd.conf entries are in the form:

/dev/sdc -d sat,16 -a -I 194 -s L/../../1/01

and all drives behind the controller do the same.

Regards,

Richard

Re: ATA_16 support on mptsas

[Krzysztof Błaszkowski]

Hello,

ATA_16 through SG is supported with recent firmware for LSI cards.
I verified non-dma/pio ATA commands only.

Regards,
Krzysztof Blaszkowski

On Monday 23 June 2008 21:40, Moore, Eric wrote:
> On Monday, June 23, 2008 10:00 AM, Krzysztof Błaszkowski wrote:
> > I found that any HDIO_DRIVE_CMD ioctl on sata drive connected
> > through mpsas
> > and backplane will fail. Basically the scsi_host_template structure is
> > missing ioctl callback. after adding it and temporary
> > tweaking domain_device
> > structure associated to scsi_device (rphy only) i reached a
> > point where
> > ata_scsi_ioctl returns EIO and this why i need some clue on a
> > way of adding
> > such support similar way to aic94 where it has been done.
> >
> > I found also that mptsas leaves domain_device rather
> > uninitialized. the
> > example is rphy but there more fields i don't know if they
> > are revelant to
> > proper processing of HDIO_DRIVE_CMD.
> > i need additional references on libata design, call flow and
> > structures
> > relationship.
> >
> > probably it would be the best to design mptsas from scratch
> > using libsas but
> > this seems to me as huge work although if i was guided i
> > would probably
> > complete this.
>
> We have no plans to implement HDIO ioctls in our driver.   The SATL
> implementation is inside the mpt fusion firmware, and from the driver, we
> don't care whether the underlying protocal is SAS, SATA, Fibre Channel, or
> SPI.   For all protocals, we send scsi commands to the controller firmware
> using SCSI_IO opcode, with the following struct:
>
> typedef struct _MSG_SCSI_IO_REQUEST
> {
>     U8                      TargetID;           /* 00h */
>     U8                      Bus;                /* 01h */
>     U8                      ChainOffset;        /* 02h */
>     U8                      Function;           /* 03h */
>     U8                      CDBLength;          /* 04h */
>     U8                      SenseBufferLength;  /* 05h */
>     U8                      Reserved;           /* 06h */
>     U8                      MsgFlags;           /* 07h */
>     U32                     MsgContext;         /* 08h */
>     U8                      LUN[8];             /* 0Ch */
>     U32                     Control;            /* 14h */
>     U8                      CDB[16];            /* 18h */
>     U32                     DataLength;         /* 28h */
>     U32                     SenseBufferLowAddr; /* 2Ch */
>     SGE_IO_UNION            SGL;                /* 30h */
> } MSG_SCSI_IO_REQUEST, MPI_POINTER PTR_MSG_SCSI_IO_REQUEST,
>   SCSIIORequest_t, MPI_POINTER pSCSIIORequest_t;
>
> > I tried another approach where i used SG_IO ioctl and
> > prepared ATA_16 cdb
> > (just like libata does) but this failed on mptsas connected drives too
> > altough this way works on drives connected to ICH6.
>
> The SG tools will work with mpt fusion if your passing the ATA_12
> (opcode=0xA1) and ATA_16 (opcode=0x85).   This is implemented in fusion
> firmware.  If your failing, then your probably having old firmware.  I
> suggest that you upgrading by going to the download site  located here:
> http://www.lsi.com/cm/DownloadSearch.do?locale=EN.    Ken Stewart is from
> support, he should be able to assist you with upgrading the firmware if you
> encounter any problems.
>
> Eric Moore

Re: ATA_16 support on mptsas

[Krzysztof Błaszkowski]

The recent firmware for e.g. SAS3442 doesn't send check condition with ata 
registers file so some commands don't work properly although those commands 
don't return drive state are delivered to drive and processed by the drive.

Krzysztof Blaszkowski

On Monday 23 June 2008 21:40, Moore, Eric wrote:
> On Monday, June 23, 2008 10:00 AM, Krzysztof Błaszkowski wrote:
> > I found that any HDIO_DRIVE_CMD ioctl on sata drive connected
> > through mpsas
> > and backplane will fail. Basically the scsi_host_template structure is
> > missing ioctl callback. after adding it and temporary
> > tweaking domain_device
> > structure associated to scsi_device (rphy only) i reached a
> > point where
> > ata_scsi_ioctl returns EIO and this why i need some clue on a
> > way of adding
> > such support similar way to aic94 where it has been done.
> >
> > I found also that mptsas leaves domain_device rather
> > uninitialized. the
> > example is rphy but there more fields i don't know if they
> > are revelant to
> > proper processing of HDIO_DRIVE_CMD.
> > i need additional references on libata design, call flow and
> > structures
> > relationship.
> >
> > probably it would be the best to design mptsas from scratch
> > using libsas but
> > this seems to me as huge work although if i was guided i
> > would probably
> > complete this.
>
> We have no plans to implement HDIO ioctls in our driver.   The SATL
> implementation is inside the mpt fusion firmware, and from the driver, we
> don't care whether the underlying protocal is SAS, SATA, Fibre Channel, or
> SPI.   For all protocals, we send scsi commands to the controller firmware
> using SCSI_IO opcode, with the following struct:
>
> typedef struct _MSG_SCSI_IO_REQUEST
> {
>     U8                      TargetID;           /* 00h */
>     U8                      Bus;                /* 01h */
>     U8                      ChainOffset;        /* 02h */
>     U8                      Function;           /* 03h */
>     U8                      CDBLength;          /* 04h */
>     U8                      SenseBufferLength;  /* 05h */
>     U8                      Reserved;           /* 06h */
>     U8                      MsgFlags;           /* 07h */
>     U32                     MsgContext;         /* 08h */
>     U8                      LUN[8];             /* 0Ch */
>     U32                     Control;            /* 14h */
>     U8                      CDB[16];            /* 18h */
>     U32                     DataLength;         /* 28h */
>     U32                     SenseBufferLowAddr; /* 2Ch */
>     SGE_IO_UNION            SGL;                /* 30h */
> } MSG_SCSI_IO_REQUEST, MPI_POINTER PTR_MSG_SCSI_IO_REQUEST,
>   SCSIIORequest_t, MPI_POINTER pSCSIIORequest_t;
>
> > I tried another approach where i used SG_IO ioctl and
> > prepared ATA_16 cdb
> > (just like libata does) but this failed on mptsas connected drives too
> > altough this way works on drives connected to ICH6.
>
> The SG tools will work with mpt fusion if your passing the ATA_12
> (opcode=0xA1) and ATA_16 (opcode=0x85).   This is implemented in fusion
> firmware.  If your failing, then your probably having old firmware.  I
> suggest that you upgrading by going to the download site  located here:
> http://www.lsi.com/cm/DownloadSearch.do?locale=EN.    Ken Stewart is from
> support, he should be able to assist you with upgrading the firmware if you
> encounter any problems.
>
> Eric Moore

RE: ATA_16 support on mptsas

[Moore, Eric]

On Friday, June 27, 2008 8:24 AM,  Krzysztof Błaszkowski wrote:
>
> The recent firmware for e.g. SAS3442 doesn't send check
> condition with ata
> registers file so some commands don't work properly although
> those commands
> don't return drive state are delivered to drive and processed
> by the drive.
>

I device driver supports returning sense data, so if the target returned sense, it would be sent up the stack.    Here is the location of the SATL spec http://www.t10.org/ftp/t10/drafts/sat2/sat2r05.pdf, please refer to section 11.1..   So can you provide more details on which commands are you expecting sense data on.    Meanwhile I will send Ken the mpt fusion engineering design note for SATL.

Eric

Re: ATA_16 support on mptsas

[Krzysztof Błaszkowski]

On Friday 27 June 2008 17:07, Moore, Eric wrote:
> On Friday, June 27, 2008 8:24 AM,  Krzysztof Błaszkowski wrote:
> > The recent firmware for e.g. SAS3442 doesn't send check
> > condition with ata
> > registers file so some commands don't work properly although
> > those commands
> > don't return drive state are delivered to drive and processed
> > by the drive.
>
> I device driver supports returning sense data, so if the target returned
> sense, it would be sent up the stack.    Here is the location of the SATL
> spec http://www.t10.org/ftp/t10/drafts/sat2/sat2r05.pdf, please refer to
> section 11.1..   So can you provide more details on which commands are you
> expecting sense data on.    Meanwhile I will send Ken the mpt fusion
> engineering design note for SATL.


okay. i didn't know this spec so thank you for reference.

Anyway:
1. I observed that ATA_16 issued to disk through ICH6 ends up with 4 bytes 
longer sense data comparing to sense data from LSI.

2. according to the spec chapter 12.2.3 if the cdb has set the CK_COND bit 
then the sense data should include ATA Status Descriptor described in chapter 
12.2.5.  Seems that the recent firmware violates this requirement thus latest 
hdparm (rev 8.9) signals false failure or can not evaluate right status. And 
the hdparm sets this bit in sgio.c:sg16()

you can try e.g. CHECK POWER MODE (0xe5)

>
> Eric

Krzysztof