From owner-cvs-all  Sun Apr 22 13:13: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 11E5837B424; Sun, 22 Apr 2001 13:13:29 -0700 (PDT)
	(envelope-from joerg@FreeBSD.org)
Received: (from joerg@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f3MKDTd16756;
	Sun, 22 Apr 2001 13:13:29 -0700 (PDT)
	(envelope-from joerg)
Message-Id: <200104222013.f3MKDTd16756@freefall.freebsd.org>
From: Joerg Wunsch <joerg@FreeBSD.org>
Date: Sun, 22 Apr 2001 13:13:28 -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
X-Loop: FreeBSD.ORG

joerg       2001/04/22 13:13:28 PDT

  Modified files:
    sys/cam/scsi         scsi_sa.c 
  Log:
  Fix the `tape drive spinning indefinately upon mt stat' problem.
  
  With the recent changes in the CAM error handling, some problems in
  the error handling of sa(4) have been uncovered.  Basically, a number
  of conditions that are not actually errors have been mistreated as
  genuine errors.  In particular:
  
  . Trying to read in variable length mode with a mismatched blocksize
    between the on-tape (virtual) blocks and the read(2) supplied buffer
    size, causing an ILI SCSI condition, have caused an attempt to retry
    the supposedly `errored' transfer, causing the tape to be read
    continuously until it eventually hit EOM.  Since by default any
    simple mt(1) operation does an initial test read, an `mt stat' was
    sufficient to trigger this bug.
  
    Note that it's Justin's opinion that treating a NO SENSE as an EIO
    is another bug in CAM.  I feel not authorized to fix cam_periph.c
    without another confirmation that i'm on the right track, however.
  
  . Hitting a filemark caused the read(2) syscall to return EIO, instead
    of returning a `short read'.  Note that the current fix only solves
    this problem in variable length mode.  Fixed length mode uses a
    different code path, and since i didn't grok all the intentions behind
    that handling, i did not touch it (IOW: it's still broken, and you get
    an EIO upon hitting a filemark).
  
  The solution is to keep track of those conditions inside saerror(),
  and upon completion to not call cam_periph_error() in that case.  We
  need to make sure that the device gets unfrozen if needed though (in
  case of actual errors, cam_periph_error() does this on our behalf).
  
  Not objected by:       mjacob (who currently doesn't have the time to
  			      review the patch)
  
  Revision  Changes    Path
  1.68      +16 -3     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