SCSI-2 SEND command

NTDEV
1

I recently read the SCSI-2 spec, and was very interested in the support it
provides for multiple host bus adapters to communicated with each other and
pass data over the bus, via the SEND command. I would like to be able to
use the SCSI bus as a kind of poor mans network interface, if for no other
reason than proof of concept. I’ve been reading over the DDK, and it seems
the only way to get an asynchronous event notification, such as the receipt
of a SEND command, is to send down an SRB with the command code to register
for AEN, and when the AEN comes in, the SRB is completed. This looks like
it would work, but the docs say this command code is reserved for use in
future versions of NT, and the sample miniport drivers that come in the DDK
do not implement it.

So, I was wondering, has anyone attempted anything like this before, and
does anyone know if there are any cards out there that do implement support
for AEN?

I tried connecting both of my SCSI cards to the same bus just to see what
would happen, and I was quite confused by the results. I expected each
card to scan the bus, and find the other card on it, only they did
not. Both cards saw all of the drives on the bus, but not each
other. Shouldn’t they see each other as targets on the bus?

–>Phillip Susi
xxxxx@iag.net

2

SCSI Controllers are called “Initiators”, although this is in itself
confusing because SCSI devices like disks in theory can be initiators (the
term comes from the fact that they “initiate” a SCSI command). You can have
any number of initiators on the same bus (up to SCSI limits) as long as each
initiator has it’s own unique id. The reason why most controllers are set
to ID7 is that this is the highest priority on the bus. Most SCSI chipsets
can be programmed to operate in initiator or target mode and can easily
switch back and forth. However, in the case of SCSI controllers especially,
they’ve never typically been used (and more importantly tested) in that
environment, so you are very likely to uncover bugs in the driver, firmware
or both. Even finding two controllers that behave properly on a bus with
two initiators can be a chore – this is the std environment mandated by
installing Windows2000 Advanced Server, and you’ll see that the HCL for SCSI
controllers used for controlling the Quorum/shared disks is very small.
I believe there have been network cards that attach to SCSI buses, but these
devices haven’t been at all popular.
What you’ll probably need to do is use SCSI controllers that you have the
miniport source for so you can make the necessary changes to allow them to
operate correctly in target mode. Unfortunately, there are very few SCSI
miniport sources on the DDK and most (all?) of them are for old ISA/EISA
cards.

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Phillip Susi [mailto:xxxxx@iag.net]
Sent: Wednesday, July 19, 2000 8:01 AM
To: NT Developers Interest List
Subject: [ntdev] SCSI-2 SEND command

I recently read the SCSI-2 spec, and was very interested in the support it
provides for multiple host bus adapters to communicated with each other and
pass data over the bus, via the SEND command. I would like to be able to
use the SCSI bus as a kind of poor mans network interface, if for no other
reason than proof of concept. I’ve been reading over the DDK, and it seems
the only way to get an asynchronous event notification, such as the receipt
of a SEND command, is to send down an SRB with the command code to register
for AEN, and when the AEN comes in, the SRB is completed. This looks like
it would work, but the docs say this command code is reserved for use in
future versions of NT, and the sample miniport drivers that come in the DDK
do not implement it.

So, I was wondering, has anyone attempted anything like this before, and
does anyone know if there are any cards out there that do implement support
for AEN?

I tried connecting both of my SCSI cards to the same bus just to see what
would happen, and I was quite confused by the results. I expected each
card to scan the bus, and find the other card on it, only they did
not. Both cards saw all of the drives on the bus, but not each
other. Shouldn’t they see each other as targets on the bus?

3

Paul is right. You’ll also have an interesting time with many
devices on a multi-initiator bus. Many allegedly SCSI devices
will simply not work in this environment. (Tapes and CDs in fact
frequently don’t even decode LUNs, let alone initiators.) You
also need to be aware that on such a bus there is a temptation for
each machine to access shared disks directly. Unless your OS is
prepared to coordinate its access to the devices, this can lead
to file structure corruption. This can work with a distributed
lock manager a la VMS, or with code to pretend that disks are
visible one side only but there has to be cooperation at some
level. Bus reset on the shared bus is interesting as well…

The scsi bus works nicely as a storage bus, but is far from
optimal for network traffic, where its heavier-weight setup
slows things.

-----Original Message-----
From: Paul Bunn [mailto:xxxxx@ultrabac.com]
Sent: Wednesday, July 19, 2000 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SCSI-2 SEND command

SCSI Controllers are called “Initiators”, although this is in itself
confusing because SCSI devices like disks in theory can be initiators (the
term comes from the fact that they “initiate” a SCSI command). You can have
any number of initiators on the same bus (up to SCSI limits) as long as each
initiator has it’s own unique id. The reason why most controllers are set
to ID7 is that this is the highest priority on the bus. Most SCSI chipsets
can be programmed to operate in initiator or target mode and can easily
switch back and forth. However, in the case of SCSI controllers especially,
they’ve never typically been used (and more importantly tested) in that
environment, so you are very likely to uncover bugs in the driver, firmware
or both. Even finding two controllers that behave properly on a bus with
two initiators can be a chore – this is the std environment mandated by
installing Windows2000 Advanced Server, and you’ll see that the HCL for SCSI
controllers used for controlling the Quorum/shared disks is very small.
I believe there have been network cards that attach to SCSI buses, but these
devices haven’t been at all popular.
What you’ll probably need to do is use SCSI controllers that you have the
miniport source for so you can make the necessary changes to allow them to
operate correctly in target mode. Unfortunately, there are very few SCSI
miniport sources on the DDK and most (all?) of them are for old ISA/EISA
cards.

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Phillip Susi [mailto:xxxxx@iag.net]
Sent: Wednesday, July 19, 2000 8:01 AM
To: NT Developers Interest List
Subject: [ntdev] SCSI-2 SEND command

