From owner-aic7xxx Tue Jan 6 22:16:32 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA15493 for aic7xxx-outgoing; Tue, 6 Jan 1998 22:16:32 -0800 (PST) (envelope-from owner-aic7xxx) Received: from paperboy.ids.net (paperboy.ids.net [155.212.1.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA15473 for ; Tue, 6 Jan 1998 22:16:21 -0800 (PST) (envelope-from mikebw@bilow.bilow.uu.ids.net) Received: from bilow.bilow.uu.ids.net (uucp@localhost) by paperboy.ids.net (8.8.8/8.8.8) with UUCP id BAA05601; Wed, 7 Jan 1998 01:05:00 -0500 (EST) Received: by bilow.bilow.uu.ids.net (uugate-034-OS/2-230); Wed, 07 Jan 98 05:51:06 -0000 Date: Wed, 07 Jan 98 05:20:00 -0000 Message-ID: <4b309a26@bilow.bilow.uu.ids.net> From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: Tagged Queueing and Dque Bit To: aic7xxx@freebsd.org Reply-To: mikebw@bilow.bilow.uu.ids.net X-Mailer: uugate 0.34 (OS/2 2.30) Sender: owner-aic7xxx@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Daniel M. Eischen wrote in a message to Mike Bilow: > If the mid-level SCSI code is depending solely upon the INQUIRY > response without either reading or writing the Control Mode > Page, then this is a clear error that needs to be fixed -- it > may solve a lot of problems. DME> I don't have the Linux mid-level SCSI code handy, but it is DME> indeed checking the INQUIRY response and setting the tagged DME> queueing bit in the Scsi_Device structure. This bit in the DME> device structure, along with driver configuration options, DME> are the only things that the driver looks at in determining DME> whether to perform tagged queueing or not. Whoever sets DME> this bit (the Linux mid-level SCSI code) should be the DME> responsible party. Furthermore, SCSI commands should come DME> from the Linux mid-level SCSI code and not from the driver DME> (with the exception of the sense request). I agree that the mid-level SCSI code is responsible, and the behavior you describe is wrong: the DQue bit on the Control Mode Page should be either read or written before tagged queueing is enabled. To some extent, the state of the DQue bit is a user responsibility outside the responsibility of the code, something like termination, but I think it is good practice to at least warn of any inconsistencies we detect. Technically, my understanding was that the Scsi_Device structure bit was to be interpreted by the driver as necessary but not sufficient. One could even take it as a mere suggestion, since the driver is not even obliged to support tagged queueing. It might be worth clarifying exactly what the bit is supposed to mean, since it is obviously critical that the mid-level SCSI code and all drivers should interpret it in the same way. That said, it would certainly be a good idea for the mid-level SCSI code to read or write the DQue bit before setting the bit in the Scsi_Device structure. DME> Ahh, but we're not in a good position to do this. And when you DME> think about how this affects other drivers you'll see why it is DME> better in the mid-level SCSI code anyways - why have duplicate DME> code in each driver doing exactly the same thing? I see your point, but the definition of the bit in the Scsi_Device structure is at issue: it could mean "If drivers want do tagged queueing then we don't have any problem with that up here," or it could mean "It is safe for drivers to do tagged queueing." These are very different things. -- Mike