[2754] in linux-scsi channel archive
Re: queuecommand
daemon@ATHENA.MIT.EDU (Michael Neuffer)
Wed Nov 5 00:22:48 1997
Date: Wed, 5 Nov 1997 06:16:23 +0100 (MET)
From: Michael Neuffer <neuffer@goofy.zdv.Uni-Mainz.de>
To: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
cc: linux-scsi@vger.rutgers.edu, linux-kernel@vger.rutgers.edu
In-Reply-To: <199711041510.QAA29016@sunsite.ms.mff.cuni.cz>
On Tue, 4 Nov 1997, Jakub Jelinek wrote:
> I'm just wondering why is scsi host method queuecommand
> declared to return int, when the return value is never used.
> But apparently a lot of drivers do use it, but sometimes they
> return 1 and sometimes 0 for success/failure.
> I think the return value should be made common and scsi.c should cope with
> that, in the sense that commands which couldn't be queued will be retried in
> a short time. Several drivers in case of "request queue overflow" just
> return that they couldn't queue it, but mid-layer doesn't care and just
> assumes the command has been successfuly queued. The commands then never
> actually go into any queue and cause timeouts, bus resets and often panics
> because miriads of scsi errors that come from that.
> Or the other solution could be to implement some internal queueing in the
> drivers, so that they'd put the command which they cannot handle into some
> software queue and after a while try to put it there again...
>
> Ideas?
The new midlevel scsi code adresses that among other things.
Take a look at ftp://andante.jic.com/pub/scsi/scsi2159.diff
Mike
