From owner-cvs-all Thu Aug 30 9:25:33 2001 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 939B437B405; Thu, 30 Aug 2001 09:25:24 -0700 (PDT) (envelope-from mjacob@FreeBSD.org) Received: (from mjacob@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f7UGPOB07591; Thu, 30 Aug 2001 09:25:24 -0700 (PDT) (envelope-from mjacob) Message-Id: <200108301625.f7UGPOB07591@freefall.freebsd.org> From: Matt Jacob Date: Thu, 30 Aug 2001 09:25:24 -0700 (PDT) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/cam/scsi scsi_sa.c X-FreeBSD-CVS-Branch: HEAD Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG mjacob 2001/08/30 09:25:24 PDT Modified files: sys/cam/scsi scsi_sa.c Log: Clear SA_FLAG_ERR_PENDING for MTREW, MTERASE and MTRETENS ioctl cases. Clear residual counts after a successful samount (the user doesn't care that we got an N-kbyte residual on our test read). Change a lot of error handling code. 1. If we end up in saerror, check more carefully about the kind of error. If it is a CAM_SCSI_STATUS_ERROR and it is a read/write command, we'll be handling this in saerror. If it isn't a read/write command, check to see whether this is just an EOM/EOP check condition- if it is, just set residual and return normally. A residual and then a NO SENSE check condiftion with the ASC of 0 and ASCQ of between 1 and 4 are normal 'signifying' events, not errors per se, and we shouldn't give the command to cam_periph_error to do something relatively unpredictable with. 2. If we get a Bus Reset, had a BDR sent, or get the cam status of CAM_REQUEUE_REQ, check the retry count on the command. The default error handler, cam_periph_error, doesn't honor retry count in these cases. This may change in the future, but for now, make sure we set EIO and return without calling cam_periph_error if the retry count for the command with an error is zero. 3. Clean up the pending error case goop and handle cases more sensibly. The rules are: If command was a Write: If we got a SSD_KEY_VOLUME_OVERFLOW, the resid is propagated and we set ENOSPC as the error. Else if we got an EOM condition- just mark EOM pending. And set a residual of zero. For the longest time I was just propagating residual from the sense data- but my tape comparison tests were always failing because all drives I tested with actually *do* write the data anyway- the EOM (early warning) condition occurred *prior* to all of the data going out to media- that is, it was still buffered by the drive. This case is described in SCSI-2, 10.2.14, paragraph #d for the meaning of 'information field'. A better fix for this would be to issue a WFM command of zero to cause the drive to flush any buffered data, but this would require a fairly extensive rewrite. Else if the command was a READ: If we got a SSD_KEY_BLANK_CHECK- If we have a One Filemark EOT model- mark EOM as pending, otherwise set EIO as the erorr. Else if we found a Filemark- If we're in Fixed Block mode- mark EOF pending. If we had an ILI (Incorrect Length Indicator)- If the residual is less than zero, whine about tape record being too big for user's buffer, otherwise if we were in Fixed Block mode, mark EIO as pending. All 'pending' conditions mean that the command in question completes without error indication. It had succeeded, but a signifying event occurred during its execution which will apply to the *next* command that would be exexcuted. Except for the one EOM case above, we always propagate residual. Now, way back in sastart- if we notice any of the PENDING bits set, we don't run the command we've just pulled off the wait queue. Instead, we then figure out it's disposition based upon a previous command's association with a signifying event. If SA_FLAG_EOM_PENDING is set, we don't set an error. We just complete the command with residual set to the request count (not data moved, but no error). We continue on. If SA_FLAG_EOF_PENDING- if we have this, it's only because we're in Fixed Block mode- in which case we traverse all waiting buffers (which we can get in fixed block mode because physio has split things up) and mark them all as no error, but no data moved and complete them. If SA_FLAG_EIO_PENDING, just mark the buffer with an EIO error and complete it. Then we clear all of the pending state bits- we're done. MFC after: 4 weeks Revision Changes Path 1.78 +113 -86 src/sys/cam/scsi/scsi_sa.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message