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.
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
