headers
Bryan Henderson | 1 Apr 2005 01:27
Picon
Favicon

Re: How to find which (physical) SCSI HBA corresponds to which host n umber?

By default, Linux assigns host numbers to HBAs somewhat arbitrarily.  In 
practice, it's fairly predictable as long as you don't change anything -- 
Linux assigns them sequentially starting at zero in the order in which it 
discovers them, which is controlled first by the order in which Linux 
initializes the corresponding HBA driver.

But you can control it a little.  The 'scsihosts' module parameter of the 
SCSI midlayer driver scsi_mod reserves host numbers for specific HBA 
drivers.  It looks like "scsihosts=aic7xxx,aic7xxx,qla1280".  That means 
to reserve host numbers 0 and 1 for the aic7xxx driver and 2 for qla1280. 
The two reserved for aic7xxx are assigned in the order that the aic7xxx 
driver registers them, which is ordinarily the order in which the aic7xxx 
driver detects them.  I don't think there's usually a way to control that, 
but it should be repeatable as long as the hardware configuration stays 
the same.  But it's generally not good to rely on the hardware 
configuration staying the same.  Some day, one card will be broken or 
temporarily removed, and that will change the host number of the other 
one.

As with other SCSI numbering (LUNs, Linux device numbers), you normally 
don't try to prescribe which numbers go to which equipment, but rather 
discover afterward -- proc/scsi/hba_name/host_number.  The identifying 
information is dependent on the particular HBA type and driver, and 
sometimes doesn't exist.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Apr 2005 06:18
Picon

Re: [PATCH scsi-misc-2.6 01/13] scsi: don't use blk_insert_request() for requeueing

On Thu, Mar 31, 2005 at 11:12:11AM +0100, Christoph Hellwig wrote:
> On Thu, Mar 31, 2005 at 06:07:55PM +0900, Tejun Heo wrote:
> > 01_scsi_no_REQ_SPECIAL_on_requeue.patch
> > 
> > 	blk_insert_request() has 'reinsert' argument, which, when set,
> > 	turns on REQ_SPECIAL and REQ_SOFTBARRIER and requeues the
> > 	request.  SCSI midlayer was the only user of this feature and
> > 	all requeued requests become special requests defeating
> > 	quiesce state.  This patch makes scsi midlayer use
> > 	blk_requeue_request() for requeueing and removes 'reinsert'
> > 	feature from blk_insert_request().
> > 
> > 	Note: In drivers/scsi/scsi_lib.c, scsi_single_lun_run() and
> > 	scsi_run_queue() are moved upward unchanged.
> 
> That lest part doesn't belong into this patch at all.

 Actually, it is, as scsi_queue_insert() is changed to call
scsi_run_queue() explicitly.  However, scsi_queue_insert() is removed
later, so the change is pretty dumb.  Maybe I'll add prototype and
remove it together later, or reorder patches.

 Thanks.

--

-- 
tejun

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajat Jain, Noida | 1 Apr 2005 06:23

RE: How to find which (physical) SCSI HBA corresponds to which ho st n umber?


Hi Bryan,

Thanks for the reply. I got my queries solved. 

> 
> As with other SCSI numbering (LUNs, Linux device numbers), 
> you normally don't try to prescribe which numbers go to which 
> equipment, but rather discover afterward -- 
> proc/scsi/hba_name/host_number.  The identifying information 
> is dependent on the particular HBA type and driver, and 
> sometimes doesn't exist.
> 

This proc entry is made AFTER the device is registered with SCSI mid-level
driver (scsi_mod). 

I have a system with "N" number of similar HBAs attached. So basically what
that means is that after I add a SCSI device to one of the HBAs, the only
option I have left with me is following

For n = 0 to N
Do
	echo "scsi add-single-device n 0 ID 0" > /proc/scsi/scsi
done

i.e. trial and method that tries to scan for the particular target on ALL
the HBAs???

Rajat
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tejun Heo | 1 Apr 2005 07:01
Picon

Re: [PATCH scsi-misc-2.6 01/13] scsi: don't use blk_insert_request() for requeueing

 Hello, James.

