HP SW support take 3

Fix locking bug. Will have to send the block layer stuff to Jens Axboe when we get hp-sw support finished. For now I included everything in one patch (reminder - don't use things like rd, dm, md, aoe, or anything without a real queue under dm-mpath if you are using a hw_hanlder that injects a failover command).

This was only tested with scsi_debug.

diff -Naurp linux-2.6.12-rc5.orig/drivers/block/ll_rw_blk.c linux-2.6.12-rc5/drivers/block/ll_rw_blk.c

drivers/block/ll_rw_blk.c +3 -1

@@ -2369,7 +2369,7 @@ void disk_round_stats(struct gendisk *di
 /*
  * queue lock must be held
  */
-static void __blk_put_request(request_queue_t *q, struct request *req)
+void __blk_put_request(request_queue_t *q, struct request *req)
 {
 	struct request_list *rl = req->rl;
 

@@ -2398,6 +2398,8 @@ static void __blk_put_request(request_qu
 	}
 }
 
+EXPORT_SYMBOL(__blk_put_request);
+
 void blk_put_request(struct request *req)
 {
 	/*

diff -Naurp linux-2.6.12-rc5.orig/include/linux/blkdev.h linux-2.6.12-rc5/include/linux/blkdev.h

include/linux/blkdev.h +1 -0

@@ -540,6 +540,7 @@ extern void blk_unregister_queue(struct 
 extern void register_disk(struct gendisk *dev);
 extern void generic_make_request(struct bio *bio);
 extern void blk_put_request(struct request *);
+extern void __blk_put_request(request_queue_t *, struct request *);
 extern void blk_end_sync_rq(struct request *rq);
 extern void blk_attempt_remerge(request_queue_t *, struct request *);
 extern void __blk_attempt_remerge(request_queue_t *, struct request *);

I confirm a robust behaviour now with take 3.
Here is a take 4 that move to an appropriate "best effort mode", ie always return success.

The point is, whenever DM start submitting io the an asleep controler, precede with a START command. If it fails ... too bad, the consecutive io will fail and DM will try another PG. Had to do that because take 3 interprets an error where the controler switch have correctly happened.

I guess we could suppress the sense buffer allocation if this "best effort mode" is agreed on.

I also added path->dev->name to DMINFO() calls to make for a more informative output.

Quoted 5 lines · Christophe Varoqui

I confirm a robust behaviour now with take 3.
Here is a take 4 that move to an appropriate "best effort mode", ie always return success.

The point is, whenever DM start submitting io the an asleep controler, precede with a START command. If it fails ... too bad, the consecutive io will fail and DM will try another PG. Had to do that because take 3 interprets an error where the controler switch have correctly happened.

ok so is it if the controller is already failed over and we send the START command, rq->errors had some value so I ended up failing the operation, right? Let me send a patch that will dump the sense and rq->errors info out so we can see if there is some nice ASC/ASCQ value that will tell us this occured like with the LSI boxes.

Quoted 12 lines · Mike Christie

Quoted 9 lines · Christophe Varoqui

I confirm a robust behaviour now with take 3.
Here is a take 4 that move to an appropriate "best effort mode", ie always return success.

The point is, whenever DM start submitting io the an asleep controler, precede with a START command. If it fails ... too bad, the consecutive io will fail and DM will try another PG. Had to do that because take 3 interprets an error where the controler switch have correctly happened.

Quoted 5 lines

ok so is it if the controller is already failed over and we send the START command, rq->errors had some value so I ended up failing the operation, right? Let me send a patch that will dump the sense and rq->errors info out so we can see if there is some nice ASC/ASCQ value that will tell us this occured like with the LSI boxes.

oh wait, when I reread this I guess you are saying that I was always gettting a rq->error value when I send a START_STOP and it succeeds?