I recently read the SCSI-2 spec, and was very interested in the support it
provides for multiple host bus adapters to communicated with each other and
pass data over the bus, via the SEND command. I would like to be able to
use the SCSI bus as a kind of poor mans network interface, if for no other
reason than proof of concept. I’ve been reading over the DDK, and it seems
the only way to get an asynchronous event notification, such as the receipt
of a SEND command, is to send down an SRB with the command code to register
for AEN, and when the AEN comes in, the SRB is completed. This looks like
it would work, but the docs say this command code is reserved for use in
future versions of NT, and the sample miniport drivers that come in the DDK
do not implement it.

So, I was wondering, has anyone attempted anything like this before, and
does anyone know if there are any cards out there that do implement support
for AEN?

I tried connecting both of my SCSI cards to the same bus just to see what
would happen, and I was quite confused by the results. I expected each
card to scan the bus, and find the other card on it, only they did
not. Both cards saw all of the drives on the bus, but not each
other. Shouldn’t they see each other as targets on the bus?

You are currently subscribed to ntdev as: xxxxx@FirstUSA.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

4

These are minor problems. The big problem is that NT has no concept
that it could be a target, and has no interfaces to support this. If the
miniport behaved as a target, there is still no mechanism to tell any upper layer
that some unsolicited data has arrived.

If you actually wanted to use SCSI as a link level protocol, you’d be better off
creating an NDIS miniport that serviced this “new” type of network controller,
but then it wouldn’t be a SCSI miniport, and you couldn’t initiate requests to other
devices. I’ve never figured out how to build a miniport that would be both SCSI and NDIS
at the same time.

-DH
----- Original Message -----
From: “Paul Bunn”
To: “NT Developers Interest List”
Sent: Wednesday, July 19, 2000 11:18 AM
Subject: [ntdev] RE: SCSI-2 SEND command

> SCSI Controllers are called “Initiators”, although this is in itself
> confusing because SCSI devices like disks in theory can be initiators (the
> term comes from the fact that they “initiate” a SCSI command). You can have
> any number of initiators on the same bus (up to SCSI limits) as long as each
> initiator has it’s own unique id. The reason why most controllers are set
> to ID7 is that this is the highest priority on the bus. Most SCSI chipsets
> can be programmed to operate in initiator or target mode and can easily
> switch back and forth. However, in the case of SCSI controllers especially,
> they’ve never typically been used (and more importantly tested) in that
> environment, so you are very likely to uncover bugs in the driver, firmware
> or both. Even finding two controllers that behave properly on a bus with
> two initiators can be a chore – this is the std environment mandated by
> installing Windows2000 Advanced Server, and you’ll see that the HCL for SCSI
> controllers used for controlling the Quorum/shared disks is very small.
> I believe there have been network cards that attach to SCSI buses, but these
> devices haven’t been at all popular.
> What you’ll probably need to do is use SCSI controllers that you have the
> miniport source for so you can make the necessary changes to allow them to
> operate correctly in target mode. Unfortunately, there are very few SCSI
> miniport sources on the DDK and most (all?) of them are for old ISA/EISA
> cards.
>
> Regards,
>
> Paul Bunn, UltraBac.com, 425-644-6000
> Microsoft MVP - WindowsNT/2000
> http://www.ultrabac.com
>
>
> -----Original Message-----
> From: Phillip Susi [mailto:xxxxx@iag.net]
> Sent: Wednesday, July 19, 2000 8:01 AM
> To: NT Developers Interest List
> Subject: [ntdev] SCSI-2 SEND command
>
>
> I recently read the SCSI-2 spec, and was very interested in the support it
> provides for multiple host bus adapters to communicated with each other and
> pass data over the bus, via the SEND command. I would like to be able to
> use the SCSI bus as a kind of poor mans network interface, if for no other
> reason than proof of concept. I’ve been reading over the DDK, and it seems
> the only way to get an asynchronous event notification, such as the receipt
> of a SEND command, is to send down an SRB with the command code to register
> for AEN, and when the AEN comes in, the SRB is completed. This looks like
> it would work, but the docs say this command code is reserved for use in
> future versions of NT, and the sample miniport drivers that come in the DDK
> do not implement it.
>
> So, I was wondering, has anyone attempted anything like this before, and
> does anyone know if there are any cards out there that do implement support
> for AEN?
>
> I tried connecting both of my SCSI cards to the same bus just to see what
> would happen, and I was quite confused by the results. I expected each
> card to scan the bus, and find the other card on it, only they did
> not. Both cards saw all of the drives on the bus, but not each
> other. Shouldn’t they see each other as targets on the bus?
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

