Date: Sun, 7 Jan 2001 14:43:17 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Darren Joy <darrenj@uk.uu.net> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release Message-ID: <Pine.LNX.4.10.10101071331300.1107-100000@linux.local> In-Reply-To: <Pine.BSF.4.21.0101061900290.8530-100000@yukon.cam.uk.internal>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> <repeat indefinitely>
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: <ncr 53c825a fast10 wide scsi> 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: <CONNER CFP2105S 2.14GB 1524> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10101071331300.1107-100000>