From owner-freebsd-scsi Fri Aug 16 8:40: 0 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 558FE37B400 for ; Fri, 16 Aug 2002 08:39:58 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9525E43E70 for ; Fri, 16 Aug 2002 08:39:57 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.5/8.12.5) with ESMTP id g7GFdWZY027114; Fri, 16 Aug 2002 09:39:32 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Fri, 16 Aug 2002 09:39:32 -0600 From: "Justin T. Gibbs" To: "Sabapathi, Vanishree" , freebsd-scsi@FreeBSD.ORG Subject: Re: Reg: Reset and Abort Entry point in CAM scsi driver Message-ID: <3134680000.1029512372@aslan.scsiguy.com> In-Reply-To: <0E3FA95632D6D047BA649F95DAB60E5701265BCC@EXA-ATLANTA.se.lsil.com> References: <0E3FA95632D6D047BA649F95DAB60E5701265BCC@EXA-ATLANTA.se.lsil.co m> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hi, > I would like to know when the Abort and reset entry point is called > in a CAM-Scsi driver... These entry points are never getting called in my > driver... > I tried running i/o's on my disk and pulling the power of one of the disks > on which the i/o was running...The i/o's were freezed on screen... Now I > expected XPT_ABORT/XPT_RESET entry points in my driver to be called... but > my Driver's entry point was never called... ( I mean my driver was never > called with any entry point) > > Please advice if I should be doing something special to handle these > cases.. FreeBSD != Linux. The SIM drivers are responsible for honoring the timeout field as specified in the CCB. If you look at other SIM drivers in the FreeBSD tree, you will see them either using the "timeout" function or the "callout_reset" APIs. See callout.9 for details. When a SIM sees a timeout, it is up to the SIM to determine what recovery actions are required to restore operation. This avoids lots of ugly issues with timeouts managed by the upper SCSI layer: 1) When should the timeout be started? Only the SIM knows when I/O is really started, so it should make that decision. 2) What if a timeout occurs just as a command completed? Only the SIM can determine if this is the case and properly ignore the timeout and return the command as completed correctly. 3) How do you untangle the semantics of "abort" if it can either mean, abort this command because I'm no longer interested in it, or my watchdog timer expired so I'm just flailing about aborting stuff in the hopes that the SIM will restore bus operation. For these and other reasons, the SIMS are responsible for timeout management. I would expect you to see an XPT_RESET ccb just after probe unless your path inquiry data has PIM_NOBUSRESET set. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message