5

At 11:46 AM 7/19/00 -0400, you wrote:

These are minor problems. The big problem is that NT has no concept
that it could be a target, and has no interfaces to support this. If the
miniport behaved as a target, there is still no mechanism to tell any
upper layer
that some unsolicited data has arrived.
NT does seem to have a concept to allow this in the form of an SRB that
registers to listen for an AEN from a given target, but the documentation
says that the command is reserved for use in future versions of NT, and the
sample drivers in the DDK do not support it. The question is are there
drivers out there for particular cards that do support it?

If you actually wanted to use SCSI as a link level protocol, you’d be
better off
creating an NDIS miniport that serviced this “new” type of network controller,
but then it wouldn’t be a SCSI miniport, and you couldn’t initiate
requests to other
devices. I’ve never figured out how to build a miniport that would be
both SCSI and NDIS
at the same time.

I was planning on writing an NDIS miniport that simply opens the scsi port
and sends down SRBs to communicate. This should work provided that the
scsi miniport driver implements the SRB command to receive AENs.

-DH
----- Original Message -----
From: “Paul Bunn”
>To: “NT Developers Interest List”
>Sent: Wednesday, July 19, 2000 11:18 AM
>Subject: [ntdev] RE: SCSI-2 SEND command
>
>
> > SCSI Controllers are called “Initiators”, although this is in itself
> > confusing because SCSI devices like disks in theory can be initiators (the
> > term comes from the fact that they “initiate” a SCSI command). You can
> have
> > any number of initiators on the same bus (up to SCSI limits) as long as
> each
> > initiator has it’s own unique id. The reason why most controllers are set
> > to ID7 is that this is the highest priority on the bus. Most SCSI chipsets
> > can be programmed to operate in initiator or target mode and can easily
> > switch back and forth. However, in the case of SCSI controllers
> especially,
> > they’ve never typically been used (and more importantly tested) in that
> > environment, so you are very likely to uncover bugs in the driver, firmware
> > or both. Even finding two controllers that behave properly on a bus with
> > two initiators can be a chore – this is the std environment mandated by
> > installing Windows2000 Advanced Server, and you’ll see that the HCL for
> SCSI
> > controllers used for controlling the Quorum/shared disks is very small.
> > I believe there have been network cards that attach to SCSI buses, but
> these
> > devices haven’t been at all popular.
> > What you’ll probably need to do is use SCSI controllers that you have the
> > miniport source for so you can make the necessary changes to allow them to
> > operate correctly in target mode. Unfortunately, there are very few SCSI
> > miniport sources on the DDK and most (all?) of them are for old ISA/EISA
> > cards.

Right… I tried plugging both of my scsi controllers, an integrated
adaptec AIC 7880 and an older PCI NCR/symbios logic board onto the same
bus. Both cards saw the 2 drives on the bus, but they did not see each
other. As I understand the SCSI-2 spec, the cards should see each other as
a controller on the bus with whatever TID they are configured for ( I set
the ID of my adaptec to 6 instead of 7 ). Maybe I’ll have to try using
some of those cards on the cluster services HCL.

>
> > Regards,
> >
> > Paul Bunn, UltraBac.com, 425-644-6000
> > Microsoft MVP - WindowsNT/2000
> > http://www.ultrabac.com
> >
> >

–>Phillip Susi
xxxxx@iag.net

6

No, that’s not the issue. The controllers do not respond to each other
because they are both in initiator mode – one of them needs to be
reprogrammed to operate in target mode. One possibility for this is to
obtain VirtualSCSI from fellow NTDev contributor Bill Casey, info at:
http://www.advstor.com/vscsi.html
The alternative would be to use hardware that you have the source for AND
(importantly) freely available documentation for the SCSI chipset used. The
NCR (now LSI, nee Symbios) 53c9x chipset is one such example of this. It
might also be possible to (given the availability of documentation) simply
adapt (or infer from this) the correct code for SCSI cards based on the
other LSI chips such as the C810 or C895. This route is not a trivial
exercise, and explains why VirtualSCSI only works with a set number of SCSI
interface cards. Essentially, you’ll be taking a miniport device driver and
converting it to an NDIS driver, a completely different animal.

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Phillip Susi [mailto:xxxxx@iag.net]
Sent: Wednesday, July 19, 2000 5:50 PM
To: NT Developers Interest List
Subject: [ntdev] RE: SCSI-2 SEND command

> controllers used for controlling the Quorum/shared disks is very small.
> I believe there have been network cards that attach to SCSI buses, but
these
> devices haven’t been at all popular.
> What you’ll probably need to do is use SCSI controllers that you have
the
> miniport source for so you can make the necessary changes to allow them
to
> operate correctly in target mode. Unfortunately, there are very few
SCSI
> miniport sources on the DDK and most (all?) of them are for old ISA/EISA
> cards.

Right… I tried plugging both of my scsi controllers, an integrated
adaptec AIC 7880 and an older PCI NCR/symbios logic board onto the same
bus. Both cards saw the 2 drives on the bus, but they did not see each
other. As I understand the SCSI-2 spec, the cards should see each other as
a controller on the bus with whatever TID they are configured for ( I set
the ID of my adaptec to 6 instead of 7 ). Maybe I’ll have to try using
some of those cards on the cluster services HCL.

