From owner-svn-src-head@FreeBSD.ORG Tue Aug 17 18:18:28 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BE681065672; Tue, 17 Aug 2010 18:18:28 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id EBDA98FC08; Tue, 17 Aug 2010 18:18:27 +0000 (UTC) Received: from [192.168.0.103] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o7HI5Dka093736; Tue, 17 Aug 2010 11:05:13 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C6ACF53.5080607@feral.com> Date: Tue, 17 Aug 2010 11:05:07 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Scott Long References: <201008171711.o7HHBFce039173@svn.freebsd.org> <810BE039-72EA-4020-8B42-8D1274E888AA@samsco.org> In-Reply-To: <810BE039-72EA-4020-8B42-8D1274E888AA@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Tue, 17 Aug 2010 11:05:14 -0700 (PDT) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Matt Jacob Subject: Re: svn commit: r211434 - head/sys/cam/scsi X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:18:28 -0000 On 8/17/2010 10:59 AM, Scott Long wrote: > This is violates the policy that CAM has effectively had for a long time that separates protocol error handling in the periph from transport error recovery in the SIM. I think it's better to encourage SIMs to register an AC_LOST_DEVICE event and handle command aborts themselves. Most drivers have a busy queue and know what outstanding CCBs belong to what devices/targets. And in the age of SAS, the SIMs are going to know about dead devices long before the periph will, and should already be in the process of aborting the outstanding commands and returning the CCBs. SIMs that don't probably don't even properly timeout outstanding commands, so they'll have much deeper problems than this. > > I'm in the middle of working on this for the mps driver. Your change may or may not get in the way of the design I already have, where the SIM autonomously dequeues and completes all outstanding CCBs to dead devices. I'll hopefully have an answer in the coming weeks and let you know. Please don't MFC before then. > > Oh, okay. I don't need to MFC it then, depending on the state of your work. All of the periph drivers had this XXX. I'm doing practical work at present to try and handle device lossage in current systems. Not sure about this being a violation of policy. There's nothing in this that says anything about protocol errors or what. If the device is going away, it is not unreasonable to call into CAM to make sure any inflight CCBs are aborted, wherever they may be. The reality here is that this goes straight to the SIM, but that need not be so.