I don't know who the right person is to handle this, but maybe someone can help... When a command injected through the sg driver encounters any sort of error, the usual retry mechanism and error handler are brought into play. Since sg sets the number of retries to 0 by default, the retry mechanism shouldn't cause any difficulty. But the error handler does. IMO it should never get involved with requests coming through sg -- sg should provide access that is as transparent as possible so that userspace programs will have a clean shot at managing their device. Consider a case that just came up. A USB CD drive causes a phase error when it receives a certain READ BUFFER command (buggy firmware on the drive, never mind that now). You would expect the user program to receive from sg a host_status value indicating DID_ERROR or something of the sort. Instead the error handler takes charge and sends out one or two TEST UNIT READY commands. The status information finally received by the user program is the status from the TEST UNIT READY, not from the failed READ BUFFER! How's a program supposed to cope with that sort of obfuscation? Something in the SCSI stack (scsi_io_completion ?) should check for requests coming in via sg and should know to complete the requests immediately. No requeuing and no error handling. Does this sound like a feasible thing to implement? Alan Stern - : 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
