SenseInfoBuffer is NULL

Hi,

doing some experiments with SCSI miniport driver. Notices some interesting
thing: when requests are initiated by class driver (SPTI requests from
UserMode app) or by Adaptec ASPI layer SRB that is passed to the SCSI
miniport driver has Srb->SenseInfoBuffer set to NULL. Other SRBs
(originated by class driver to read the data or to test unit ready) are
OK. So when the UserMode app is getting back the SCSI request that
completed with error it contains no SCSI sense data.

Is there any way to workaround this? Did anybody seen somethink like this?

Thanks,
Anton A. Kolomyeytsev

I don’t recall if there’s a way to easily pass in your own SenseInfoBuffer
with SPTI or not.
However, most apps that would use SPTI would tend to issue their own
REQUEST_SENSE I would think (if the buffer was not available)

Regards

Paul Bunn, UltraBac Software, 425-644-6000
Microsoft MVP - NT/Windows 2000/XP
http://www.ultrabac.com

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Sunday, March 02, 2003 4:07 AM
To: NT Developers Interest List
Subject: [ntdev] SenseInfoBuffer is NULL

Hi,

doing some experiments with SCSI miniport driver. Notices some interesting
thing: when requests are initiated by class driver (SPTI requests from
UserMode app) or by Adaptec ASPI layer SRB that is passed to the SCSI
miniport driver has Srb->SenseInfoBuffer set to NULL. Other SRBs
(originated by class driver to read the data or to test unit ready) are
OK. So when the UserMode app is getting back the SCSI request that
completed with error it contains no SCSI sense data.

Is there any way to workaround this? Did anybody seen somethink like this?

Thanks,
Anton A. Kolomyeytsev


You are currently subscribed to ntdev as: xxxxx@ultrabac.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Paul,

SRBs that are handling UserMode SCSI pass-thru request CDBs embedded do
always have SRB_FLAGS_DISABLE_AUTOSENSE flag raised (at least the ones
I’ve seen). Does not matter did you set the flag that your SCSI miniport
does automatic sense or not. So if SRB completes with CHECK CONDITION
status next command that is targeted to device (initiated by the class
driver) is SCSIOP_REQUEST_SENSE (0x03). In my particular case the problem
was that SCSI transport I use inside SCSI miniport did not allow me to
turn automatic sense off. So I just could not handle
SRB_FLAGS_DISABLE_AUTOSENSE enabled SRBs “AS IS”. The sequence of actions
was: CDB that competes with CHECK CONDITION -> REQUEST SENSE (my SCSI
transport executed automatically) -> REQUEST SENSE (issued by class driver
to determine sense for the CHECK CONDITION terminated CDB). It’s clear
that second REQUEST SENSE was always returning good status ))

What I did. When SRB with SRB_FLAGS_DISABLE_AUTOSENSE comes into my SCSI
miniport I do clear the flag SRB_FLAGS_DISABLE_AUTOSENSE and set flag
SRB_FLAGS_AUTOSENSE_VALID and copy sense data **ALWAYS** (SenseInfoBuffer
is always allocated and valid). The only thing I do not know is – it this
a hack or is this a solution )) Sounds like a hack but according to the
sources of the class drivers in DDK should work (and works!) w/o any
problems. Of course I can keep the SCSI sense in the device extension and
just copy it on the SCSIOP_REQUEST_SENSE coming to the device after
previous command failure. But I’d like not to intrude into CDB sequence
processing.

BTW, the SRB with the SenseInfoBuffer set to NULL was SCSIOP_REQUEST_SENSE
itself. As it keeps sense in DataBuffer looks like this situation is OK.

Regards,
Anton Kolomyeytsev

I don’t recall if there’s a way to easily pass in your own SenseInfoBuffer
with SPTI or not.
However, most apps that would use SPTI would tend to issue their own
REQUEST_SENSE I would think (if the buffer was not available)

Regards

Paul Bunn, UltraBac Software, 425-644-6000
Microsoft MVP - NT/Windows 2000/XP
http://www.ultrabac.com

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Sunday, March 02, 2003 4:07 AM
To: NT Developers Interest List
Subject: [ntdev] SenseInfoBuffer is NULL

Hi,

