From: bugme-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 10554] New: scsi_scan doesn't set the queue depth for tape drive
Date: Fri, 25 Apr 2008 08:29:05 -0700 (PDT) [thread overview]
Message-ID: <bug-10554-11613@http.bugzilla.kernel.org/> (raw)
http://bugzilla.kernel.org/show_bug.cgi?id=10554
Summary: scsi_scan doesn't set the queue depth for tape drive
Product: SCSI Drivers
Version: 2.5
KernelVersion: 2.6.16
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: scsi_drivers-other@kernel-bugs.osdl.org
ReportedBy: flerat@hi-stor.com
Latest working kernel version: 2.6.16
Distribution: Suse
Hardware Environment: IA64
Software Environment: Suse + Backup Software
Problem Description:
scsi_scan doesn't set the queue depth for tape drive.
I'm using an STK 9840B (scsi fiber tape drive) and when I try to acces with 2
driver on the same device, device report an error.
I'm using a software that monitor the tape drive quality. This software use the
"sg" driver to acces to tape drive. The backup software use "st" to read/ write
data.
When the backup software and my software acces in the same time the data
transfert failed.
I'm using a STK 9840B tape drive and when I test with IBM LTO1 it's work.
The main difference between the both drive is that STK doesn't support queue
command (qdepth=1 or 0) and IBM support queue qdepth > 1.
I'm using a qlogic fiber channel, when I'm force the ql2xmaxqdpeth to 1, all is
working very well. But this paramater is for all devices connected to Qlogic
Fiber channel. In my configuartion have 1TB a disk and performence is low due
to qdpeth=1.
On the scsi_scan.c, we have the method scsi_add_lun who read the CmdQue from
the inquiry and set the tagged flag:
if ((sdev->scsi_level >= SCSI_2) && (inq_result[7] & 2) &&
!(*bflags & BLIST_NOTQ))
sdev->tagged_supported = 1;
---> CmdQue = inq_result[7] & 2
STK: CmdQue = 0
IBM: CmdQue = 1
But according to www.t10.org and SPC-2:
"A command queuing (CMDQUE) bit of one indicates that the device supports
tagged tasks (command queuing) for this logical unit (see SAM-2). A value of
zero indicates the device server may support tagged tasks for this logical
unit (see the BQUE bit, above)."
Note the "may support tagged" and in fact if you look the BQUE bit:
STK: BQUE=0
IBM: BQUE=0
For www.t10.org:
BQUE=0, CmdQue=0 : No command queuing of any kind supported.
BQUE=0, CmdQue=1 : Command queuing with all types of task tags supported.
scsi_scan do this:
STK: sdev->tagged_supported = 0 and qdepth = ql2xmaxqdepth
IBM: sdev->tagged_supported = 1 and qdepth = ql2xmaxqdepth
For me, scsi_scan must read the BQUE bit and set the qdepth to 1 for STK and to
max for IBM.
Regards
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
reply other threads:[~2008-04-25 15:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-10554-11613@http.bugzilla.kernel.org/ \
--to=bugme-daemon@bugzilla.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).