7

> At 11:46 AM 7/19/00 -0400, you wrote:

>These are minor problems. The big problem is that NT has no concept
>that it could be a target, and has no interfaces to support this. If the
>miniport behaved as a target, there is still no mechanism to tell any
>upper layer
>that some unsolicited data has arrived.
NT does seem to have a concept to allow this in the form of an SRB that
registers to listen for an AEN from a given target, but the documentation
says that the command is reserved for use in future versions of NT, and the
sample drivers in the DDK do not support it. The question is are there
drivers out there for particular cards that do support it?

AEN is defined in the SCSI protocol, and it is a mechanism by which a
target (e.g., disk) can asynchronously notify an initiator of some event.
So NT has some unimplemented concept in initiator mode that it a target
is sending it
an event. This is completely unrelated to NT running as a target or
initiator/target. (Also, my belief is AEN is a legacy feature that most
new implementations drop. I don’t expect it will ever be supported in NT.)

-DH

8

What you describe below is the SCSI disconnect/reconnect protocol which is
what makes the SCSI protocol a multitasking bus. This is critical to the
performance of SCSI with many devices attached. When a target wishes to
reconnect back to the initiator (typically because a command has completed)
it will wait for bus free, and request to speak to the initiator during
arbitration. When it wins the arbitration, the SCSI chipset will generate
an interrupt which will be serviced by the miniport driver which will take
the necessary steps to complete the command. This will all stem ultimately
from an SRB/IRP that caused the command to be issued in the first place.
SCSI targets don’t just send unsolicited events/requests to initiators.
Interestingly though, it is possible for a SCSI target to enter intiator
mode and send a command to another target, without any host controller
involvement whatsoever. This means that disk on SCSI ID2 could read the
data directly off of SCSI ID3 if it felt like it!

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Dave Harvey [mailto:xxxxx@syssoftsol.com]
Sent: Wednesday, July 19, 2000 6:32 PM
To: NT Developers Interest List
Subject: [ntdev] RE: SCSI-2 SEND command

At 11:46 AM 7/19/00 -0400, you wrote:
>These are minor problems. The big problem is that NT has no concept
>that it could be a target, and has no interfaces to support this. If the
>miniport behaved as a target, there is still no mechanism to tell any
>upper layer
>that some unsolicited data has arrived.
NT does seem to have a concept to allow this in the form of an SRB that
registers to listen for an AEN from a given target, but the documentation
says that the command is reserved for use in future versions of NT, and
the
sample drivers in the DDK do not support it. The question is are there
drivers out there for particular cards that do support it?

AEN is defined in the SCSI protocol, and it is a mechanism by which a
target (e.g., disk) can asynchronously notify an initiator of some event.
So NT has some unimplemented concept in initiator mode that it a target
is sending it
an event. This is completely unrelated to NT running as a target or
initiator/target. (Also, my belief is AEN is a legacy feature that most
new implementations drop. I don’t expect it will ever be supported in NT.)

9

>

>If you actually wanted to use SCSI as a link level protocol, you’d be
>better off
>creating an NDIS miniport that serviced this “new” type of network controller,
>but then it wouldn’t be a SCSI miniport, and you couldn’t initiate
>requests to other
>devices. I’ve never figured out how to build a miniport that would be
>both SCSI and NDIS
>at the same time.

I was planning on writing an NDIS miniport that simply opens the scsi port
and sends down SRBs to communicate. This should work provided that the
scsi miniport driver implements the SRB command to receive AENs.

So lets say you send down some “special” SRB that requests incoming messages,
and is completed when those arrive. I guess that you could fake-out being a
target completely in the miniport. When the miniport receives a SEND request, and
it has a special SRB, it does a dataphase to transfer the data to the buffer. When that
completes, it sends status to the initiator and completes the SRB. So I guess this will
work for the SEND operation. The key is that the miniport is the target, and cannot
communicate with any other driver to do target functionality. It would get extremely
messy (including lots of deadlocks) if you received an operation in the miniport,
completed some SRB, then waited to send status to the initiator until some other
driver sent you an SRB.

You do have to implement all the receive NEXUS stuff, probably with tags. The miniport
has to advertise that it is both target & initiator, and it must support some basic operations
such as Inquiry. If you were serious about this, then there are issues about when you do
a bus scan from the NDIS driver.

Also, if the SCSI is going over Fibre Channel, then this picture is really backwards, because
Fibre Channel is a link level with SCSI built on top of it.

Anyway, it might work.

Good Luck,

-DH

10

----- Original Message -----
From: “Paul Bunn”
To: “NT Developers Interest List”
Sent: Wednesday, July 19, 2000 9:42 PM
Subject: [ntdev] RE: SCSI-2 SEND command

> What you describe below is the SCSI disconnect/reconnect protocol which is
I certainly wasn’t intending on talking about disconnect/reconnect. I’m trying to
talk about driver layering in NT, and where responsibility for target mode would
have to go.

Note that the “No-disconnect” protocol is typically only supported on Parallel SCSI.
On Fibre Channel, everything is implemented as disconnect/reconnect.

