[8608] in linux-scsi channel archive
Re: [PATCH] add-single-device [was: inducing SCSI bus scan]
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Wed Apr 12 13:46:45 2000
Message-ID: <002301bfa49f$ff116a70$4d0310ac@fairfax.datafocus.com>
From: "Eric Youngdale" <eric@andante.org>
To: "Doug Ledford" <dledford@redhat.com>, <mkwasigr@INTERCOPE.COM>
Cc: "Douglas Gilbert" <dgilbert@interlog.com>,
<linux-scsi@vger.rutgers.edu>
Date: Wed, 12 Apr 2000 12:56:07 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
----- Original Message -----
From: Doug Ledford <dledford@redhat.com>
To: <mkwasigr@INTERCOPE.COM>
Cc: Douglas Gilbert <dgilbert@interlog.com>; Eric Youngdale
<eric@andante.org>; <linux-scsi@vger.rutgers.edu>
Sent: Wednesday, April 12, 2000 4:56 AM
Subject: Re: [PATCH] add-single-device [was: inducing SCSI bus scan]
> OK, I've added code in the 5.1.29 driver to address this problem. It
should
> exist any more. The general issue is that during the normal bus scan, the
mid
> layer SCSI code frobs around with device->queuing_supported (or something
like
> that) and we use that to determine if we should enabled TCQ on that device
> when the mid layer calls our select_queue_depths() routine. However, when
you
> do a scsi-add-single-device, the select_queue_depths() routine gets called
> once again with the same arguments as before, the complete device list,
but
> this time the devices don't have the queueing supported flag set. This
was
> causing the aic7xxx driver to reset the devices to untagged status as it
> rescanned the list.
Yes, I am thinking that the interface for selecting queue depths might
need to be redone so that it is essentially done on a device-by-device
basis - for the single unit scan case this would work out better anyways.
The only question I have is whether or not there is a circumstance where the
queue depth is more logically considered to be a bus concept rather than a
device concept. This is probably something for the todo list for 2.5 rather
than something that we need to address right now. I don't have a clear idea
in my mind of exactly how this interface is used by the various driver
authors anyways, and until I do I would prefer to leave it alone.
> My fix for this in the driver was to simply check the
> p->max_queue_depth[device] entry in the aic7xxx driver for each device in
the
> device list. If that entry is not at the default setting, then I assume
its
> queue depth has already been set and I leave it at what it currently is.
> Otherwise, I set it.
>
> The one thing I didn't check is if the scsi-add-single-device code bothers
to
> frob the queueing supported flag before calling into the
select_queue_depths()
> routine. If it doesn't, then devices added after the normal scan will
always
> get set to untagged status.
For new devices, it looks like that flag is cleared, but the logic is
the same for all cases (i.e. bootup, module load and insertion via proc
filesystem), so this end of things is *probably* ok. The code fragment
where this gunk is set is below (from a 2.3.51 kernel):
/*
* Set the tagged_queue flag for SCSI-II devices that purport to support
* tagged queuing in the INQUIRY data.
*/
SDpnt->tagged_queue = 0;
if ((SDpnt->scsi_level >= SCSI_2) &&
(scsi_result[7] & 2) &&
!(bflags & BLIST_NOTQ)) {
SDpnt->tagged_supported = 1;
SDpnt->current_tag = 0;
}
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
