Re: [PATCH] saved and restore result for timed out commands

Alan Stern
2005-06-01T21:26:38Z

On Wed, 1 Jun 2005, James Bottomley wrote:

> On Wed, 2005-06-01 at 14:45 -0400, Alan Stern wrote:
> > Has there been any more progress on this issue?
>
> Well, the patch is in scsi-misc, if that's what you're asking.

That's good. Is it too much to ask for an additional patch to zero out
the sense data buffer after the error handler has finished with a command?
After a transport error or a timeout there shouldn't be any sense data
(races aside), but the error handler often leaves apparently valid data in
the buffer, unrelated to the original command.

By the way, is scsi-misc available anywhere as a patch (or set of
patches) for those of us not on the bleeding edge, or does it exist only
as a git repository?

> > I spoke with Jörg Schilling (author of the cdrecord package, a widely-used
> > sg client) and he said that failed operations should be retried
> > automatically if the command had not gotten as far as being sent on the
> > bus -- e.g., if the host adapter driver's queue was full. But if the
> > command did get sent to the device then any subsequent failure should be
> > reflected back to the client with no retrys.
>
> That's pretty much what we do now ... with the exception of QUEUE_FULL
> and BUSY handling. What's the actual problem you were discussing?

This isn't so much in response to a particular problem as it is an attempt
to make the Linux sg driver more useful. (The discussion got started
because of an actual problem, but that problem was at the USB level, not
the SCSI level.)

You may not have run across Schilling very much. He's done a lot of
work on SCSI application programming on a variety of OS's. His opinion of
the Linux SCSI stack isn't very high, although admittedly many of the
problems he complains about only existed in much earlier versions of
Linux. (Try reading through the some of the documentation or man pages
for cdrecord and you'll see what I mean.)

Anyway, he still talks about how Linux's sg interface is so much worse
than Solaris's. Considering this issue of proper return codes and client
control of the device, you can agree that he does have a point. He must
think of himself purely as an applications programmer, not a kernel
programmer, because he hasn't done anything to _fix_ these problems -- he
prefers to complain about them. So I decided to see if something could be
done to fix this particular issue, which does appear to be genuine.

Overall, the motivation is simply to improve sg by making it more
transparent, giving clients more control over the device, and returning
valid and useful status.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html