> what makes the SCSI protocol a multitasking bus. This is critical to the
> performance of SCSI with many devices attached. When a target wishes to
> reconnect back to the initiator (typically because a command has completed)
> it will wait for bus free, and request to speak to the initiator during
> arbitration. When it wins the arbitration, the SCSI chipset will generate
> an interrupt which will be serviced by the miniport driver which will take
> the necessary steps to complete the command. This will all stem ultimately
Only on simpler hardware. More advanced hardware will let you queue
data and status phases, so that the arb and transfer are a single operation to the driver.

> from an SRB/IRP that caused the command to be issued in the first place.
> SCSI targets don’t just send unsolicited events/requests to initiators.
But that is what AEN is: The target generates an operation on the bus
when there is no initiator command outstanding to the target. A target
need not be an initiator to do this.

> Interestingly though, it is possible for a SCSI target to enter intiator
> mode and send a command to another target, without any host controller
> involvement whatsoever. This means that disk on SCSI ID2 could read the
> data directly off of SCSI ID3 if it felt like it!
To be picky, it cannot. A device can be a target, and initiator, or an initiator/target.
A disk that reports itself as a target cannot initiate any requests. To rephrase:
“it is possible for a SCSI device that mostly acts as a target to enter intiator
mode and send a command to another target, without any host controller
involvement whatsoever.”
-DH

>
> Regards,
>
> Paul Bunn, UltraBac.com, 425-644-6000
> Microsoft MVP - WindowsNT/2000
> http://www.ultrabac.com
>
>
> -----Original Message-----
> From: Dave Harvey [mailto:xxxxx@syssoftsol.com]
> Sent: Wednesday, July 19, 2000 6:32 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: SCSI-2 SEND command
>
>
>
> > At 11:46 AM 7/19/00 -0400, you wrote:
> > >These are minor problems. The big problem is that NT has no concept
> > >that it could be a target, and has no interfaces to support this. If the
> > >miniport behaved as a target, there is still no mechanism to tell any
> > >upper layer
> > >that some unsolicited data has arrived.
> > NT does seem to have a concept to allow this in the form of an SRB that
> > registers to listen for an AEN from a given target, but the documentation
> > says that the command is reserved for use in future versions of NT, and
> the
> > sample drivers in the DDK do not support it. The question is are there
> > drivers out there for particular cards that do support it?
>
> AEN is defined in the SCSI protocol, and it is a mechanism by which a
> target (e.g., disk) can asynchronously notify an initiator of some event.
> So NT has some unimplemented concept in initiator mode that it a target
> is sending it
> an event. This is completely unrelated to NT running as a target or
> initiator/target. (Also, my belief is AEN is a legacy feature that most
> new implementations drop. I don’t expect it will ever be supported in NT.)
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

11

At 06:09 PM 7/19/00 -0700, Paul Bunn wrote:
>No, that’s not the issue. The controllers do not respond to each other
>because they are both in initiator mode – one of them needs to be
>reprogrammed to operate in target mode. One possibility for this is to

As far as I can tell from the scsi-2 spec, the only thing that ‘initiator’
and ‘target’ means to scsi is the initiator is the device that initiated a
command, and the target is the device to which the initiator is
talking. Any device can respond to commands from some other device acting
as an initator, or it can choose to be an initiator itself by initiating a
command to another device.

>obtain VirtualSCSI from fellow NTDev contributor Bill Casey, info at:
>http://www.advstor.com/vscsi.html
>The alternative would be to use hardware that you have the source for AND
>(importantly) freely available documentation for the SCSI chipset used. The
>NCR (now LSI, nee Symbios) 53c9x chipset is one such example of this. It
>might also be possible to (given the availability of documentation) simply
>adapt (or infer from this) the correct code for SCSI cards based on the
>other LSI chips such as the C810 or C895. This route is not a trivial
>exercise, and explains why VirtualSCSI only works with a set number of SCSI
>interface cards. Essentially, you’ll be taking a miniport device driver and
>converting it to an NDIS driver, a completely different animal.

I do not see why you would need to do this at all. Provided the existing
miniport driver implements the SRB command to receive an AEN ( which I’m
now betting those controllers on the clustering services HCL do ), you
could write an NDIS driver to open the scsi port, and send it this SRB in a
pass through ioctl.

At 09:31 PM 7/19/00 -0400, “Dave Harvey” wrote:

>AEN is defined in the SCSI protocol, and it is a mechanism by which a
>target (e.g., disk) can asynchronously notify an initiator of some event.
>So NT has some unimplemented concept in initiator mode that it a target
>is sending it
>an event. This is completely unrelated to NT running as a target or
>initiator/target. (Also, my belief is AEN is a legacy feature that most
>new implementations drop. I don’t expect it will ever be supported in NT.)

You seem to be suggesting that there is some other way to pass data between
controllers, other than a SEND type AEN, could you explain?

At 09:46 PM 7/19/00 -0400, “Dave Harvey” wrote:

