lkml.org 
[lkml]   [2000]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sym53c8xx syslog messages from 2.2.14
On 21 Feb 2000, Patrick J. LoPresti wrote:
>One of our systems (running stock 2.2.14) is generating syslog
>messages like these very frequently, especially when the machine is
>busy. I tried lowering the TCQ depth to 8 but it did not make any
>difference.

How did you set it to 8? You may need to wack the kernel with a 2x4
to get it to behave (read: delete sections of the scsi driver.) You
are free to use that same 2x4 on Quantum and the scsi driver author.

>Could someone tell me what they mean and how I can make them stop?

First off, the driver attempts to ajust the queue depth based on
a number of factors (only one of which is the user.) On a QUEUE FULL
condition from the drive, the driver drops the queue depth down to
how ever many commands are currently queued. The queue depth is increased
after 1000 commands are successful.

First off, the SCSI specs say any device reporting tagged command queuing
capabilties MUST support a minimum of 8 queued commands. Thus, setting it
lower than 8 should never be necessary. HOWEVER, some manufacturers'
(read: Quantum) drives "don't work right." They signal command completion
before they are ready for the next command -- who knows what kind of crazy
shit is going on in the microcode.

The Quantum Altas I was _very_ _very_ bad at handling queuing. They fixed
some of it in later microcode, but it still lies about command completion.
(I should be able to remove power from the drive the instant it signals
command completion.)

You will need to set the queue depth to _8_ and make sure the damned driver
never tries to change it. On QUEUE FULL, the driver should wait a second
and _then_ re-queue the command. I had similar problems with a qlogicpti
like board in a sparc20 -- in that case, it was the card's command queue
overflowing instead of a drive, but same difference.

--Ricky

PS: I've got some IBM drives eating 64 queued commands :-) This introduces
some interesting behavior from the kernel thinking commands are timing
out :-) (4M buffer on the drive, BTW)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.043 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site