Jens Axboe wrote: > On Thu, Jan 04 2007, James Bottomley wrote: >> On Thu, 2007-01-04 at 12:21 +0100, Jens Axboe wrote: >>> I guess it's fully up to you how you want to solve it. The scheme seems >>> a little elaborate, but these error conditions are unlikely to ever been >>> seen in the wild, so no objections from me. >> Actually, there's already a DID_ code that does what you want. Instead >> of DID_ERROR, which will retry immediately, there's DID_REQUEUE which >> will halt the device queue and wait for a returning command to retry. > > As long as it keeps firing the queue at some intervals even without any > commands pending at all, then that'll work just fine. I like that > approach a lot better than coding the error into some sense value that > is (at best) some vague approximation of what has happened (calling > memory shortage a transport error is a bit of a stretch). True, but both happen. The scsi_debug driver is a virtual host, virtual target and a lu (ram disk). The failure that you pointed out stopped a response being built. In the real world that would in the target or lu. The reason that I mentioned aborted_command sense key is that it is also a "out of resources" (bandwidth) error and it broke sg_dd. I would bet money that it would also break the block layer/sd. The block layer should leave it alone as it is simply a matter of sd retrying a few times. However the st driver could have a real problem (e.g. did that state changing command work, fail or partially work??). Anyway, I have submitted a patch that reports DID_REQUEUE for an allocation failures and adds the ability to inject aborted_command errors. Doug Gilbert - 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
