svn commit: r211434 - head/sys/cam/scsi
mj at feral.com
Tue Aug 17 18:18:28 UTC 2010
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.
More information about the svn-src-head