>So lets say you send down some “special” SRB that requests incoming messages,
>and is completed when those arrive. I guess that you could fake-out being a
>target completely in the miniport. When the miniport receives a SEND
>request, and
>it has a special SRB, it does a dataphase to transfer the data to the
>buffer. When that
>completes, it sends status to the initiator and completes the SRB. So I
>guess this will
>work for the SEND operation. The key is that the miniport is the target,
>and cannot
>communicate with any other driver to do target functionality. It would
>get extremely
>messy (including lots of deadlocks) if you received an operation in the
>miniport,
>completed some SRB, then waited to send status to the initiator until some
>other
>driver sent you an SRB.

I don’t understand this waiting and deadlock you are describing. The
controller would receive the SEND, complete the SRB, and pass the data up,
and then go back to whatever it was doing, such as processing other SRBs.

>You do have to implement all the receive NEXUS stuff, probably with
>tags. The miniport
>has to advertise that it is both target & initiator, and it must support
>some basic operations
>such as Inquiry. If you were serious about this, then there are issues
>about when you do
>a bus scan from the NDIS driver.

Hrm… do HBAs typically give the driver that much control? From glancing
at the sample miniports in the DDK, it looked like they more or less passed
the SRB down to the board, and let it handle all of the bus
protocol. About the inquiry command, I am thinking that is why the 2 cards
did not see each other: they are not responding to the INQUIRY scsi command
which is used to scan the bus. Do you think this could be corrected in the
scsi miniport, or would it typically require a hardware/firmware fix on the
board?

At 10:41 PM 7/19/00 -0400, “Dave Harvey” wrote:

>I certainly wasn’t intending on talking about disconnect/reconnect. I’m
>trying to
>talk about driver layering in NT, and where responsibility for target mode
>would
>have to go.

By ‘target mode’ are you referring to something completely different than
what I am talking about? That being an AEN in the form of a SEND command.

> > Interestingly though, it is possible for a SCSI target to enter intiator
> > mode and send a command to another target, without any host controller
> > involvement whatsoever. This means that disk on SCSI ID2 could read the
> > data directly off of SCSI ID3 if it felt like it!
>To be picky, it cannot. A device can be a target, and initiator, or an
>initiator/target.
>A disk that reports itself as a target cannot initiate any requests. To
>rephrase:
>“it is possible for a SCSI device that mostly acts as a target to enter
>intiator
> mode and send a command to another target, without any host controller
> involvement whatsoever.”

From reading the SCSI-2 spec, any device can be a target simply by
responding to commands from other devices, or an initiator by simply
sending a command to another device. The only thing special about the HBA
is what type of device it identifies itself as in the INQUIRY command,
specifically, a processor, as opposed to say, a disk. Is this incorrect?

–>Phillip Susi
xxxxx@iag.net

12

Even if the controller knows how to be a target, remember that
if it has no response to INQUIRY, the bus scanning logic isn’t going
to find much to identify. INQUIRY contains the device type info
that one usually uses…

-----Original Message-----
From: Phillip Susi [mailto:xxxxx@iag.net]
Sent: Wednesday, July 19, 2000 8:50 PM
To: NT Developers Interest List
Subject: [ntdev] RE: SCSI-2 SEND command

At 11:46 AM 7/19/00 -0400, you wrote:

These are minor problems. The big problem is that NT has no concept
that it could be a target, and has no interfaces to support this. If the
miniport behaved as a target, there is still no mechanism to tell any
upper layer
that some unsolicited data has arrived.
NT does seem to have a concept to allow this in the form of an SRB that
registers to listen for an AEN from a given target, but the documentation
says that the command is reserved for use in future versions of NT, and the
sample drivers in the DDK do not support it. The question is are there
drivers out there for particular cards that do support it?

If you actually wanted to use SCSI as a link level protocol, you’d be
better off
creating an NDIS miniport that serviced this “new” type of network
controller,
but then it wouldn’t be a SCSI miniport, and you couldn’t initiate
requests to other
devices. I’ve never figured out how to build a miniport that would be
both SCSI and NDIS
at the same time.

I was planning on writing an NDIS miniport that simply opens the scsi port
and sends down SRBs to communicate. This should work provided that the
scsi miniport driver implements the SRB command to receive AENs.

-DH
----- Original Message -----
From: “Paul Bunn”
>To: “NT Developers Interest List”
>Sent: Wednesday, July 19, 2000 11:18 AM
>Subject: [ntdev] RE: SCSI-2 SEND command
>
>
> > SCSI Controllers are called “Initiators”, although this is in itself
> > confusing because SCSI devices like disks in theory can be initiators
(the
> > term comes from the fact that they “initiate” a SCSI command). You can
> have
> > any number of initiators on the same bus (up to SCSI limits) as long as
> each
> > initiator has it’s own unique id. The reason why most controllers are
set
> > to ID7 is that this is the highest priority on the bus. Most SCSI
chipsets
> > can be programmed to operate in initiator or target mode and can easily
> > switch back and forth. However, in the case of SCSI controllers
> especially,
> > they’ve never typically been used (and more importantly tested) in that
> > environment, so you are very likely to uncover bugs in the driver,
firmware
> > or both. Even finding two controllers that behave properly on a bus
with
> > two initiators can be a chore – this is the std environment mandated by
> > installing Windows2000 Advanced Server, and you’ll see that the HCL for
> SCSI
> > controllers used for controlling the Quorum/shared disks is very small.
> > I believe there have been network cards that attach to SCSI buses, but
> these
> > devices haven’t been at all popular.
> > What you’ll probably need to do is use SCSI controllers that you have
the
> > miniport source for so you can make the necessary changes to allow them
to
> > operate correctly in target mode. Unfortunately, there are very few
SCSI
> > miniport sources on the DDK and most (all?) of them are for old ISA/EISA
> > cards.

