[2931] in linux-scsi channel archive
Re: DPT 2044U and Quantum Fireball ST4.3
daemon@ATHENA.MIT.EDU (mike@magpies.com)
Tue Dec 16 02:34:42 1997
Date: Tue, 16 Dec 1997 01:15:30 -0600 (CST)
From: <mike@magpies.com>
To: linux-eata@goofy.zdv.Uni-Mainz.de, linux-scsi@vger.rutgers.edu
In-Reply-To: <199712160451.VAA08057@mza.com>
I would also be very interested in a response to many of his questions as
I have a similiar setup using a 2144UW and have had the pleasure of some
corrupted file systems when I tried to switch kernels.
Mike Masoni
mike@magpies.com
http://www.magpies.com
check out our javascript translator
On Mon, 15 Dec 1997, Zane Dodson wrote:
> Hello,
>
> I'm having a problem with my DPT 2044U and a Quantum Fireball ST4.3. Below
> is my hardware configuration:
>
> Here's an excerpt from the system log for this machine running 2.0.30.
>
> EATA (Extended Attachment) driver version: 2.59b
> developed in co-operation with DPT
> (c) 1993-96 Michael Neuffer, mike@i-Connect.Net
> Registered HBAs:
> HBA no. Boardtype Revis EATA Bus BaseIO IRQ DMA Ch ID Pr QS S/G IS
> scsi0 : PM2044U v07K.Y 2.0c PCI 0x6110 11 BMST 1 7 N 64 252 Y
> scsi0 : EATA (Extended Attachment) HBA driver
> scsi : 1 host.
> Vendor: QUANTUM Model: FIREBALL ST4.3S Rev: 0F0C
> Type: Direct-Access ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
> scsi0: queue depth for target 0 on channel 0 set to 64
>
> The Quantum drive is the only peripheral on the bus. It has its
> terminator enabled jumper set. Also, I have turned ON termination in
> the DPT PCI SCSI BIOS. So, my SCSI bus is properly terminated
> at the adapter end and the disk end.
>
> I have found that if I have tagged queuing enabled in the DPT PCI BIOS,
> I can get severe filesystem corruption. However, disabling tagged queuing in
> the DPT BIOS results in a stable system. I contacted both Quantum and
> DPT. Quantum explained that their drive had no reported problems with
> supporting tagged queuing, but the maximum depth was 8. DPT echoed similar
> sentiments in that they had no reported problems with the combination of
> hardware and tagged queuing.
>
> Does anyone have any information about this particular hardware combination?
> I have long been confused by the many driver choices I have. Is one
> of the EATA drivers recommended above the others? (I'm using eata_dma at the
> moment, but there's EATA-PIO and just EATA which I haven't yet tried.)
> I have many machines with DPT controllers in them. I have a 2044U, 2144UW,
> a 3334UW, and a 3334UDW with an SX4030UW/2 added on. Should I choose
> the eata_dma driver for all these controllers? Also, I found in the
> eata.c source file a listing of all the boot-time/command-line options for
> the eata driver. However, I could not find a similar listing for the
> eata_dma driver. Can I disable tagged queuing on a target-by-target basis?
> Can I set the maximum queue depth on a target-by-target basis?
>
> It is interesting that the queue depth of target 0 above is set to 64
> (this is true regardless of the setting of the DPT BIOS option for tagged
> queuing -- I suspect in the case where the DPT BIOS option for tagged
> queuing is off, this parameter is ignored). What happens if the drive
> only supports a queue depth of 8 and the driver attempts 64? Given the
> filesystem errors that resulted, it would appear that the commands
> are discarded and never processed.
>
> Also, I found it interesting that in another machine with a 2144UW (a
> Quantum Fireball ST4.3 on 0 and a Jaz drive on 2), the queue depth was
> set to 32 for both targets. Is the total of 64 divided between the two
> drives in this case? I haven't yet had a problem with this particular
> hardware/software configuration, but it hasn't been used as heavily.
>
> I'd be interested in a brief explanation of how the tagged queuing is
> implemented and how the DPT negotiates this setting with each drive.
> The theory of operation section in the DPT manual seems to indicate the
> controller is capable of 64 outstanding commands and I'm assuming this
> has to be divided among the target devices attached.
>
> Any comments would be appreciated and more information can be provided.
>
> Best regards,
>
> Zane Dodson
> dodson@mza.com
>
