James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 2008-02-10 at 16:29 +0100, Elias Oltmanns wrote: >> James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: [...] >> > No. We have a fix for this, it's called setting device_max_blocked to 2 >> > or greater. All your patch does is make this seem to be the case, plus >> > it eliminates the instant reissue case for drivers with queuecommands >> > that do obey all the rules. >> > >> > If you can prove that IDE doesn't obey the rules (no defer returns) >> >> In fact, I can prove that scsi midlayer itself doesn't exactly comply >> with this rule by design. The comment explaining the SDEV_BLOCK state in >> scsi_device.h suggests that the low level driver is supposed to control >> whether a device is switched to or from SDEV_BLOCK. However, with >> max_device_blocked set to 1 we have an infinite loop where the low level >> driver never gets even called since scsi_dispatch_cmd will requeue the >> request instantly. >> >> IDE doesn't obey the rule either but this can be fixed easily. So, what >> about SDEV_BLOCK? > > Well, nothing. It's an API a HBA may not use (per previous rule) if it > wants to set max_device_blocked to 1. Right. Thanks for the clarification. Regards, Elias - 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
