Re: SCSI Kernel Problem - BAD

Leonard N. Zubkoff (lnz@dandelion.com)
Sat, 16 Mar 1996 17:56:31 -0800


From: "Eric Youngdale" <eric@aib.com>
Date: Fri, 15 Mar 1996 10:24:19 -0500

WRT the comments about tagged queueing, and the indeterminacy of
the order of operations, this is indeed worrying for a number of reasons.
Not the least of which is that if you are modifying lots of files, you could
conceivably have updates to the inode table consistently being deferred
because of large file writes. My gut feeling is that if we encounter
a timeout and tagged queueing is enabled, then instead of direct action,
we probably want to send one of those marker thingies to the device
to force it to synchronize - then we reset the timeout period to give
the command a chance to complete.

The solution I'm using is actually very simple and doesn't require support from
any asynchronous timeout code:

BusLogic_QueueTag_T QueueTag = BusLogic_SimpleQueueTag;
/*
When using Tagged Queuing with Simple Queue Tags, it appears that disk
drive controllers do not guarantee that a queued command will not
remain in a disconnected state indefinitely if commands that read or
write nearer the head position continue to arrive without interruption.
Therefore, for each Target Device this driver keeps track of the last
time either the queue was empty or an Ordered Queue Tag was issued. If
more than 2 seconds have elapsed since this last sequence point, this
command will be issued with an Ordered Queue Tag rather than a Simple
Queue Tag, which forces the Target Device to complete all previously
queued commands before this command may be executed.
*/
if (HostAdapter->ActiveCommandCount[TargetID] == 0)
HostAdapter->LastSequencePoint[TargetID] = jiffies;
else if (jiffies - HostAdapter->LastSequencePoint[TargetID] > 2*HZ)
{
HostAdapter->LastSequencePoint[TargetID] = jiffies;
QueueTag = BusLogic_OrderedQueueTag;
}

Just a few lines of code will prevent the problem...

Leonard