Patrick Mansfield wrote:
On Wed, Aug 24, 2005 at 04:03:58AM -0500, Mike Christie wrote:-#define end_io_error(uptodate) (unlikely((uptodate) <= 0)) +enum { + BLK_SUCCESS = 0, /* Must be zero for compat with old usage */ + BLKERR_IO, /* Generic I/O error */ + BLKERR_NOTSUPP, /* Operation is not supported */ + BLKERR_WOULDBLOCK, /* Operation would block */ + BLKERR_FATAL_DRV, /* Fatal driver error */ + BLKERR_FATAL_DEV, /* Fatal device error */ + BLKERR_FATAL_XPT, /* Fatal transport error */ + BLKERR_RETRY_DRV, /* Driver error, I/O may be retried */ + BLKERR_RETRY_DEV, /* Device error, I/O may be retried */ + BLKERR_RETRY_XPT, /* Transport error, I/O may retried */ +};Do you need to add and use a BLKERR_TIMEOUT? As we can't determine the problem area for a timeout, and if it can or should be retried.
I was hoping we could figure this out. In the patches, if a command times out and eh kicks off I was just returning BLKERR_RETRY_DEV. This guessing occurs for a lot of errors becuase we do not know what exactly happened. the reason for the timeout could have been a device problem or transport problem. Some help in figuring this type of thing out is needed in other places.
- : 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
