HBA self selection

HBA self selection

[Cameron, Steve]

Noticed in scsi_scan.c (2.6.15.2 kernel...)

   1336 static void __scsi_scan_target(struct device *parent, unsigned int chann        el,
   1337                 unsigned int id, unsigned int lun, int rescan)
   1338 {
   1339         struct Scsi_Host *shost = dev_to_shost(parent);
   1340         int bflags = 0;
   1341         int res;
   1342         struct scsi_target *starget;
   1343
   1344         if (shost->this_id == id)
   1345                 /*
   1346                  * Don't scan the host adapter
   1347                  */
   1348                 return;
   1349

There exist some target devices which depend on the adapter being
able to do self selection.  The HP MSA30 presents a processor device
at ID 7, for instance.

The processor device at ID 7 will generally not be accessible, because
the HBA is generally at this ID.  The processor device doesn't care that the
HBA is at id 7.  He says, "hmm, the adapter is talking to himself,
that means, he's talking to me."   It's just a way to put a processor
device on the bus without really "using up" a scsi id, since there
are only a few of them.

This used to work, I'm pretty sure.  Could do 
"echo scsi add-single-device 0 0 7 0 > /proc/scsi/scsi" and 
the processor device would show up.  Now it doesn't.

-- steve

Re: HBA self selection

[Matthew Wilcox]

On Thu, Apr 13, 2006 at 09:58:50AM -0500, Cameron, Steve wrote:
> There exist some target devices which depend on the adapter being
> able to do self selection.  The HP MSA30 presents a processor device
> at ID 7, for instance.
> 
> The processor device at ID 7 will generally not be accessible, because
> the HBA is generally at this ID.  The processor device doesn't care that the
> HBA is at id 7.  He says, "hmm, the adapter is talking to himself,
> that means, he's talking to me."   It's just a way to put a processor
> device on the bus without really "using up" a scsi id, since there
> are only a few of them.

Hmm.  That means it never used to work with sym2 -- has anyone ever
tested the MSA30 with an LSI 1010/896 card?  I appreciate it's an U320
device, so that's probably not a common configuration.

I can take the code out that prevents us talking to the bus; it's pretty
much a one-liner:

-        if (sdev->id == np->myaddr) {
-                sym_xpt_done2(np, cmd, DID_NO_CONNECT);
-                return 0;
-        }

but I'd like this change tested, if you wouldn't mind.  After the
midlayer's fixed, of course ;-)

> This used to work, I'm pretty sure.  Could do 
> "echo scsi add-single-device 0 0 7 0 > /proc/scsi/scsi" and 
> the processor device would show up.  Now it doesn't.
> 
> -- steve
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: HBA self selection

[Cameron, Steve]

When you say it never used to work with sym2, you mean
what?  Didn't work at all, or just the prcoessor device at id 7?

I think that most people using an MSA30 don't 
particularly care if they can't talk to the processor devices on
that box, and are unaware of its existence.  They can still access 
the disks just fine. (the MSA30 is a scsi JBOD, essentially.)
Pretty much only HP's SNMP storage agents try to talk
to that processor device, I think, so unless you're running them,
you won't notice or care, so long as the disks are working.

I think we originally saw the problem with an LSI card,
but I forget exactly which one, it used the mptlinux driver,
I think.  

-- steve

-----Original Message-----
From: Matthew Wilcox [mailto:matthew@wil.cx]
Sent: Thu 4/13/2006 10:24 AM
To: Cameron, Steve
Cc: linux-scsi@vger.kernel.org
Subject: Re: HBA self selection
 
On Thu, Apr 13, 2006 at 09:58:50AM -0500, Cameron, Steve wrote:
> There exist some target devices which depend on the adapter being
> able to do self selection.  The HP MSA30 presents a processor device
> at ID 7, for instance.
> 
> The processor device at ID 7 will generally not be accessible, because
> the HBA is generally at this ID.  The processor device doesn't care that the
> HBA is at id 7.  He says, "hmm, the adapter is talking to himself,
> that means, he's talking to me."   It's just a way to put a processor
> device on the bus without really "using up" a scsi id, since there
> are only a few of them.

Hmm.  That means it never used to work with sym2 -- has anyone ever
tested the MSA30 with an LSI 1010/896 card?  I appreciate it's an U320
device, so that's probably not a common configuration.

I can take the code out that prevents us talking to the bus; it's pretty
much a one-liner:

-        if (sdev->id == np->myaddr) {
-                sym_xpt_done2(np, cmd, DID_NO_CONNECT);
-                return 0;
-        }

but I'd like this change tested, if you wouldn't mind.  After the
midlayer's fixed, of course ;-)

> This used to work, I'm pretty sure.  Could do 
> "echo scsi add-single-device 0 0 7 0 > /proc/scsi/scsi" and 
> the processor device would show up.  Now it doesn't.
> 
> -- steve
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HBA self selection

[James Bottomley]

On Thu, 2006-04-13 at 09:24 -0600, Matthew Wilcox wrote:
> I can take the code out that prevents us talking to the bus; it's pretty
> much a one-liner:
> 
> -        if (sdev->id == np->myaddr) {
> -                sym_xpt_done2(np, cmd, DID_NO_CONNECT);
> -                return 0;
> -        }
> 
> but I'd like this change tested, if you wouldn't mind.  After the
> midlayer's fixed, of course ;-)

I really don't think it's a good idea to try to force a HBA to select
it's own address in SPI.  It's certainly illegal under the standard, and
there are many things that could go wrong with this (both inside the HBA
and on the bus).

Steve, how exactly is this supposed to work?  The SPI protocol wasn't
designed to allow two devices on the bus with the same ID.  I'm assuming
the device doesn't do all the things that simply can't work, like
disconnect/reconnect?

James

RE: HBA self selection

[Cameron, Steve]

James Bottomley wrote:

> Steve, how exactly is this supposed to work?  The SPI 
> protocol wasn't designed to allow two devices on the bus 
> with the same ID.  I'm assuming the device doesn't do all 
> the things that simply can't work, like disconnect/reconnect?

I don't really know how it's made to work.

If it's a bad idea for general usage... maybe some 
way to permit it on a per scsi host basis?  Maybe a 
way to enable/disable this feature thru sysfs or 
something, with the default being disabled?

Otherwise our SNMP agents won't be able to know that
fans failed, overtemp etc. in the storage box.

-- steve

RE: HBA self selection

[James Bottomley]

On Thu, 2006-04-13 at 13:35 -0500, Cameron, Steve wrote:
> If it's a bad idea for general usage... maybe some 
> way to permit it on a per scsi host basis?  Maybe a 
> way to enable/disable this feature thru sysfs or 
> something, with the default being disabled?
> 
> Otherwise our SNMP agents won't be able to know that
> fans failed, overtemp etc. in the storage box.

Erm, as I read the MSA30 documentation, it has fourteen drive bays.
That means it has 14 targets plus the processor, so since 16 is the
addressing capacity of a wide SPI bus, there doesn't seem to be a need
to have the initiator and the processor at the same ID ... what's the
reason they have to be?

James

Re: HBA self selection

[Mike Anderson]

James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Thu, 2006-04-13 at 13:35 -0500, Cameron, Steve wrote:
> > If it's a bad idea for general usage... maybe some 
> > way to permit it on a per scsi host basis?  Maybe a 
> > way to enable/disable this feature thru sysfs or 
> > something, with the default being disabled?
> > 
> > Otherwise our SNMP agents won't be able to know that
> > fans failed, overtemp etc. in the storage box.
> 
> Erm, as I read the MSA30 documentation, it has fourteen drive bays.
> That means it has 14 targets plus the processor, so since 16 is the
> addressing capacity of a wide SPI bus, there doesn't seem to be a need
> to have the initiator and the processor at the same ID ... what's the
> reason they have to be?

One could be leaving room for another initiator in a multi-initiator
environment.

To answer the previous question. Since single bit selection is not
supported the peripheral bay can monitor the bus looking for this
condition. Once it sees this state and tries to validate it with some
timing it can assume that the the initiator wants to select the peripheral
bay. It normally does not support disconnects as it is only sending back
SES like data.

-andmike
--
Michael Anderson
andmike@us.ibm.com

RE: HBA self selection

[Cameron, Steve]

James Bottomley wrote:

> Erm, as I read the MSA30 documentation, it has fourteen drive bays.
> That means it has 14 targets plus the processor, so since 16 is the
> addressing capacity of a wide SPI bus, there doesn't seem to be a need
> to have the initiator and the processor at the same ID ... what's the
> reason they have to be?

Probably for the same reason one cuts the end of a pot roast 
off before cooking it.  Because mom did it that way, who did it 
that way because grandma did it that way, and turns out grandma 
did it that way only because her pan wasn't big enough.

MSA30's grandma was an old narrow scsi Proliant jbod that only had
8 IDs to work with -- pan not big enough.  I'm just guessing though.

It is what it is.

-- steve

Re: HBA self selection

[Douglas Gilbert]

Cameron, Steve wrote:
> Noticed in scsi_scan.c (2.6.15.2 kernel...)
> 
>    1336 static void __scsi_scan_target(struct device *parent, unsigned int chann        el,
>    1337                 unsigned int id, unsigned int lun, int rescan)
>    1338 {
>    1339         struct Scsi_Host *shost = dev_to_shost(parent);
>    1340         int bflags = 0;
>    1341         int res;
>    1342         struct scsi_target *starget;
>    1343
>    1344         if (shost->this_id == id)
>    1345                 /*
>    1346                  * Don't scan the host adapter
>    1347                  */
>    1348                 return;
>    1349
> 
> There exist some target devices which depend on the adapter being
> able to do self selection.  The HP MSA30 presents a processor device
> at ID 7, for instance.
> 
> The processor device at ID 7 will generally not be accessible, because
> the HBA is generally at this ID.  The processor device doesn't care that the
> HBA is at id 7.  He says, "hmm, the adapter is talking to himself,
> that means, he's talking to me."   It's just a way to put a processor
> device on the bus without really "using up" a scsi id, since there
> are only a few of them.
> 
> This used to work, I'm pretty sure.  Could do 
> "echo scsi add-single-device 0 0 7 0 > /proc/scsi/scsi" and 
> the processor device would show up.  Now it doesn't.

Steve,
I suppose the lk 2.6 equivalent of:
# echo "0 7 0" > /sys/class/scsi_host/host<n>/scan
doesn't work either? [The reason I ask is that the
new technique works for finding "well known" lus.]

Doug Gilbert

RE: HBA self selection

[Cameron, Steve]

I didn't try it yet, but a cursory look through the code
makes me think it winds up in the same place, __scan_scsi_target,
so I think it probably won't work any differently.  Thanks
for the idea though (and for reminding me of the new way.  Old
habits die hard.)

-- steve

-----Original Message-----
From: Douglas Gilbert [mailto:dougg@torque.net]
[...]
Steve,
I suppose the lk 2.6 equivalent of:
# echo "0 7 0" > /sys/class/scsi_host/host<n>/scan
doesn't work either? [The reason I ask is that the
new technique works for finding "well known" lus.]

Doug Gilbert