Is ASPI dead? I don't think so!
polfer at moxietech.com
Mon Feb 3 13:05:36 PST 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* polfer at moxietech.com (Daniel Polfer)
Some recent traffic from Pat Lavarre at IOMEGA expressed concerns with
the state of ASPI on Windows 95 and Windows NT.
I'd like to reassure everyone that ASPI is alive and well, and that
we're doing all we can to keep ASPI as clean a solution as it can be.
As a matter of fact, there was close to 5 hours of material delivered
at the recent Adaptec Developer's Conference which specifically
addresses many of Pat's concerns. I'll address those covered at the
conference first, and then I'll handle the rest In particular...
> ... can I transfer more than 64K of data?
On PIO adapters, maybe. The miniport must report a high enough
max-transfer to the port. If this is not done, ASPI restricts the
transfer (this means that ASPI is enforcing rules set by a lower level
driver, it is not introducing a problem).
Now, on DMA controllers you get into scatter/gather issues. Besides
max-transfer the miniport reports to IOS/SCSIPORT the number of
scatter/gather pages it can support. To make a long story short this
is historically 17. NT 4.0 can allow this to go higher, but 95
enforces it along with a 60KB per S/G element max, and a 512KB overall
max. The IOS enforces these restrictions and ASPI just plays along.
Can you beat this? Yes. Make sure your buffers are contiguous, or
play with the registry on NT 4.0. ASPI even has two
functions--GetASPI32Buffer/FreeASPI32Buffer-- which facilitate the
allocation and management of buffers which can be as large as 512KB
(the upper OS limit). If you want bigger on NT we covered several
strategies at the conference for getting by. The functions are
documented in a new spec handed out along with some sample code.
>... can I detect underruns?
> (i.e. transfers of less than what I expect)
> (by requesting byte count check)
> (i.e. srb=3D08h or srb=3D18h)
Yes. Use residual byte count. This has always been in ASPI for
Win95/WinNT. It was also in ASPI for DOS. It is documented in the
file RESIDUAL.TXT on any of the Adaptec online forums, and it is
documented in that new spec. Basically, or in 0x04 to the SRB_Flags
value and the buffer length will be adjusted to reflect the portion of
the buffer not transferred.
As an aside, You mention SRB =3D 0x08 or 0x18. This corresponds to a
data direction SRB_DIR_IN or SRB_DIR_IN|SRB_DIR_OUT. The SRB_DIR_IN
is fine, but a combination of IN and OUT should never be used in 95/NT
(even if you bypass ASPI and go straight to the port). The reason is
that some miniports cannot properly manage their data phases if they
don't know the true direction. SRB_DIR_SCSI (the combination of both
flags) should really be avoided if maximum cross-adapter compatibility
>... can I turn off auto-sense?
> (by setting sense length to zero)
No. This cannot be done reliably on NT because of timing issues.
What if you issue a command and it fails? Will you as a ring-3 app be
able to issue a request sense for that device before someone else
(even an OS component) does another command? What happens to your app
if you miss. This is closely related to the fact that 18 byte sense
requests are the practical limit on NT. We made the decision to limit
this ability on both platforms based on these issues.
>... can I make the Escape key cancel stuff?
> (by virtue of the driver
> returning srb status =3D 0
> when it encounters significant delay)
>... can I set my own timeouts?
> (same technique as for Escape)
You can't do an Escape cancel because there is no way for ASPI to
reliably tell the IOS/SCSIPORT to kill an I/O packet which has already
hit a host adapter. We're dealing with many host adapters, and a good
many won't allow this kind of operation. Based on this, the O/S
doesn't do it, and therefore we don't. I definitely agree with you
that this is tragic. I also think it is sad that I can't force either
a bus or a bus-device reset, but there isn't much I can do to fix the
problem because there is no O/S support.
Now, as far as timeouts are concerned... You can set
per-process/per-target timouts on ASPI SRBs. When the timeout goes
off the bus receives a *HARD* reset and the I/O (along with everybody
elses) gets aborted so that it can be retried. Check out the
SC_GETSET_TIMEOUT SRB which is documented in the spec handed out at
>... must I count adapters
> (and myself range-check ID's)
> (rather than just trying an ID)
Why don't you call GetASPI32SupportInfo (or its equivalent)? It
literally takes two more lines of code, and then you'll *KNOW* the
host adapter count. Aside from this, you can do what you indicated
ever since the first rev to ASPI. As a matter of fact, with the
latest version you can handle Plug'n'Play events from ASPI as well.
You can actually capture dynamic host adapter and device arrival and
departure, as well as force rescans of the SCSI bus under 95/NT to
pick up the late power-on of devices.
As I mentioned, all of the above issues were discussed at the Adaptec
Developer's Conference a few weeks ago. The code required to use
everything mentioned above has been available for awhile (download
ASPI32.EXE from any online service). Further, the ASPI layer itself
can be licensed for free from Adaptec for redistribution in your own
apps (complete with an installation utility).
Now, there were several other questions which I have not addressed,
which were not addressed at the conference:
>... can I attempt precisely 64K of data
> (without hanging the driver)
> (even if it can't transfer that much)
>... can I transfer 64K w/out seeing corrupt bytes?
>... can I detect overruns of small buffers?
> (e.g. a buffer of just 3 bytes)
I don't know the answer to these questions, because the answers depend
on the miniport that you are using. If the miniport has a problem
with this then there will be a problem with ASPI. ASPI builds a
request and then ships it down to the lower layer. There have been
bugs (all code has bugs), but none of them have been for issues like
ASPI cannot fix problems with the lower layers, and this includes any
installed filter drivers, the port, the miniport, or the adapter
itself. ASPI is a top level component, and it sometimes suffers for
it. Witness the original support for ATAPI. There were many reported
compatibility problems because of bad SCSI emulation on the part of
the various (there are many when you look at NT and 95) ATAPI drivers.
This combined with the confusion users were experiencing ("Why is my
IDE CD-ROM showing up as a SCSI device?") caused us to block ATAPI
devices from showing up in ASPI.=20
So, I'll take the credit for problems with my code, but not for every
single component below me as well! :-)
>... must I zero the offset of segment:offset ptrs?
I don't know of any issues regarding this. If you know of a problem
with ASPI for Win16 as implemented in Win95/WinNT then I would be
happy to hear about it so that I can fix the code. If this is a
problem from Win3.1x days then we'll have to narrow the problem down
to the specific ASPI software which is faulting (different manager for
I hope that completely clears up the issues which Pat mentioned. ASPI
is indeed alive and well, and there is still a lot of work being done
to improve it. Big buffers, Plug and Play, and error handling through
timeouts just go to prove it is still the easiest way to interface to
SCSI devices from Win32. If anyone has questions just let me know!
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
More information about the T10