doing some experiments with SCSI miniport driver. Notices some interesting
thing: when requests are initiated by class driver (SPTI requests from
UserMode app) or by Adaptec ASPI layer SRB that is passed to the SCSI
miniport driver has Srb->SenseInfoBuffer set to NULL. Other SRBs
(originated by class driver to read the data or to test unit ready) are
OK. So when the UserMode app is getting back the SCSI request that
completed with error it contains no SCSI sense data.

Is there any way to workaround this? Did anybody seen somethink like this?

Thanks,
Anton A. Kolomyeytsev


You are currently subscribed to ntdev as: xxxxx@ultrabac.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

SPTI has a location for the sense info buffer. My first guess, however,
would be that the app isn’t sending a sense buffer down.

-p

-----Original Message-----
From: Paul Bunn [mailto:xxxxx@UltraBac.com]
Sent: Sunday, March 02, 2003 7:25 PM
To: NT Developers Interest List

I don’t recall if there’s a way to easily pass in your own
SenseInfoBuffer with SPTI or not.
However, most apps that would use SPTI would tend to issue their own
REQUEST_SENSE I would think (if the buffer was not available)

Regards

Paul Bunn, UltraBac Software, 425-644-6000 Microsoft MVP - NT/Windows
2000/XP http://www.ultrabac.com

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Sunday, March 02, 2003 4:07 AM
To: NT Developers Interest List
Subject: [ntdev] SenseInfoBuffer is NULL

Hi,

doing some experiments with SCSI miniport driver. Notices some
interesting
thing: when requests are initiated by class driver (SPTI requests from
UserMode app) or by Adaptec ASPI layer SRB that is passed to the SCSI
miniport driver has Srb->SenseInfoBuffer set to NULL. Other SRBs
(originated by class driver to read the data or to test unit ready) are
OK. So when the UserMode app is getting back the SCSI request that
completed with error it contains no SCSI sense data.

Is there any way to workaround this? Did anybody seen somethink like
this?

Thanks,
Anton A. Kolomyeytsev


You are currently subscribed to ntdev as: xxxxx@ultrabac.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Ah, that makes sense, especially combined with Peter’s information. I think
I’ve had to do something like you describe in the past with a class driver
when the sensebuffer wasn’t behaving as I originally suspected…

Regards,

Paul Bunn, UltraBac Software, 425-644-6000
Microsoft MVP - Windows NT/2000/XP
http://www.ultrabac.com

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Monday, March 03, 2003 2:58 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SenseInfoBuffer is NULL

Paul,

SRBs that are handling UserMode SCSI pass-thru request CDBs embedded do
always have SRB_FLAGS_DISABLE_AUTOSENSE flag raised (at least the ones
I’ve seen). Does not matter did you set the flag that your SCSI miniport
does automatic sense or not. So if SRB completes with CHECK CONDITION
status next command that is targeted to device (initiated by the class
driver) is SCSIOP_REQUEST_SENSE (0x03). In my particular case the problem
was that SCSI transport I use inside SCSI miniport did not allow me to
turn automatic sense off. So I just could not handle
SRB_FLAGS_DISABLE_AUTOSENSE enabled SRBs “AS IS”. The sequence of actions
was: CDB that competes with CHECK CONDITION -> REQUEST SENSE (my SCSI
transport executed automatically) -> REQUEST SENSE (issued by class driver
to determine sense for the CHECK CONDITION terminated CDB). It’s clear
that second REQUEST SENSE was always returning good status ))

What I did. When SRB with SRB_FLAGS_DISABLE_AUTOSENSE comes into my SCSI
miniport I do clear the flag SRB_FLAGS_DISABLE_AUTOSENSE and set flag
SRB_FLAGS_AUTOSENSE_VALID and copy sense data **ALWAYS** (SenseInfoBuffer
is always allocated and valid). The only thing I do not know is – it this
a hack or is this a solution )) Sounds like a hack but according to the
sources of the class drivers in DDK should work (and works!) w/o any
problems. Of course I can keep the SCSI sense in the device extension and
just copy it on the SCSIOP_REQUEST_SENSE coming to the device after
previous command failure. But I’d like not to intrude into CDB sequence
processing.

