On Thursday, August 10, 2006 5:28 PM, Mike Christie wrote > But I thought, a request should eventually complete and so we > should be > woken up from get_request_wait, and we will try allocate a > request again > and then the write request count should have gone down and we > should be > able to proceed. Mike, You are right. My logic was bad ... I was confusing mapped and target device queues. Turns out the delays that I am seeing (multipathd checker thread is stuck waiting for up to 15 minutes waiting for a free target device queue) are due to ios being held and timed out by the SCSI LLD (Emulex). I never waited more than 10 minutes in my testing earlier in the month before looking for some type of deadlock. I've changed the patch to call blk_get_request() with __GFP_WAIT always from a worker thread context since using pre-allocated request structures does not help the problem. Thanks, Ed -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
