Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Aug 2010 11:05:07 -0700
From:      Matthew Jacob <mj@feral.com>
To:        Scott Long <scottl@samsco.org>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Matt Jacob <mjacob@FreeBSD.org>
Subject:   Re: svn commit: r211434 - head/sys/cam/scsi
Message-ID:  <4C6ACF53.5080607@feral.com>
In-Reply-To: <810BE039-72EA-4020-8B42-8D1274E888AA@samsco.org>
References:  <201008171711.o7HHBFce039173@svn.freebsd.org> <810BE039-72EA-4020-8B42-8D1274E888AA@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C6ACF53.5080607>