:> I know cam uses some helper threads so I am not entirely sure about
:> the context the cam_sim_alloc() calls are being made in, but if they
:> do not create I/O stalls for already-operational SCSI devices then I
:> am inclined (in DFly anyway) to simply make the malloc in
:> cam_sim_alloc() M_WAITOK.
:> :> -Matt
:> Matthew Dillon :> <[EMAIL PROTECTED]>
:> :
:In the 4.x case, so long as the driver doesn't do an splcam() or somehow
:block hardware interrupts before calling cam_sim_alloc() you are
:probably fine. For 5.x, you might run into Giant problems.
:
:Scott
Well, I don't see how a spl or Giant could possibly have anything to do with memory deadlocks. Both are dropped when a thread blocks so the worst that happens is that you add some latency.
CAM doesn't use a kthread in 4.x. It uses it's own SWI hooks. If you call splcam(), then you will block those from running, and no CAM I/O will complete until you call splx(). That's why I say that it's ok to use M_WAITOK so long as you don't block CAM from running.
If you want to add a WAITOK/NOWAIT flag parameter to cam_sim_alloc(), that might be a good solution.
Scott
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