BTW, the SRB with the SenseInfoBuffer set to NULL was SCSIOP_REQUEST_SENSE
itself. As it keeps sense in DataBuffer looks like this situation is OK.

Regards,
Anton Kolomyeytsev

I don’t recall if there’s a way to easily pass in your own SenseInfoBuffer
with SPTI or not.
However, most apps that would use SPTI would tend to issue their own
REQUEST_SENSE I would think (if the buffer was not available)

Regards

Paul Bunn, UltraBac Software, 425-644-6000
Microsoft MVP - NT/Windows 2000/XP
http://www.ultrabac.com

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Sunday, March 02, 2003 4:07 AM
To: NT Developers Interest List
Subject: [ntdev] SenseInfoBuffer is NULL

Hi,

doing some experiments with SCSI miniport driver. Notices some interesting
thing: when requests are initiated by class driver (SPTI requests from
UserMode app) or by Adaptec ASPI layer SRB that is passed to the SCSI
miniport driver has Srb->SenseInfoBuffer set to NULL. Other SRBs
(originated by class driver to read the data or to test unit ready) are
OK. So when the UserMode app is getting back the SCSI request that
completed with error it contains no SCSI sense data.

Is there any way to workaround this? Did anybody seen somethink like this?

Thanks,
Anton A. Kolomyeytsev


You are currently subscribed to ntdev as: xxxxx@ultrabac.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@ultrabac.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

This is a “hack”. Of particular concern to me is your statement that
“SenseInfoBuffer is always allocated and valid”. Just because you’ve
seen this in the past doesn’t mean it will always be allocated and valid
in the future.

-p

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Monday, March 03, 2003 2:58 AM
To: NT Developers Interest List

Paul,

SRBs that are handling UserMode SCSI pass-thru request CDBs embedded do
always have SRB_FLAGS_DISABLE_AUTOSENSE flag raised (at least the ones
I’ve seen). Does not matter did you set the flag that your SCSI miniport
does automatic sense or not. So if SRB completes with CHECK CONDITION
status next command that is targeted to device (initiated by the class
driver) is SCSIOP_REQUEST_SENSE (0x03). In my particular case the
problem was that SCSI transport I use inside SCSI miniport did not allow
me to turn automatic sense off. So I just could not handle
SRB_FLAGS_DISABLE_AUTOSENSE enabled SRBs “AS IS”. The sequence of
actions
was: CDB that competes with CHECK CONDITION -> REQUEST SENSE (my SCSI
transport executed automatically) -> REQUEST SENSE (issued by class
driver to determine sense for the CHECK CONDITION terminated CDB). It’s
clear that second REQUEST SENSE was always returning good status ))

What I did. When SRB with SRB_FLAGS_DISABLE_AUTOSENSE comes into my SCSI
miniport I do clear the flag SRB_FLAGS_DISABLE_AUTOSENSE and set flag
SRB_FLAGS_AUTOSENSE_VALID and copy sense data **ALWAYS**
(SenseInfoBuffer is always allocated and valid). The only thing I do not
know is – it this a hack or is this a solution )) Sounds like a hack
but according to the sources of the class drivers in DDK should work
(and works!) w/o any problems. Of course I can keep the SCSI sense in
the device extension and just copy it on the SCSIOP_REQUEST_SENSE coming
to the device after previous command failure. But I’d like not to
intrude into CDB sequence processing.

BTW, the SRB with the SenseInfoBuffer set to NULL was
SCSIOP_REQUEST_SENSE itself. As it keeps sense in DataBuffer looks like
this situation is OK.

Regards,
Anton Kolomyeytsev

I don’t recall if there’s a way to easily pass in your own
SenseInfoBuffer with SPTI or not.
However, most apps that would use SPTI would tend to issue their own
REQUEST_SENSE I would think (if the buffer was not available)

Regards

Paul Bunn, UltraBac Software, 425-644-6000 Microsoft MVP - NT/Windows
2000/XP http://www.ultrabac.com

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Sunday, March 02, 2003 4:07 AM
To: NT Developers Interest List
Subject: [ntdev] SenseInfoBuffer is NULL

Hi,

