Messages in this thread | | | Date | Tue, 22 Feb 2000 21:02:08 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: sym53c8xx syslog messages from 2.2.14 |
| |
On Mon, 21 Feb 2000, Ricky Beam wrote:
> 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.
For the [sym/ncr]53c8xx driver, you must refer to:
/usr/src/linux/drivers/scsi/README.ncr53c8xx
> >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.
I have 1 Atlas 1, 2 Atlas 2 and 1 Atlas 4. The Atlas 4 is a lot better, but the driver copes with all these drives.
> The Quantum Altas I was _very_ _very_ bad at handling queuing. They fixed
You get with Quantum Atlas < 4 drives in mono-initiator what you get with any other drive in multi-initiator environment. A SCSI subsystem that can work in multi-initiator environment must work with Quantum drives.
> 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.)
I does lie only if you enable write behind caching and FUA bit is not set for writes, which is correct.
> You will need to set the queue depth to _8_ and make sure the damned driver > never tries to change it.
/usr/src/linux/damned_drivers/scsi/README.ncr53c8xx
> 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.
The suggested method is to wait for a command completion from the offending device prior to requeuing any subsequent command to this device. The sym53c8xx driver does shrink its internal device queue depth up to the number of _actually_ disconnect commands which has the _same_ effect.
Then, the device queue depth will be incremented later based on some fixed amount of _successful_ commands. This scales quite well with a very low overhead. This has been implemented and tuned based on the behaviour of Atlas drives.
Gérard.
> --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)
I have such a 10000 rpm drive. I use it with 32 tags under Linux and 64 tags under FreeBSD. No problem. Btw, the Viking II from Quantum also supports such an amount of tagged commands (may-be only 63, but it is equivalent). This depends mostly on the firmware.
- 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/
| |