[8116] in linux-scsi channel archive
Re: scsi queue depth problem
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Tue Feb 15 23:10:43 2000
Message-ID: <001901bf782a$d2398dd0$0f17a8c0@eric.home>
From: "Eric Youngdale" <eric@andante.org>
To: "Ralston, Steve" <steve.ralston@lsil.com>,
"'Douglas Gilbert'" <dgilbert@724.com>
Cc: <linux-scsi@vger.rutgers.edu>
Date: Tue, 15 Feb 2000 22:06:29 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
For a moment I thought I understood the problem. I added an entry in
the host template for select_queue_depths, mainly to make the thing
symmetric WRT all of the other entrypoints. Back when this stuff got
added, we didn't have the lisp-like initializers, and as a result an
addition of this sort would have required patching each and every low-level
driver.
Unfortunately I looked over my patches, and the thing I changed won't
explain it.
There was one other thing which I did that might explain the issue. I
was cleaning up the way that scan_scsis() works, mainly to fix it so that it
does less under-the-hood hacking of the underlying datastructures, and it
essentially uses existing interfaces much more like the way that sd.c would,
for example. When we are scanning the bus, I just force the queue depth to
1, as this is all we need for the purposes of scanning the bus. When I am
finished scanning the bus for a device, I release the single commandblock,
but I never reset the queue_depth for the device back to 0. It is
theoretically possible that in the select_queue_depths function that a
low-level driver would look at the queue depth for a device and decide that
if the value were non-zero that it should leave it alone.
The quick-hack way to test this theory is to simply zero the queue depth
in scsi_release_commandblocks(). The real fix is to probably set the queue
depth back to 0 in scan_scsis(), but first I would like to see confirmation
that this explains the problem.
-Eric
----- Original Message -----
From: "Ralston, Steve" <steve.ralston@lsil.com>
To: "'Douglas Gilbert'" <dgilbert@724.com>
Cc: <eric@andante.org>; <linux-scsi@vger.rutgers.edu>
Sent: Tuesday, February 15, 2000 7:17 PM
Subject: RE: scsi queue depth problem
> Yes, you gather correctly. :-)
> I was just cruising along doing periodic kernel source tree
> updates while working on the (SCSI) driver, and happened
> to notice that beating on the disk, well "sounded different"
> after updating from linux-2.3.42. When I tried to figure out why,
> I noticed lack of [any] usual:
> <6>mpiscsi: Queue depth now {2-64}.
> debug printk's in my sysklog... Indicating to me that I'm
> choked down to 1 deep.
>
> > If the midlevel restricts your device queue to 1 then
> > that is a problem with either
> > - the mid-level
> > - or your driver's callback function provided to
> > calculate queue depth.
>
> The driver source did not change (famous last words) when
> I noticed the choke down. Sooo, I guess that means
> a problem introduced in the scsi mid-level? @2.3.43?
> That's my big concern and why I posted to the linux-scsi list;
> it's not nice to be cruising along and have things like this
> change this underneath, but hey, that's linux life. :-)
>
> How are you measuring the tagged queueing? From underneath
> (bus analyser), inside your driver or from above (e.g. dd)?
>
> Yes. :-) I noticed this inside the driver. Don't have FC analyzer
> on there, but also measured / confirmed this inside the HAB
> firmware processor(s) using ARM Multi-ICE debugger...
>
> BTW: I'm pretty (99%) sure there's no problem with my 2.3.43,
> 2.3.44, 2.3.45+ikd, nor 2.3.45 stock kernel source trees.
> I even dropped back to stock 2.3.45 kernel to make sure
> my feeble hacks patching in 2.3.40-ikd2 weren't the culprit.
>
> Thanks,
> -SteveR
>
> > -----Original Message-----
> > From: Douglas Gilbert [SMTP:dgilbert@724.com]
> > Sent: Tuesday, February 15, 2000 2:16 PM
> > To: 'Ralston, Steve'; Douglas Gilbert
> > Cc: 'eric@andante.org'
> > Subject: RE: scsi queue depth problem
> >
> > Steve,
> > So it works on 2.3.42 and is restricted to a queue length
> > of 1 on 2.3.45 I gather. Perhaps you could try again to
> > do what I suggested on 2.3.45 . If the midlevel restricts
> > your device queue to 1 then that is a problem with either
> > - the mid-level
> > - or your driver's callback function provided to
> > calculate queue depth.
> >
> > How are you measuring the tagged queueing? From underneath
> > (bus analyser), inside your driver or from above (e.g. dd)?
> > In the unlikely event you are using dd then I have a useful
> > utility called sgp_dd that uses posix worker threads (up to
> > 16) to push multiple scsi commands down a mid-level queue.
> > While this is happening it can be observed with
> > "cd /proc/scsi/sg/debug; cat debug"
> > (if you are using the correct version of sg :-) ).
> > You'll find this utility at http://www.torque.net/sg
> >
> >
> > Doug Gilbert
> >
> > > -----Original Message-----
> > > From: Ralston, Steve [mailto:steve.ralston@lsil.com]
> > > Sent: Tuesday, February 15, 2000 12:35 PM
> > > To: 'Douglas Gilbert'
> > > Cc: 'eric@andante.org'
> > > Subject: RE: scsi queue depth problem
> > >
> > >
> > > Sorry again. I'd already stepped back to linux-2.3.42 kernel
> > > when I tried loading sg. I see the CONFIG_PROC_FS stuff
> > > didn't show up till 2.3.43.
> > >
> > > Not sure where to look next...
> > >
> > > Thanks,
> > > -SteveR
> > >
> > > > -----Original Message-----
> > > > From: Douglas Gilbert [SMTP:dgilbert@724.com]
> > > > Sent: Tuesday, February 15, 2000 11:20 AM
> > > > To: 'steve.ralston@lsil.com'
> > > > Cc: 'eric@andante.org'
> > > > Subject: RE: scsi queue depth problem
> > > >
> > > > Steve,
> > > > You wrote (on the linux-scsi newsgroup):
> > > > > > Perhaps you could load the sg driver and try:
> > > > > > $ cd /proc/scsi/sg
> > > > > > $ cat device_hdr devices
> > > > > > $ cat host_hdr hosts
> > > > > Sorry, I've tried loading the sg driver, but it is not
> > > yielding ANY
> > > > > /proc/scsi entries, even though I definitely have CONFIG_PROC_FS
> > > > > set in my kernel/module builds. (I don't even see CONFIG_PROC_FS
> > > > > anywhere in drivers/scsi/sg.c)
> > > >
> > > > It seems as though your kernel source tree has problems.
> > > > According to a kernel source browser such as:
> > > > http://zaphod.redwave.net/linux/kernel-2.3/
> > > >
> > > > CONFIG_PROC_FS appears 7 times in drivers/scsi/sg.c in
> > > > 2.3.45 . Perhaps you should download the complete
> > > > linux-2.3.45 source and retest your queuing problem.
> > > >
> > > > Doug Gilbert
> > >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
