Date: Sun, 12 Dec 1999 18:18:55 -0800 (PST) From: klh@netcom.com To: freebsd-gnats-submit@freebsd.org Subject: kern/15446: Unpredictable enabling of SCSI Tagged Queueing Message-ID: <19991213021855.0010914CB3@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 15446
>Category: kern
>Synopsis: Unpredictable enabling of SCSI Tagged Queueing
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Dec 12 18:20:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator: Ken Harrenstien
>Release: 3.1-RELEASE
>Organization:
>Environment:
FreeBSD <hostname> 3.1-RELEASE FreeBSD 3.1-RELEASE #<n>: <buildstring> i386
>Description:
Whether or not a device capable of tagged queueing is actually flagged
as such appears to be semi-random. It can be different for two identical
drives, and can change from one boot to the next of the same kernel.
For example, on one recent boot, two identical drives give this:
da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled
...
da2: 10.0MB/s transfers (10.0MHz, offset 15)
In conjunction with another problem which I am filing separately (the
possibility that the Seagate ST32550WC is broken with respect to
tagged queueing) this causes my system to sometimes work and sometimes
fail depending on the level of disk activity. I did not notice this
earlier because until recently I have not significantly stressed the
disk I/O. Now that it's a problem I've reviewed the system logs for
the past few months and found that sometimes tagged queueing was
enabled and sometimes not.
FWIW the version of cam_xpt.c in my source tree is 1.42. There are
a few too many things involved in the enable/disable code for me to be
certain what is going on or whether the flags are even being initialized
properly.
I looked at the CVS log for this file but could not be sure whether
the problem had been noticed or addressed in later revs. Ditto
GNATS. It seems unlikely that a problem like this could have
escaped notice until now, so this bug report is more of a preliminary
check to find out whether it's worth sending additional info.
>How-To-Repeat:
Unknown, but I can reproduce the variability quite reliably and am
willing to test some number of changes to 3.1-RELEASE, as well as
send additional info like system log output for the last few months
(too long for this form).
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991213021855.0010914CB3>