From owner-aic7xxx Tue Jan 6 04:38:00 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA06538 for aic7xxx-outgoing; Tue, 6 Jan 1998 04:38:00 -0800 (PST) (envelope-from owner-aic7xxx) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA06521 for ; Tue, 6 Jan 1998 04:37:55 -0800 (PST) (envelope-from deischen@iworks.InterWorks.org) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id GAA21947; Tue, 6 Jan 1998 06:43:49 -0600 (CST) Message-Id: <199801061243.GAA21947@iworks.InterWorks.org> Date: Tue, 6 Jan 1998 06:43:49 -0600 (CST) From: "Daniel M. Eischen" To: Klaus.Steinberger@Physik.Uni-Muenchen.DE, aic7xxx@freebsd.org Subject: Re: Tagged Queueing and Dque Bit Sender: owner-aic7xxx@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > But with one box it didn't work, until I figured out that the drive > claims to have tagged queueing, but has the Dque bit set to one > in the control mode page (Dque inhibits tagged queueing). > > The driver did time outs and gave me error messages that there is no > active SCB for this drive. [...] > After I figured out the Dque bit, and reset it to zero, it worked flawlessly > with tagged queueing enabled. > > So I would suggest, that the driver should check also the Control Mode > Page (if available), and should honor the Dque bit (fall back to not use > tagged queueing if Dque is set). The driver is not in the business of making it's own SCSI commands and sending them to the target. The mid-level SCSI code and target drivers do this. The mid-level SCSI code detects whether the drive is capable of doing tagged queueing and sets a bit in the SCSI request structure that the driver looks at. If this bit is set, and tagged queueing is enabled in the driver, then you're going to get tagged queueing. If a fix is to be made for this, it belongs in the mid-level SCSI code. [ See linux-scsi@vger.rutgers.edu ] Dan Eischen deischen@iworks.InterWorks.org