On Thu, Mar 31, 2005 at 11:53:20AM -0600, James Bottomley wrote:
> On Thu, 2005-03-31 at 18:07 +0900, Tejun Heo wrote:
> > 01_scsi_no_REQ_SPECIAL_on_requeue.patch
> > 
> > 	blk_insert_request() has 'reinsert' argument, which, when set,
> > 	turns on REQ_SPECIAL and REQ_SOFTBARRIER and requeues the
> > 	request.  SCSI midlayer was the only user of this feature and
> > 	all requeued requests become special requests defeating
> > 	quiesce state.  This patch makes scsi midlayer use
> > 	blk_requeue_request() for requeueing and removes 'reinsert'
> > 	feature from blk_insert_request().
> 
> Well, REQ_SPECIAL is the signal to the mid-layer that we've allocated
> the resources necessary to process the command, so in practice it will
> be turned on for every requeue request (because we set it when the
> command is prepared),

 Sorry, but where?  AFAICT, only blk_insert_request() and
scsi_init_io() on sgtable allocation failure set REQ_SPECIAL during
scsi midlayer processing.  This patch replaces blk_insert_request()
with blk_requeue_request() and the next patch removes REQ_SPECIAL
setting in scsi_init_io().

 REQ_SPECIAL is currently overloaded to mean two different things.

 * The request is a special request.
 * The request has been requeued using scsi_queue_insert().
   i.e. It has been prepped.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Apr 2005 07:14
Picon

Re: [PATCH scsi-misc-2.6 02/13] scsi: don't turn on REQ_SPECIAL on sgtable allocation failure.

 Hello, James.

On Thu, Mar 31, 2005 at 11:53:45AM -0600, James Bottomley wrote:
> On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote:
> > 	Don't turn on REQ_SPECIAL on sgtable allocation failure.  This
> > 	was the last place where REQ_SPECIAL is turned on for normal
> > 	requests.
> 
> If you do this, you'll leak a command every time the sgtable allocation
> fails.

 AFAICT, not really.  We don't allocate another scsi_cmnd for normal
requests if req->special != NULL.

 Thanks.

--

-- 
tejun

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Apr 2005 07:15
Picon

Re: [PATCH scsi-misc-2.6 04/13] scsi: remove meaningless volatile qualifiers from structure definitions

 Hello, Chritoph.

On Thu, Mar 31, 2005 at 11:11:45AM +0100, Christoph Hellwig wrote:
> On Thu, Mar 31, 2005 at 06:08:10PM +0900, Tejun Heo wrote:
> >  	struct list_head    siblings;   /* list of all devices on this host */
> >  	struct list_head    same_target_siblings; /* just the devices sharing same target id */
> >  
> > -	volatile unsigned short device_busy;	/* commands actually active on low-level */
> > +	unsigned short device_busy;	/* commands actually active on
> > +					 * low-level. protected by sdev_lock. */
> 
> You should probably switch it to just unsigned.  The other 16bit are wasted
> due to alignment anyway, and some architectures produce better code for 32bit
> accesses.
> 
> > -	volatile unsigned short host_busy;   /* commands actually active on low-level */
> > -	volatile unsigned short host_failed; /* commands that failed. */
> > +
> > +	/*
> > +	 * The following two fields are protected with host_lock;
> > +	 * however, eh routines can safely access during eh processing
> > +	 * without acquiring the lock.
> > +	 */
> > +	unsigned short host_busy;	   /* commands actually active on low-level */
> > +	unsigned short host_failed;	   /* commands that failed. */
> 
> Here it would actually increase the struct size but might make sense anyway.

 Sure, I'll make them unsigned.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Apr 2005 07:15
Picon

Re: [PATCH scsi-misc-2.6 05/13] scsi: remove a timer race from scsi_queue_insert() and cleanup timer

 Hello, Chritoph.

On Thu, Mar 31, 2005 at 11:13:53AM +0100, Christoph Hellwig wrote:
> >  		/* Queue the command and wait for it to complete */
> >  		/* Abuse eh_timeout in the scsi_cmnd struct for our purposes */
> >  		init_timer(&cmd->eh_timeout);
> > +		cmd->eh_timeout.function = NULL;
> 
> I'd rather not see aic7xxx poke even deeper into this internal code.
> Can you please switch it to use a timer of it's own first?

 Yes, I'll.

 Thanks.