doing some experiments with SCSI miniport driver. Notices some
interesting
thing: when requests are initiated by class driver (SPTI requests from

UserMode app) or by Adaptec ASPI layer SRB that is passed to the SCSI
miniport driver has Srb->SenseInfoBuffer set to NULL. Other SRBs
(originated by class driver to read the data or to test unit ready)
are OK. So when the UserMode app is getting back the SCSI request that

completed with error it contains no SCSI sense data.

Is there any way to workaround this? Did anybody seen somethink like
this?

Thanks,
Anton A. Kolomyeytsev


You are currently subscribed to ntdev as: xxxxx@ultrabac.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Peter,

no, this is not my statement! I always check is SenseInfoBuffer valid
(non-NULL and contains valid pointer to non-paged SenseInfoBufferLength
bytes memory region). If yes I copy sense to it, if no just set correct
flags (SRB_STATUS_AUTOSENSE_VALID cleared) in SRB.

OK, if you’re confirming that this technique is nothing more then a hack
I’ll turn to keeping sense info inside my SCSI miniport until somebody
will not issue SRB with SCSIOP_REAQUEST_SENSE to it.

Thanks for help!

Anton Kolomyeytsev

P.S. It looks like there are some of your comments inside classpnp, right?
))

This is a “hack”. Of particular concern to me is your statement that
“SenseInfoBuffer is always allocated and valid”. Just because you’ve
seen this in the past doesn’t mean it will always be allocated and valid
in the future.

-p
=20
-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]=20
Sent: Monday, March 03, 2003 2:58 AM
To: NT Developers Interest List

Paul,

SRBs that are handling UserMode SCSI pass-thru request CDBs embedded do
always have SRB_FLAGS_DISABLE_AUTOSENSE flag raised (at least the ones
I’ve seen). Does not matter did you set the flag that your SCSI miniport
does automatic sense or not. So if SRB completes with CHECK CONDITION
status next command that is targeted to device (initiated by the class
driver) is SCSIOP_REQUEST_SENSE (0x03). In my particular case the
problem was that SCSI transport I use inside SCSI miniport did not allow
me to turn automatic sense off. So I just could not handle
SRB_FLAGS_DISABLE_AUTOSENSE enabled SRBs “AS IS”. The sequence of
actions
was: CDB that competes with CHECK CONDITION -> REQUEST SENSE (my SCSI
transport executed automatically) -> REQUEST SENSE (issued by class
driver to determine sense for the CHECK CONDITION terminated CDB). It’s
clear that second REQUEST SENSE was always returning good status ))

What I did. When SRB with SRB_FLAGS_DISABLE_AUTOSENSE comes into my SCSI
miniport I do clear the flag SRB_FLAGS_DISABLE_AUTOSENSE and set flag
SRB_FLAGS_AUTOSENSE_VALID and copy sense data **ALWAYS**
(SenseInfoBuffer is always allocated and valid). The only thing I do not
know is – it this a hack or is this a solution )) Sounds like a hack
but according to the sources of the class drivers in DDK should work
(and works!) w/o any problems. Of course I can keep the SCSI sense in
the device extension and just copy it on the SCSIOP_REQUEST_SENSE coming
to the device after previous command failure. But I’d like not to
intrude into CDB sequence processing.

BTW, the SRB with the SenseInfoBuffer set to NULL was
SCSIOP_REQUEST_SENSE itself. As it keeps sense in DataBuffer looks like
this situation is OK.

Regards,
Anton Kolomyeytsev

> I don’t recall if there’s a way to easily pass in your own=20
> SenseInfoBuffer with SPTI or not.
> However, most apps that would use SPTI would tend to issue their own=20
> REQUEST_SENSE I would think (if the buffer was not available)
>=20
> Regards
>=20
> Paul Bunn, UltraBac Software, 425-644-6000 Microsoft MVP - NT/Windows=20
> 2000/XP http://www.ultrabac.com
>=20
>=20
>=20
> -----Original Message-----
> From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
> Sent: Sunday, March 02, 2003 4:07 AM
> To: NT Developers Interest List
> Subject: [ntdev] SenseInfoBuffer is NULL
>=20
>=20
> Hi,
>=20
> doing some experiments with SCSI miniport driver. Notices some=20
> interesting
> thing: when requests are initiated by class driver (SPTI requests from

> UserMode app) or by Adaptec ASPI layer SRB that is passed to the SCSI=20
> miniport driver has Srb->SenseInfoBuffer set to NULL. Other SRBs=20
> (originated by class driver to read the data or to test unit ready)=20
> are OK. So when the UserMode app is getting back the SCSI request that

