From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Eric Moore <eric.moore@lsi.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 9/13] mpt2sas: T10 DIF Support - EEDP
Date: Wed, 15 Apr 2009 15:31:33 -0400 [thread overview]
Message-ID: <yq163h5zpbe.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20090414043511.GJ20124@lsil.com> (Eric Moore's message of "Mon, 13 Apr 2009 22:35:14 -0600")
>>>>> "Eric" == Eric Moore <eric.moore@lsi.com> writes:
Eric,
+_scsih_setup_eedp(struct scsi_cmnd *scmd, Mpi2SCSIIORequest_t *mpi_request)
[...]
+ /*
+ * enable ref/app/guard checking
+ * auto increment ref tag
+ */
+ mpi_request->EEDPFlags = eedp_flags |
+ MPI2_SCSIIO_EEDPFLAGS_INC_PRI_REFTAG |
+ MPI2_SCSIIO_EEDPFLAGS_CHECK_REFTAG |
+ MPI2_SCSIIO_EEDPFLAGS_CHECK_APPTAG |
+ MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD;
How can you check the app tag?
+_scsih_eedp_error_handling(struct scsi_cmnd *scmd, u16 ioc_status)
[...]
+ if (scmd->sc_data_direction == DMA_TO_DEVICE) {
+ sk = ILLEGAL_REQUEST;
+ host_byte = DID_ABORT;
+ } else {
+ sk = ABORTED_COMMAND;
+ host_byte = DID_OK;
+ }
ILLEGAL REQUEST is used when the HBA detects a mismatch between data and
protection information. If you are not receiving PI from the OS (WRITE
INSERT) then the HBA can't detect an integrity error. So in the
DMA_TO_DEVICE case only the target can catch the error (and it will
return ABORTED_COMMAND).
For READ, both the drive firmware and the HBA can ostensibly check that
the data buffers and PI match.
Are your EEDP error flags only set when the HBA firmware detects a
problem or also when the drive returns ABORTED COMMAND/0x10?
I.e. do we get double failure scenarios (both drive and HBA detect the
mismatch)?
+ scsi_host_set_prot(shost, SHOST_DIF_TYPE1_PROTECTION
+ | SHOST_DIF_TYPE3_PROTECTION);
How do you handle Type 3? The application tag and reference tags are
both defined as being opaque storage for Type 3.
If I understand correctly, your firmware only deals with the Type 2
usage model of the application tag. And Type 1 + 2 usage of the
reference tag.
+ scsi_host_set_guard(shost, SHOST_DIX_GUARD_CRC);
Technically speaking that is only required for DIX exchange. But
setting it doesn't hurt.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2009-04-15 19:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-14 4:35 [PATCH 9/13] mpt2sas: T10 DIF Support - EEDP Eric Moore
2009-04-15 19:31 ` Martin K. Petersen [this message]
2009-04-15 20:07 ` Moore, Eric
2009-04-15 22:26 ` Martin K. Petersen
2009-04-15 22:53 ` Moore, Eric
2009-04-16 2:54 ` Martin K. Petersen
-- strict thread matches above, loose matches on Subject: below --
2009-04-16 16:45 Eric Moore
2009-04-17 0:49 ` Martin K. Petersen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq163h5zpbe.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=eric.moore@lsi.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox