could your system thread do asynchronous I/O to talk to the remote server? Then you’d have some token (IRP, something else) that you could try to cancel when a bus reset occurs.
-p
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of identifier scorpio
Sent: Monday, June 06, 2005 10:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ?ظ??? Re: [ntdev] about BUS-RESET of SCSI miniport
as to my miniport driver, in HwScsiStartIo, i insert the incomming SRBs into a request list,
and i create a system thread to fetch SRBs (1 SRB each time) from the request list
and redirect the disk I/O request to remote server. before the request is
satisfied, the system thread keeps waiting for the response. (synchronized I/O)
after the system thread is awaken by a disk I/O response, it insert the currently processed SRB
into a completion list. And there is a soft interrupt handler HwScsiTimer keeping
removing the SRBs from the completion list and complete them.
in my circumstance, when bus reset occurs, the SRB that timed out causing the
bus reset is hold by the system thread, and the thread is being blocked by
WaitForXXX since the disk I/O response has not been received yet. so, the thread
can’t detect bus reset until WaitForXXX timeout.
well, below is my plan of HwScsiBusReset implementation:
- create a boolean flag named ‘BusReseted’ and initialized with false
- in HwScsiBusReset, do nothing but set ‘BusReseted’ to true.
- in system thread, when it is awaken from WaitForXXX with return value of STATUS_TIMEOUT,
it test whether ‘BusReseted’ is true. if true, it set currently processed SRB’s SrbStatus to SRB_STATUS_TIMEOUT and insert it into
completion list, and then set all other outstanding SRBs’ SrbStatus to SRB_STATUS_BUS_RESET
and insert them into completion list too. - the HwScsiTimer remove SRBs from completion list and complete them.
- the thread then monitor the request list to wait for SCSIport re-sending those abnormally
completed SRBs again.
before i code blindly, i hope some comment from you.
by the way, does SCSIport have any time limit on bus rest processing? and if have, how long?
because bus reset may occur just after the system thread calls WaitForXXX, thus there may be
a long time before the thread detects the bus reset event (till after the thread awake from
WaitForXxx). so, if the time limit exits, the long period in waiting may result another timeout
(bus reset processing timeout). that’s miserable.
xxxxx@attotech.com д???
Well, from my looking at the class driver for just a few minutes, it appears that the requests will be resent up to the max retry count. What that retry count is I don’t know, but I think it might be something like 5; I think it depends on who sent the request to the class driver.
In my experience, I have seen commands retried with this status.
Note that you have to be concerned probably about two statuses. I think that the command that timed out causing the bus reset will probably end up getting a status of SRB_STATUS_TIMEOUT, and the other commands that were in process at the time will get status SRB_STATUS_BUS_RESET.
Some of this is speculation on my part.
Jerry.
xxxxx@lists.osr.com wrote on 06/06/2005 02:12:03 AM:
I wanna known that if i implement HwScsiResetBus and successfully
> complete every
> ourstanding request with SrbStatus set to SRB_STATUS_BUS_RESET, then
> the disk.sys will
> re-send me all those requests that i completed with
> SRB_STATUS_BUS_RESET status just
> now. according to your experience, is that true? (the DDK never say that).
> about your “minor clarification on TimeOutValue”, i have observed
> that, thanks. —
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
DO YOU YAHOO!?
??ӭʹ???Ż??? http: — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>