> completed with error it contains no SCSI sense data.
>=20
> Is there any way to workaround this? Did anybody seen somethink like
this?
>=20
> Thanks,
> Anton A. Kolomyeytsev
>=20
> —
> You are currently subscribed to ntdev as: xxxxx@ultrabac.com To=20
> unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Okay. I see terms like “always valid” and get scared. I’m not sure how
you’re checking to see if the pointer is valid though - existance may
not be enough. The safest thing is to try and honor the
[yes|no]-autosense flag.

Personally I’d just have a buffer in my logical unit extension to use
for the sense data iff none is provided by the class driver. When a
request sense comes down you’d need to then get the data from your
device extension. Saddly this requires that you set MapBuffers.

-p

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Monday, March 03, 2003 1:15 PM
To: NT Developers Interest List

Peter,

no, this is not my statement! I always check is SenseInfoBuffer valid
(non-NULL and contains valid pointer to non-paged SenseInfoBufferLength
bytes memory region). If yes I copy sense to it, if no just set correct
flags (SRB_STATUS_AUTOSENSE_VALID cleared) in SRB.

OK, if you’re confirming that this technique is nothing more then a hack
I’ll turn to keeping sense info inside my SCSI miniport until somebody
will not issue SRB with SCSIOP_REAQUEST_SENSE to it.

Thanks for help!

Anton Kolomyeytsev

P.S. It looks like there are some of your comments inside classpnp,
right?
))

This is a “hack”. Of particular concern to me is your statement that
“SenseInfoBuffer is always allocated and valid”. Just because you’ve
seen this in the past doesn’t mean it will always be allocated and
valid in the future.

-p
=20
-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]=20
Sent: Monday, March 03, 2003 2:58 AM
To: NT Developers Interest List

Paul,

SRBs that are handling UserMode SCSI pass-thru request CDBs embedded
do always have SRB_FLAGS_DISABLE_AUTOSENSE flag raised (at least the
ones I’ve seen). Does not matter did you set the flag that your SCSI
miniport does automatic sense or not. So if SRB completes with CHECK
CONDITION status next command that is targeted to device (initiated by

the class
driver) is SCSIOP_REQUEST_SENSE (0x03). In my particular case the
problem was that SCSI transport I use inside SCSI miniport did not
allow me to turn automatic sense off. So I just could not handle
SRB_FLAGS_DISABLE_AUTOSENSE enabled SRBs “AS IS”. The sequence of
actions
was: CDB that competes with CHECK CONDITION -> REQUEST SENSE (my SCSI
transport executed automatically) -> REQUEST SENSE (issued by class
driver to determine sense for the CHECK CONDITION terminated CDB).
It’s clear that second REQUEST SENSE was always returning good status
))

What I did. When SRB with SRB_FLAGS_DISABLE_AUTOSENSE comes into my
SCSI miniport I do clear the flag SRB_FLAGS_DISABLE_AUTOSENSE and set
flag SRB_FLAGS_AUTOSENSE_VALID and copy sense data **ALWAYS**
(SenseInfoBuffer is always allocated and valid). The only thing I do
not know is – it this a hack or is this a solution )) Sounds like a
hack but according to the sources of the class drivers in DDK should
work (and works!) w/o any problems. Of course I can keep the SCSI
sense in the device extension and just copy it on the
SCSIOP_REQUEST_SENSE coming to the device after previous command
failure. But I’d like not to intrude into CDB sequence processing.

BTW, the SRB with the SenseInfoBuffer set to NULL was
SCSIOP_REQUEST_SENSE itself. As it keeps sense in DataBuffer looks
like this situation is OK.

Regards,
Anton Kolomyeytsev

> I don’t recall if there’s a way to easily pass in your own=20
>SenseInfoBuffer with SPTI or not.
> However, most apps that would use SPTI would tend to issue their
>own=20 REQUEST_SENSE I would think (if the buffer was not available)

