Jens Axboe <jens.axboe@xxxxxxxxxx> wrote: > On Mon, May 03 2010, Mike Anderson wrote: > > If the queue is stopped it could be an indication that other recovery is > > happening in this case skip the blk_abort_request. > > > > Signed-off-by: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx> > > Cc: Jens Axobe <jens.axboe@xxxxxxxxxx> > > --- > > block/blk-timeout.c | 3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/block/blk-timeout.c b/block/blk-timeout.c > > index 1ba7e0a..89fbe0a 100644 > > --- a/block/blk-timeout.c > > +++ b/block/blk-timeout.c > > @@ -224,7 +224,8 @@ void blk_abort_queue(struct request_queue *q) > > list_splice_init(&q->timeout_list, &list); > > > > list_for_each_entry_safe(rq, tmp, &list, timeout_list) > > - blk_abort_request(rq); > > + if (!blk_queue_stopped(q)) > > + blk_abort_request(rq); > > > > /* > > * Occasionally, blk_abort_request() will return without > > That seems like a bit of a mixup, what ties a stopped queue to recovery? This was coding to SCSI behavior again. I tried to reduce the case of waking the eh if the transport moved the target into a blocked state. It might be redundant as FC has eh blocking and timer_reset. iSCSI has blocking but not eh blocking. > To take one example, the cciss driver stops the queue when it can't > queue more at the hw level and starts it on completion to queue more. If > recovery triggers when the hw queue has been filled, then timeouts will > fail? > > It would be better to mark the queue as already doing abort. That state > could be in the queue, or it could be at the driver level. ok. I will look into this. -andmike -- Michael Anderson andmike@xxxxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
