From owner-freebsd-scsi Sun Jan 7 6:54:46 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id 7714237B79C for ; Sun, 7 Jan 2001 06:43:54 -0800 (PST) Received: from nas1-7.mea.club-internet.fr (nas1-7.mea.club-internet.fr [195.36.139.7]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA11800; Sun, 7 Jan 2001 15:43:44 +0100 (MET) Date: Sun, 7 Jan 2001 14:43:17 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Darren Joy Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 6 Jan 2001, Darren Joy wrote: > I wrote to this list at the end of November with a problem I was having > with 4.2 Release and my Tekram DC390W. I had the machine running 3.2 > Release happily, without any problems. Then as I reinstalled with 4.2, I > found that the machine would lock up with errors reported from the SYM > driver. >=20 > I have revisited this hardware now with the intention of getting it > running rather than sitting there switched off. I want my machine back! >=20 > In response to my last post, Gerard suggested a using the "ncr" driver > instead of "sym", as this was the one used in 3.2. You said NCR worked for you in 3.2, and SYM stated about a device problem it was unable to work around. The device seemed to forget about IOs that wasn't finished yet and to reselect for IOs that didn't exist anymore as seen from the driver. > By doing a 4.2 install, and omitting the ports and src, I managed to get > FreeBSD installed on this machine before it locked up. Then post > installation, added the sources distribution and made my custom kernel > using the "ncr" driver. >=20 > Alas, I am still seeing problems, the symptoms being the same as those > experienced with the "sym" driver. >=20 > If I try to install the ports distibution, I get the following errors : >=20 > ncr0: queue empty > ncr0: queue empty > ncr0: queue empty > ncr0: queue empty > Looks like the device is returning QUEUE FULL status and the NCR does not see any command currently pending at device side (i.e. SCSI I/O having been disconnected). > A colleague once suggested to me that disabling Tagged Command Queueing > could help. This I did in the controller BIOS, however upon bootup I see = : Tagged Commands + Write Behind Caching is good at stressing SCSI device=20 firmware and revealing firmware bugs. Disabling either may help, but,=20 depending on actual I/O pattern, the latter may help better. - Synchronous writes (waited for completion synchronously) are helped by Write Caching. The device is just lying to the O/S by deferring the actual write of data to the medium. - Multi-threaded I/Os (i.e. can be several sequential I/O streams running concurrently or kind of random I/Os) are helped by Tagged Command Queuing. Btw, disabling Write Caching only tells the device to signal completion once the data have been actually written to the medium, but doesn't disallow the device to use its ram buffers neither to reorder concurrent I/Os. > /kernel: ncr0: port 0xe400-0xe4ff mem > 0xeb001000-0xeb001fff,0xeb000000-0xeb0000f > f irq 15 at device 15.0 on pci0 >=20 > /kernel: da0 at ncr0 bus 0 target 0 lun 0 > /kernel: da0: Fixed Direct Access SCSI-2 d= evice > /kernel: da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing= Enabled > /kernel: da0: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) >=20 > My thinking here is that disabling Tagged Command Queueing may cure my > woes, but FreeBSD seems to be enabling it regardless! Not regardless IMO. It does so if: - The SIM returns this feature to CAM as user setting for the device. _and_ (&&) - The device claims support for this feature in INQUIRY response. > I have double-checked the controller BIOS, and Tagged Command Queueing is > definitely disabled for this device ( there's no option to disable it > globally ), indeed, disabled for every individual device. I even tried > reducing the queue length to the minimum setting allowed in the BIOS, but > to no avail. And of course, I have tried it with Tagged Queueing enabled. What you tell to the board BIOS is stored in the controller NVRAM. The NVRAM content may be read by the SIM (low-level driver) and its content reported to CAM appropriately. This is what the SYM driver wants to do. But NCR does not try to read the NVRAM of your controller. After boot you can use `camcontrol' to disable Tagged Queueing for your disk. > Can anyone offer any help as to how I might get the NCR ( or SYM ) to > disable Tagged Command Queueing? SYM may report to CAM your disabling of TCQ in NVRAM. I just never tested it personnaly with Tekram boards for the reason I haven't any of these boards. I bought a Promise and a Tyan 53C8xx board in the past and all my recent 53C8xx boards are SYMBIOS/LSILOGIC boards that have been donated to me (1 by Varesearch and 3 by Symbios/LsiLogic). > Any ideas appreciated. FYI, the CONNER CFT2107* (not the 2105) is blacklisted for Tagged Queuing in CAM. Dunno how different/similar these devices actually are. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message