DataTransferLength in DDK SPTI sample

NTDEV
1

Hi,

I’m playing with the SPTI sample in the Windows 2003 DDK.

I wonder why in the calls for IOCTL_SCSI_PASS_THROUGH,
sptwb.spt.DataTransferLength is always set to 192 instead of
SPTWB_DATA_LENGTH which is the actual size of ucDataBuf defined in
spti.h. Is this some kind of safety precaution?

Also, in the SCSIOP_TEST_UNIT_READY test near line 237 in spti.c,
shouldn’t the device fail the request because, well, both
DataTransferLength and DataBufferOffset are set to zero? I tested this
in XP SP1 on systems with Intel 440BX integrated ATA (ATAPI.SYS) and
Promise FastTrack 133 (FASTTRAK.SYS) controller and in both cases the
call succeeded and returned data - obviously by simply writing at the
start of the SCSI_PASS_THROUGH_WITH_BUFFERS buffer. Is that expected
behavior?

Oh, and I managed to BSOD the Promise system by providing a valid
DataBufferOffset but setting DataTransferLength to zero
(IRQL_NOT_LESS_OR_EQUAL in fasttrak.sys). Grr, this driver is WHQL’d!

Ralf.

2

Look at the htm file in the 2003 Server DDK under ‘Initializing the
structures’. I guess the 192 is for four devices on the SCSI bus. It
appears to be a guess that might not work if more devices are attached.

“Ralf Buschmann” wrote in message news:xxxxx@ntdev…
>
> Hi,
>
> I’m playing with the SPTI sample in the Windows 2003 DDK.
>
> I wonder why in the calls for IOCTL_SCSI_PASS_THROUGH,
> sptwb.spt.DataTransferLength is always set to 192 instead of
> SPTWB_DATA_LENGTH which is the actual size of ucDataBuf defined in
> spti.h. Is this some kind of safety precaution?
>
> Also, in the SCSIOP_TEST_UNIT_READY test near line 237 in spti.c,
> shouldn’t the device fail the request because, well, both
> DataTransferLength and DataBufferOffset are set to zero? I tested this
> in XP SP1 on systems with Intel 440BX integrated ATA (ATAPI.SYS) and
> Promise FastTrack 133 (FASTTRAK.SYS) controller and in both cases the
> call succeeded and returned data - obviously by simply writing at the
> start of the SCSI_PASS_THROUGH_WITH_BUFFERS buffer. Is that expected
> behavior?
>
> Oh, and I managed to BSOD the Promise system by providing a valid
> DataBufferOffset but setting DataTransferLength to zero
> (IRQL_NOT_LESS_OR_EQUAL in fasttrak.sys). Grr, this driver is WHQL’d!
>
> Ralf.
> –
>
>
>