--

-- 
tejun

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Apr 2005 07:20
Picon

Re: [PATCH scsi-misc-2.6 08/13] scsi: move request preps in other places into prep_fn()

 Hello, Christoph.

On Thu, Mar 31, 2005 at 11:20:40AM +0100, Christoph Hellwig wrote:
> > +/*
> > + * Macro to determine the size of SCSI command. This macro takes vendor
> > + * unique commands into account. SCSI commands in groups 6 and 7 are
> > + * vendor unique and we will depend upon the command length being
> > + * supplied correctly in cmd_len.
> > + */
> > +#define CDB_SIZE(cmd)	(((((cmd)->cmnd[0] >> 5) & 7) < 6) ? \
> > +				COMMAND_SIZE((cmd)->cmnd[0]) : (cmd)->cmd_len)
> 
> should probably go to scsi.h as it's generally usefull.

 I don't know.  Currently it's used only in one place.  Actually, I
was thinking about moving it into the function where it's used.  But
if it's useful, renaming it to something like SCSI_CMD_CDB_SIZE()
(maybe make it inline function?) and moving to scsi.h shouldn't be any
problem.  I think we need to hear other people's opinions.  Some
inputs please.

 Thanks.

--

-- 
tejun

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Apr 2005 07:25
Picon

Re: [PATCH scsi-misc-2.6 08/13] scsi: move request preps in other places into prep_fn()

 Hello, James.

On Thu, Mar 31, 2005 at 12:07:44PM -0600, James Bottomley wrote:
> On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote:
> > 	Move request preparations scattered in scsi_request_fn() and
> > 	scsi_dispatch_cmd() into scsi_prep_fn().
> > 
> > 	* CDB_SIZE check in scsi_dispatch_cmd()
> > 	* SCSI-2 LUN preparation in scsi_dispatch_cmd()
> > 	* scsi_init_cmd_errh() in scsi_request_fn()
> > 
> > 	No invalid request reaches scsi_request_fn() anymore.
> 
> This one, I like, there's just one small problem:
> 
> You can't move scsi_init_cmd_errh() out of the request function path:
> It's where we set up the sense buffer handling, so it has to be done
> every time the command is prepared for execution (the prep function is
> only called once)---think what happens if we turn a command around for
> retry based on a sense indication.
> 
> So redo the patch and I'll put it in.

 Ah.. with later requeue path consolidation patches, all requests get
their sense buffer cleared during requeueing, which, IMHO, is more
logical.  Moving scsi_init_cmd_errh() should come after the patch.
Sorry. :-)

 I'll make another take of this patchset (maybe subset) after issues
are resolved.  I'll split and reorder relocation of scsi_init_cmd_errh
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Apr 2005 07:29
Picon

Re: [PATCH scsi-misc-2.6 09/13] scsi: in scsi_prep_fn(), remove bogus comments & clean up

 Hello, James.

On Thu, Mar 31, 2005 at 12:02:20PM -0600, James Bottomley wrote:
> On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote:
> > -	 * come up when there is a medium error.  We have to treat
> > -	 * these two cases differently.  We differentiate by looking
> > -	 * at request->cmd, as this tells us the real story.
> > +	 * come up when there is a medium error.
> 
> This comment isn't wrong.  That's exactly what this piece of code:
> 
> 		if (sreq->sr_magic == SCSI_REQ_MAGIC) {
> 
> is all about ... that's how it distinguishes between the two cases.
> 
> The comment is misleading --- what it actually should say is that req-
> >special has different contents depending upon the two cases, so
> rephrasing it to be more accurate would be helpful.

 Yes, it was misleading, even more so with previous REQ_SPECIAL
patches.  I'll rewrite the comment once we resolve the REQ_SPECIAL
issue.

 Thanks.

--

-- 
tejun

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
(Continue reading)

Permalink | Reply | 0 comments |

Gmane