Messages in this thread | | | Date | Mon, 21 Feb 2000 14:05:22 -0500 (EST) | From | Ricky Beam <> | Subject | Re: 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/
| |