Hi All,
I am working on a SCSI miniport driver and i found the following:
1> My Driver was not getting more than 2 commands at a time no matter how
and what i do with ScsiPortNotification.
2> At this time I was failing command MODE_SENSE with SRB_STATUS_ERROR.
Now while playing to get more number of commands i changed the following in
the driver:
1> Instead of failing MODE_SENSE with SRB_STATUS_ERROR i completed that
command with SRB_STATUS_INVALID_REQUEST.
After i did this change …wow my driver got flooded with commands.
Can any one explain why this behaviour is seen??
Any help is highly appriciated.
Thanks,
Ajitabh
> 1> My Driver was not getting more than 2 commands at a time no matter
1> how
and what i do with ScsiPortNotification.
2> At this time I was failing command MODE_SENSE with
SRB_STATUS_ERROR.
One possibility is there’s code in the scsi class drivers that turns off
pipelining of commands if some threshold of errors is detected. There is a
KB article about it, although I don’t offhand remember the number. The
article basically said disk performance degrades until a reboot if you get
some disk errors. There was also a patch that changed the behavior to start
pipelining again if some threshold worth of commands completed successfully.
Note this behavior is specific to specific versions of Windows.
Also note the scsi lun queue gets frozen after an error so other commands in
the queue don’t execute until you handle the error and unfreeze the queue,
so it seems quite possible that if you driver returns SRB_STATUS_ERRORS it
will not get fed a lot of commands.
Much of this behavior is handled by the SCSIPORT wrapper, so is not exactly
well documented. In cases like this, I’ve found it very helpful to trace
everything feeding into the top of the SCSIPORT wrapper, as the miniport
doesn’t see everything. A tool like BusHound helps.
I don’t know exactly what your driver is for or what your intention is.
But when you fail a SCSI command, make sure the information is
consistent. A very common problem we see (on RAID adapters for example)
is failing a command, setting the autosense flag and then not providing
any sense data. If you fail the MODE_SENSE command, set the scsi status,
and provide “actionable” sense data. For this example, if you don’t
support the particular page, set the ScsiStatus field to
SCSISTAT_CHECK_CONDITION and respond with sense data to indicate ILLEGAL
FIELD IN CDB (look at SPC-2 or SBC for the byte values). Likewise for
REQUEST SENSE if you didn’t set the autosense flag. By providing proper
information you will avoid unnecessary retries (default action if we
can’t interpret sense data) which will result in queue freezes and
possibly system hangs.
-----Original Message-----
From: Jan Bottorff [mailto:xxxxx@pmatrix.com]
Sent: Wednesday, August 11, 2004 9:52 PM
Subject: RE: Scsi Miniport …Explanation about an Observation.
1> My Driver was not getting more than 2 commands at a time no matter
1> how
and what i do with ScsiPortNotification.
2> At this time I was failing command MODE_SENSE with
SRB_STATUS_ERROR.
One possibility is there’s code in the scsi class drivers that turns off
pipelining of commands if some threshold of errors is detected. There is
a
KB article about it, although I don’t offhand remember the number. The
article basically said disk performance degrades until a reboot if you
get
some disk errors. There was also a patch that changed the behavior to
start
pipelining again if some threshold worth of commands completed
successfully.
Note this behavior is specific to specific versions of Windows.
Also note the scsi lun queue gets frozen after an error so other
commands in
the queue don’t execute until you handle the error and unfreeze the
queue,
so it seems quite possible that if you driver returns SRB_STATUS_ERRORS
it
will not get fed a lot of commands.
Much of this behavior is handled by the SCSIPORT wrapper, so is not
exactly
well documented. In cases like this, I’ve found it very helpful to trace
everything feeding into the top of the SCSIPORT wrapper, as the miniport
doesn’t see everything. A tool like BusHound helps.
I really appriciate the responses on this one. What does the tool that you
mentioned BusHound actually does and where can i get it??
-----Original Message-----
From: Jan Bottorff [mailto:xxxxx@pmatrix.com]
Sent: Thursday, August 12, 2004 12:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Scsi Miniport …Explanation about an Observation.
1> My Driver was not getting more than 2 commands at a time no matter
1> how
and what i do with ScsiPortNotification.
2> At this time I was failing command MODE_SENSE with
SRB_STATUS_ERROR.
One possibility is there’s code in the scsi class drivers that turns off
pipelining of commands if some threshold of errors is detected. There is a
KB article about it, although I don’t offhand remember the number. The
article basically said disk performance degrades until a reboot if you get
some disk errors. There was also a patch that changed the behavior to start
pipelining again if some threshold worth of commands completed successfully.
Note this behavior is specific to specific versions of Windows.
Also note the scsi lun queue gets frozen after an error so other commands in
the queue don’t execute until you handle the error and unfreeze the queue,
so it seems quite possible that if you driver returns SRB_STATUS_ERRORS it
will not get fed a lot of commands.
Much of this behavior is handled by the SCSIPORT wrapper, so is not exactly
well documented. In cases like this, I’ve found it very helpful to trace
everything feeding into the top of the SCSIPORT wrapper, as the miniport
doesn’t see everything. A tool like BusHound helps.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@lsil.com
To unsubscribe send a blank email to xxxxx@lists.osr.com