Right… I tried plugging both of my scsi controllers, an integrated
adaptec AIC 7880 and an older PCI NCR/symbios logic board onto the same
bus. Both cards saw the 2 drives on the bus, but they did not see each
other. As I understand the SCSI-2 spec, the cards should see each other as
a controller on the bus with whatever TID they are configured for ( I set
the ID of my adaptec to 6 instead of 7 ). Maybe I’ll have to try using
some of those cards on the cluster services HCL.

>
> > Regards,
> >
> > Paul Bunn, UltraBac.com, 425-644-6000
> > Microsoft MVP - WindowsNT/2000
> > http://www.ultrabac.com
> >
> >

–>Phillip Susi
xxxxx@iag.net

—
You are currently subscribed to ntdev as: xxxxx@FirstUSA.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

13

Paul:
Thanks for the plug. I’d be glad to answer any ‘SCSI Target on
NT/2000’ questions off line - xxxxx@virtualscsi.com.

Bill Casey

== SCSI Adapters & VirtualSCSI Target Mode Libs ==
Advanced Storage Concepts, Inc. www.virtualscsi.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Paul Bunn
Sent: Wednesday, July 19, 2000 8:10 PM
To: NT Developers Interest List
Subject: [ntdev] RE: SCSI-2 SEND command

No, that’s not the issue. The controllers do not respond to each other
because they are both in initiator mode – one of them needs to be
reprogrammed to operate in target mode. One possibility for this is to
obtain VirtualSCSI from fellow NTDev contributor Bill Casey, info at:
http://www.advstor.com/vscsi.html
The alternative would be to use hardware that you have the source for
AND
(importantly) freely available documentation for the SCSI chipset used.
The
NCR (now LSI, nee Symbios) 53c9x chipset is one such example of this.
It
might also be possible to (given the availability of documentation)
simply
adapt (or infer from this) the correct code for SCSI cards based on the
other LSI chips such as the C810 or C895. This route is not a trivial
exercise, and explains why VirtualSCSI only works with a set number of
SCSI
interface cards. Essentially, you’ll be taking a miniport device driver
and
converting it to an NDIS driver, a completely different animal.

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Phillip Susi [mailto:xxxxx@iag.net]
Sent: Wednesday, July 19, 2000 5:50 PM
To: NT Developers Interest List
Subject: [ntdev] RE: SCSI-2 SEND command

> controllers used for controlling the Quorum/shared disks is very
small.
> I believe there have been network cards that attach to SCSI buses,
but
these
> devices haven’t been at all popular.
> What you’ll probably need to do is use SCSI controllers that you
have
the
> miniport source for so you can make the necessary changes to allow
them
to
> operate correctly in target mode. Unfortunately, there are very few
SCSI
> miniport sources on the DDK and most (all?) of them are for old
ISA/EISA
> cards.

Right… I tried plugging both of my scsi controllers, an integrated
adaptec AIC 7880 and an older PCI NCR/symbios logic board onto the same
bus. Both cards saw the 2 drives on the bus, but they did not see each
other. As I understand the SCSI-2 spec, the cards should see each other
as
a controller on the bus with whatever TID they are configured for ( I
set
the ID of my adaptec to 6 instead of 7 ). Maybe I’ll have to try using
some of those cards on the cluster services HCL.

You are currently subscribed to ntdev as: xxxxx@advstor.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

14

----- Original Message -----
From: “Phillip Susi”
To: “NT Developers Interest List”
Sent: Thursday, July 20, 2000 1:33 AM
Subject: [ntdev] RE: SCSI-2 SEND command

> At 06:09 PM 7/19/00 -0700, Paul Bunn wrote:
> >No, that’s not the issue. The controllers do not respond to each other
> >because they are both in initiator mode – one of them needs to be
> >reprogrammed to operate in target mode. One possibility for this is to
>
> As far as I can tell from the scsi-2 spec, the only thing that ‘initiator’
> and ‘target’ means to scsi is the initiator is the device that initiated a
> command, and the target is the device to which the initiator is
> talking. Any device can respond to commands from some other device acting
> as an initator, or it can choose to be an initiator itself by initiating a
> command to another device.
Oops, I think I’m mixing FC in here. FC requires that a device describe
whether is it target or initiator in the initial handshake.