>=20 Regards =20 Paul Bunn, UltraBac Software, 425-644-6000
>Microsoft MVP - NT/Windows=20 2000/XP http://www.ultrabac.com =20
>=20 =20 -----Original Message-----
> From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
> Sent: Sunday, March 02, 2003 4:07 AM
> To: NT Developers Interest List
> Subject: [ntdev] SenseInfoBuffer is NULL =20 =20 Hi, =20 doing
>some experiments with SCSI miniport driver. Notices some=20
>interesting
> thing: when requests are initiated by class driver (SPTI requests
>from

> UserMode app) or by Adaptec ASPI layer SRB that is passed to the
> SCSI=20 miniport driver has Srb->SenseInfoBuffer set to NULL. Other
> SRBs=20 (originated by class driver to read the data or to test unit

> ready)=20 are OK. So when the UserMode app is getting back the SCSI
> request that

> completed with error it contains no SCSI sense data.
>=20
> Is there any way to workaround this? Did anybody seen somethink like
this?
>=20
> Thanks,
> Anton A. Kolomyeytsev
>=20
> —
> You are currently subscribed to ntdev as: xxxxx@ultrabac.com To=20
>unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

And then there are SCSI ACA rules to folllow too on this I guess.

-V

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Monday, March 03, 2003 2:09 PM
Subject: [ntdev] RE: SenseInfoBuffer is NULL

Okay. I see terms like “always valid” and get scared. I’m not sure how
you’re checking to see if the pointer is valid though - existance may
not be enough. The safest thing is to try and honor the
[yes|no]-autosense flag.

Personally I’d just have a buffer in my logical unit extension to use
for the sense data iff none is provided by the class driver. When a
request sense comes down you’d need to then get the data from your
device extension. Saddly this requires that you set MapBuffers.

-p

-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Monday, March 03, 2003 1:15 PM
To: NT Developers Interest List

Peter,

no, this is not my statement! I always check is SenseInfoBuffer valid
(non-NULL and contains valid pointer to non-paged SenseInfoBufferLength
bytes memory region). If yes I copy sense to it, if no just set correct
flags (SRB_STATUS_AUTOSENSE_VALID cleared) in SRB.

OK, if you’re confirming that this technique is nothing more then a hack
I’ll turn to keeping sense info inside my SCSI miniport until somebody
will not issue SRB with SCSIOP_REAQUEST_SENSE to it.

Thanks for help!

Anton Kolomyeytsev

P.S. It looks like there are some of your comments inside classpnp,
right?
))

> This is a “hack”. Of particular concern to me is your statement that
> “SenseInfoBuffer is always allocated and valid”. Just because you’ve
> seen this in the past doesn’t mean it will always be allocated and
> valid in the future.
>
> -p
> =20
> -----Original Message-----
> From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]=20
> Sent: Monday, March 03, 2003 2:58 AM
> To: NT Developers Interest List
>
> Paul,
>
> SRBs that are handling UserMode SCSI pass-thru request CDBs embedded
> do always have SRB_FLAGS_DISABLE_AUTOSENSE flag raised (at least the
> ones I’ve seen). Does not matter did you set the flag that your SCSI
> miniport does automatic sense or not. So if SRB completes with CHECK
> CONDITION status next command that is targeted to device (initiated by

> the class
> driver) is SCSIOP_REQUEST_SENSE (0x03). In my particular case the
> problem was that SCSI transport I use inside SCSI miniport did not
> allow me to turn automatic sense off. So I just could not handle
> SRB_FLAGS_DISABLE_AUTOSENSE enabled SRBs “AS IS”. The sequence of
> actions
> was: CDB that competes with CHECK CONDITION -> REQUEST SENSE (my SCSI
> transport executed automatically) -> REQUEST SENSE (issued by class
> driver to determine sense for the CHECK CONDITION terminated CDB).
> It’s clear that second REQUEST SENSE was always returning good status
> ))
>
> What I did. When SRB with SRB_FLAGS_DISABLE_AUTOSENSE comes into my
> SCSI miniport I do clear the flag SRB_FLAGS_DISABLE_AUTOSENSE and set
> flag SRB_FLAGS_AUTOSENSE_VALID and copy sense data ALWAYS
> (SenseInfoBuffer is always allocated and valid). The only thing I do
> not know is – it this a hack or is this a solution )) Sounds like a
> hack but according to the sources of the class drivers in DDK should
> work (and works!) w/o any problems. Of course I can keep the SCSI
> sense in the device extension and just copy it on the
> SCSIOP_REQUEST_SENSE coming to the device after previous command
> failure. But I’d like not to intrude into CDB sequence processing.
>
> BTW, the SRB with the SenseInfoBuffer set to NULL was
> SCSIOP_REQUEST_SENSE itself. As it keeps sense in DataBuffer looks
> like this situation is OK.
>
> Regards,
> Anton Kolomyeytsev
>
> > I don’t recall if there’s a way to easily pass in your own=20
> >SenseInfoBuffer with SPTI or not.
> > However, most apps that would use SPTI would tend to issue their
> >own=20 REQUEST_SENSE I would think (if the buffer was not available)

