From owner-freebsd-scsi Thu Mar 25 11: 4:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id AB4F714DBC for ; Thu, 25 Mar 1999 11:04:18 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id LAA35035; Thu, 25 Mar 1999 11:54:47 -0700 (MST) Date: Thu, 25 Mar 1999 11:54:47 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903251854.LAA35035@narnia.plutotech.com> To: "Kenneth D. Merry" Cc: scsi@FreeBSD.org Subject: Re: CAM flags X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199903251648.JAA86680@panzer.plutotech.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199903251648.JAA86680@panzer.plutotech.com> you wrote: > amobbs@allstor-sw.co.uk wrote... >> >> Could somebody please explain what effect "CAM_DEV_QFRZDIS" has, beyond >> "Disable DEV Q freezing", i.e. what is "DEV Q freezing", do I want it >> disabled, and if so, why? > > Whenever an error occurs for a SCSI CCB, the command queue for the device > in question is frozen until error recovery actions have completed. > > If you're writing an application that goes through the passthrough driver, > and you want to do your own error recovery, you'll probably want to disable > queue freezing since you control your own queue of commands, and can do > your own error recovery. The choice of disabling freezing the queue really depends on how you do your error recovery. Having the queue frozen is almost essential for an application that uses overlapped commands regardless of whether they are a userland peripheral driver or one in the kernel. Without queue freezing, it is possible for a command queued after the one that received the error to be sent to the device before your error recovery routines can intervene. Without overlapped commands, you may feel that having to issue an extra ccb to unfreeze the queue for every error you encounter to be cumbersome. We actually added the flag for use by applications that have no concept of a frozen device queue, like cdrecord, at least until the application can be modified to understand the way CAM works. > Otherwise, you'll have to unfreeze the queue if an error occurs. You can > tell if the queue has been frozen by looking at the CAM_DEV_QFRZN bit of > the status field in the CCB header. > > This only applies when autosense is enabled, which is the default. If > autosense is disabled (CAM_DIS_AUTOSENSE), the controller won't freeze > the queue in case of an error. Not true. The queue will be frozen on any error unless the command requested that this feature be disabled. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message