>
> >obtain VirtualSCSI from fellow NTDev contributor Bill Casey, info at:
> >http://www.advstor.com/vscsi.html
> >The alternative would be to use hardware that you have the source for AND
> >(importantly) freely available documentation for the SCSI chipset used. The
> >NCR (now LSI, nee Symbios) 53c9x chipset is one such example of this. It
> >might also be possible to (given the availability of documentation) simply
> >adapt (or infer from this) the correct code for SCSI cards based on the
> >other LSI chips such as the C810 or C895. This route is not a trivial
> >exercise, and explains why VirtualSCSI only works with a set number of SCSI
> >interface cards. Essentially, you’ll be taking a miniport device driver and
> >converting it to an NDIS driver, a completely different animal.
>
> I do not see why you would need to do this at all. Provided the existing
> miniport driver implements the SRB command to receive an AEN ( which I’m
> now betting those controllers on the clustering services HCL do ), you
> could write an NDIS driver to open the scsi port, and send it this SRB in a
> pass through ioctl.
>
> At 09:31 PM 7/19/00 -0400, “Dave Harvey” wrote:
>
> >AEN is defined in the SCSI protocol, and it is a mechanism by which a
> >target (e.g., disk) can asynchronously notify an initiator of some event.
> >So NT has some unimplemented concept in initiator mode that it a target
> >is sending it
> >an event. This is completely unrelated to NT running as a target or
> >initiator/target. (Also, my belief is AEN is a legacy feature that most
> >new implementations drop. I don’t expect it will ever be supported in NT.)
>
> You seem to be suggesting that there is some other way to pass data between
> controllers, other than a SEND type AEN, could you explain?
You can do a “SEND command - AEN data format”, but the only thing you are allowed
to send during the data phase is sense data, which does not allow you to pass data packets
of any reasonable size. If you use a “SEND command”, there is no relationship to AEN.

When the target miniport receives a SEND operation, some component on the target has
to request a data out phase, and then send status back to the initiator. The miniport could
be this component, but it would have to put the data somewhere.

>
> At 09:46 PM 7/19/00 -0400, “Dave Harvey” wrote:
>
>
> >So lets say you send down some “special” SRB that requests incoming messages,
> >and is completed when those arrive. I guess that you could fake-out being a
> >target completely in the miniport. When the miniport receives a SEND
> >request, and
> >it has a special SRB, it does a dataphase to transfer the data to the
> >buffer. When that
> >completes, it sends status to the initiator and completes the SRB. So I
> >guess this will
> >work for the SEND operation. The key is that the miniport is the target,
> >and cannot
> >communicate with any other driver to do target functionality. It would
> >get extremely
> >messy (including lots of deadlocks) if you received an operation in the
> >miniport,
> >completed some SRB, then waited to send status to the initiator until some
> >other
> >driver sent you an SRB.
>
> I don’t understand this waiting and deadlock you are describing. The
> controller would receive the SEND, complete the SRB, and pass the data up,
> and then go back to whatever it was doing, such as processing other SRBs.
If the SRB sent down a buffer, and the miniport did the data out (direction is
from the point of view of the initiator) phase into this buffer, then sent status
to the initiator, then completed the SRB, this would work. If instead, the
miniport immediately completed the SRB, and waited for another SRB to
initiate the data out phase, and yet another to send status, then there are probably
deadlocks relating to this same MP acting as an initiator to send in the other direction.

>
>
> >You do have to implement all the receive NEXUS stuff, probably with
> >tags. The miniport
> >has to advertise that it is both target & initiator, and it must support
> >some basic operations
> >such as Inquiry. If you were serious about this, then there are issues
> >about when you do
> >a bus scan from the NDIS driver.
>
> Hrm… do HBAs typically give the driver that much control? From glancing
> at the sample miniports in the DDK, it looked like they more or less passed
> the SRB down to the board, and let it handle all of the bus
> protocol. About the inquiry command, I am thinking that is why the 2 cards
> did not see each other: they are not responding to the INQUIRY scsi command
> which is used to scan the bus. Do you think this could be corrected in the
> scsi miniport, or would it typically require a hardware/firmware fix on the
> board?
If you are using a parallel SCSI controller that has scripts, you probably would
need to write some new scripts that would allow the HBA to act as a target, since
it only acts as an initiator on NT. This would be a lot of work.

>
> At 10:41 PM 7/19/00 -0400, “Dave Harvey” wrote:
>
> >I certainly wasn’t intending on talking about disconnect/reconnect. I’m
> >trying to
> >talk about driver layering in NT, and where responsibility for target mode
> >would
> >have to go.
>
> By ‘target mode’ are you referring to something completely different than
> what I am talking about? That being an AEN in the form of a SEND command.
>
> > > Interestingly though, it is possible for a SCSI target to enter intiator
> > > mode and send a command to another target, without any host controller
> > > involvement whatsoever. This means that disk on SCSI ID2 could read the
> > > data directly off of SCSI ID3 if it felt like it!
> >To be picky, it cannot. A device can be a target, and initiator, or an
> >initiator/target.
> >A disk that reports itself as a target cannot initiate any requests. To
> >rephrase:
> >“it is possible for a SCSI device that mostly acts as a target to enter
> >intiator
> > mode and send a command to another target, without any host controller
> > involvement whatsoever.”
>
> From reading the SCSI-2 spec, any device can be a target simply by
> responding to commands from other devices, or an initiator by simply
> sending a command to another device. The only thing special about the HBA
> is what type of device it identifies itself as in the INQUIRY command,
> specifically, a processor, as opposed to say, a disk. Is this incorrect?
I was mixing in Fibre Channel rules, as far as I can tell.
-DH

>
>
> –>Phillip Susi
> xxxxx@iag.net
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>