> >=20 Regards =20 Paul Bunn, UltraBac Software, 425-644-6000
> >Microsoft MVP - NT/Windows=20 2000/XP http://www.ultrabac.com =20
> >=20 =20 -----Original Message-----
> > From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
> > Sent: Sunday, March 02, 2003 4:07 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] SenseInfoBuffer is NULL =20 =20 Hi, =20 doing
> >some experiments with SCSI miniport driver. Notices some=20
> >interesting
> > thing: when requests are initiated by class driver (SPTI requests
> >from
>
> > UserMode app) or by Adaptec ASPI layer SRB that is passed to the
> > SCSI=20 miniport driver has Srb->SenseInfoBuffer set to NULL. Other
> > SRBs=20 (originated by class driver to read the data or to test unit

> > ready)=20 are OK. So when the UserMode app is getting back the SCSI
> > request that
>
> > completed with error it contains no SCSI sense data.
> >=20
> > Is there any way to workaround this? Did anybody seen somethink like
> this?
> >=20
> > Thanks,
> > Anton A. Kolomyeytsev
> >=20
> > —
> > You are currently subscribed to ntdev as: xxxxx@ultrabac.com To=20
> >unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

>for the sense data iff none is provided by the class driver. When a

request sense comes down you’d need to then get the data from your
device extension. Saddly this requires that you set MapBuffers.

This is a cite from “Physical Address Extension” DDK documentation
chapter:

“Miniports must not attempt to access data buffers using virtual
addresses unless they have set the MapBuffers bit in the
PORT_CONFIGURATION_INFORMATION structure. The exceptions to this rule
are INQUIRY and REQUEST_SENSE operations that will always have a valid
virtual address”

This seems to be a claim that REQUEST SENSE always has valid
Srb->DataBuffer. Is the documentation wrong?

Max

No - the documentation is correct.

In the days of yore this was not really a guarantee - rather INQUIRY and
REQUEST_SENSE were almost always sent by a kernel component which
happened to be using a valid system address for the data buffer (since
that component, scsiport, disk, whatever, wanted to see the data in the
buffer). However the pass-through path did not have such a guarantee
and pass-through INQUIRY or REQUEST_SENSE would get into the miniport
without being mapped.

We added a check (for XP I believe) on the op-code to see if it was one
which “needed mapped” and would force a mapping of the data buffer
regardless of the value of MapBuffers in this case. I’d forgotten doing
this so was describing the old behavior.

-p

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, March 04, 2003 2:53 PM
To: NT Developers Interest List

for the sense data iff none is provided by the class driver. When a
request sense comes down you’d need to then get the data from your
device extension. Saddly this requires that you set MapBuffers.

This is a cite from “Physical Address Extension” DDK documentation
chapter:

“Miniports must not attempt to access data buffers using virtual
addresses unless they have set the MapBuffers bit in the
PORT_CONFIGURATION_INFORMATION structure. The exceptions to this rule
are INQUIRY and REQUEST_SENSE operations that will always have a valid
virtual address”

This seems to be a claim that REQUEST SENSE always has valid
Srb->DataBuffer. Is the documentation wrong?

Max


You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

RE