[2973] in linux-scsi channel archive
Re: BusLogic problems...
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Thu Dec 18 17:52:37 1997
Date: Thu, 18 Dec 1997 23:44:50 +0100 (MET)
From: Gerard Roudier <groudier@club-internet.fr>
To: Boris Tobotras <tobotras@jet.msk.su>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <lc0afdzb0yl.fsf@goliath.jet.msk.su>
On 18 Dec 1997, Boris Tobotras wrote:
> >>>>> "Dave" == Dave Wreski writes:
>
> >> What about Atlas? I had repeatable system lock with"queue full"
> >> sympthom, with aha2940uw and Altas-II. I had to disable tagged queueing
> >> complety to survive. That was at the times of 2.0.30. With .31, tagged
> >> queuing seems not to cause the troubles, given the fact I didn't dare to
> >> enable SCB paging. But all of that doesn't look promising for me.
>
> Dave> I've also had problems with my Atlas II drives, and Leonard found a
> Dave> new firmware at Quantum's ftp site that seems to fix the problem thus
> Dave> far.
>
> Dave> Leonard, can you tell us exactly how to apply these firmware
> Dave> upgrades? I have been unable to find the executable that writes it
> Dave> to the disk..
>
> I remember seeing some utility on quantum's ftp site. But my
> firmware is is LXY4, and it seem to be the latest. There is
> something newer in TESTCODE area, but I hesitate to download test
> firmware onto my production server's drive.
>
> BTW, now I have Atlas attaches to the same bus with Atlas-II --
> should I expect the same sort of troubles with it? Not, so far. Its
> firmware is L912.
Opinion:
--------
My experience with these both drives/firmwares is that they may
return QUEUE FULL when bunches of small IO writes are performed even
reasonnable queue depth of 8 commands is being used.
It seems to me that the firmware completes a SCSI command as soon as
data has been copied to the cache. The queue that is stated full by
the firmware is probably not the apparent queue of commands that are
not yet completed but something internal to the drive firmware data.
My opinion of such an implementation of tagged commands is that it is
not serious, since no simple heuristic probably exists to handle this
cleverly from the host system.
The host system (or the user) need to estimate or dynamically resize
the maximum queued command in order to avoid QUEUE FULL. This can be
achieved only if the QUEUE FULL condition has some clear correlation
with the number of commands actually queued to the device.
IMO, Hard disk firmware implementors should consider the above and
handle write caching as follow:
- Copy data to the cache if it is possible without disconnecting the
bus or slowing actual data transfer speed.
- Disconnect if no room is available in the cache.
- Complete the command (message complete + status), only when the data
has been written to the media.
- Base the QUEUE FULL condition on a nearly fixed (or tuneable) number
of active nexuses (contexts) (or something that is predictible and
documented)
One can reply that some general adaptative algorithm can be implemented
in order to adjust dynamically the command queue depth of devices.
Such an algorithm is not guaranteed to work with any kind of
braindeaded firmware, since such a algorithm must me able to
make some predictions of effects due to its decisions.
Adding complexity to deal with complexity. This is not about to
change the actual steady state of computers which is 'not working'.
Regards, Gerard.
