Hi,
Under which conditions other than mentioned below HwResetBus() can be called in a SCSI Miniport driver.
- IO timeout.
- Cluster Reset.
I am facing an issue where I am completing a command with SRB_STATUS_BUSY and not asking for next request to the port driver. This I am doing when I dont have any outstanding request with the driver.
At times, in this situation, port driver is calling HwResetBus() even when I dont have any outstanding IOs in the driver.
Is this a port driver issue or something which I am not aware of.
I am using Windows XP SP2.
Thanks in Advance.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
This is still a timeout situation. The request you returned with busy
status is still not completed; the port driver is waiting for you to ask
for the next request so it can be retried, and the port driver is timing
it out.
Jerry.
xxxxx@lists.osr.com wrote on 05/11/2006 10:06:44 PM:
Hi,
Under which conditions other than mentioned below HwResetBus() can
be called in a SCSI Miniport driver.
- IO timeout.
- Cluster Reset.
I am facing an issue where I am completing a command with
SRB_STATUS_BUSY and not asking for next request to the port driver.
This I am doing when I dont have any outstanding request with the
driver.
At times, in this situation, port driver is calling HwResetBus()
even when I dont have any outstanding IOs in the driver.
Is this a port driver issue or something which I am not aware of.
I am using Windows XP SP2.
Thanks in Advance.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com — Questions? First check the Kernel Driver FAQ
at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit
the List Server section of OSR Online at http://www.osronline.
com/page.cfm?name=ListServer
Well you have a point but think of a situation when you cannot process any command and you dont want port driver to send you any more commands till you ask for it (not a indefinite wait), then why should port driver issue a resetBus and that too HwResetBus. Port driver can send SRB_FUNCTION_RESET_BUS (actually this might be initiated by disk class driver).
In Storport, you can pause the adapter and rest assured you will not get any more commands including HwResetBus().
What should be the ideal way in SCSI Miniport then? I guess returning only SRB_STATUS_BUSY.
Thoughts??
xxxxx@attotech.com wrote: This is still a timeout situation. The request you returned with busy
status is still not completed; the port driver is waiting for you to ask
for the next request so it can be retried, and the port driver is timing
it out.
Jerry.
xxxxx@lists.osr.com wrote on 05/11/2006 10:06:44 PM:
Hi,
Under which conditions other than mentioned below HwResetBus() can
be called in a SCSI Miniport driver.
- IO timeout.
- Cluster Reset.
I am facing an issue where I am completing a command with
SRB_STATUS_BUSY and not asking for next request to the port driver.
This I am doing when I dont have any outstanding request with the
driver.
At times, in this situation, port driver is calling HwResetBus()
even when I dont have any outstanding IOs in the driver.
Is this a port driver issue or something which I am not aware of.
I am using Windows XP SP2.
Thanks in Advance.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com — Questions? First check the Kernel Driver FAQ
at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit
the List Server section of OSR Online at http://www.osronline.
com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
Well, thinking about it from the upper level drivers’ viewpoint, if I expect a command to be done in no more than 10 seconds, then something’s wrong if it’s not done by that time from the time I sent it, not from the time that it was accepted by the Miniport. And the default time for disk reads/writes is 10 seconds * however many 64k segments or parts thereof that I’m transferring … which I think is WAAAAY too long! And then some FC adapters have changed the default to 60 seconds, so a 1 meg request times out in 16 MINUTES??? Ridiculous!
I thought that StorPort would first try to abort the particular command before issuing a Bus Reset. But I'm not sure about what happens if the miniport doesn't even have the command (because it returned busy). Thinking about it from the port driver's viewpoint, it's issuing a bus reset just 'cause it doesn't know what else to do - maybe the SCSI bus is hung and that's why the miniport can't take another request.
I'm not sure what happens when you "pause" the adapter.
I would ask the basic question ... why is the miniport unable to accept a new command for such a long time? And what is the effect on the rest of the system (that might want to be doing something on the SCSI bus to some other device on that adapter) during this time? The timeout value is specified in seconds!
Jerry.
xxxxx@lists.osr.com wrote: -----
To: "Windows System Software Devs Interest List"
From: Gurpreet Anand
Sent by: xxxxx@lists.osr.com
Date: 05/12/2006 03:12PM
Subject: Re: [ntdev] Ref: SRB_STATUS_BUSY and HwResetBus
Well you have a point but think of a situation when you cannot process any command and you dont want port driver to send you any more commands till you ask for it (not a indefinite wait), then why should port driver issue a resetBus and that too HwResetBus. Port driver can send SRB_FUNCTION_RESET_BUS (actually this might be initiated by disk class driver).
In Storport, you can pause the adapter and rest assured you will not get any more commands including HwResetBus().
What should be the ideal way in SCSI Miniport then? I guess returning only SRB_STATUS_BUSY.
Thoughts??
xxxxx@attotech.com wrote: This is still a timeout situation. The request you returned with busy
status is still not completed; the port driver is waiting for you to ask
for the next request so it can be retried, and the port driver is timing
it out.
Jerry.
xxxxx@lists.osr.com wrote on 05/11/2006 10:06:44 PM:
> Hi,
>
> Under which conditions other than mentioned below HwResetBus() can
> be called in a SCSI Miniport driver.
>
> 1. IO timeout.
> 2. Cluster Reset.
>
> I am facing an issue where I am completing a command with
> SRB_STATUS_BUSY and not asking for next request to the port driver.
> This I am doing when I dont have any outstanding request with the
driver.
> At times, in this situation, port driver is calling HwResetBus()
> even when I dont have any outstanding IOs in the driver.
>
> Is this a port driver issue or something which I am not aware of.
> I am using Windows XP SP2.
>
> Thanks in Advance.
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com --- Questions? First check the Kernel Driver FAQ
at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit
> the List Server section of OSR Online at http://www.osronline.
> com/page.cfm?name=ListServer
---
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. --- Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> What should be the ideal way in SCSI Miniport then? I guess returning only
SRB_STATUS_BUSY.
SRB_STATUS_BUSY is a bad thing, so is SCSISTAT_BUSY.
Such requests are automatically retried by SCSIPORT after exactly 1 second, and
you cannot influence this behaviour or this timeout. They are retried IIRC till
the total TimeoutValue of the SRB will not elapse.
I once developed a hooking patch for SCSIPORT (it patched ScsiPortNotification)
which changes SRB_STATUS_BUSY and SCSISTAT_BUSY to some other error status.
This was to support some exotic hardware which failed the CDBs with
SCSISTAT_BUSY if there was a long background (Immed=1) operation in progress -
the wrong way, SCSI spec requires a check condition there with the special
sense info values, one of them being the percentage of the long operation done
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
At times when you resume from Standby and the FW is not up and running and is still initializing, you have to wait for the FW to comeup before any command is send down. In this case, we cannot process the command and so the command is returned with a BUSY status till the FW is up and running.
I have the default timeout setup in the registry to 60secs …but I have seen port driver sending HwResetBus() much before the 60 secs expires.
xxxxx@attotech.com wrote: Well, thinking about it from the upper level drivers’ viewpoint, if I expect a command to be done in no more than 10 seconds, then something’s wrong if it’s not done by that time from the time I sent it, not from the time that it was accepted by the Miniport. And the default time for disk reads/writes is 10 seconds * however many 64k segments or parts thereof that I’m transferring … which I think is WAAAAY too long! And then some FC adapters have changed the default to 60 seconds, so a 1 meg request times out in 16 MINUTES??? Ridiculous!
I thought that StorPort would first try to abort the particular command before issuing a Bus Reset. But I’m not sure about what happens if the miniport doesn’t even have the command (because it returned busy). Thinking about it from the port driver’s viewpoint, it’s issuing a bus reset just 'cause it doesn’t know what else to do - maybe the SCSI bus is hung and that’s why the miniport can’t take another request.
I’m not sure what happens when you “pause” the adapter.
I would ask the basic question … why is the miniport unable to accept a new command for such a long time? And what is the effect on the rest of the system (that might want to be doing something on the SCSI bus to some other device on that adapter) during this time? The timeout value is specified in seconds!
Jerry.
xxxxx@lists.osr.com wrote: -----
To: “Windows System Software Devs Interest List”
From: Gurpreet Anand
Sent by: xxxxx@lists.osr.com
Date: 05/12/2006 03:12PM
Subject: Re: [ntdev] Ref: SRB_STATUS_BUSY and HwResetBus
Well you have a point but think of a situation when you cannot process any command and you dont want port driver to send you any more commands till you ask for it (not a indefinite wait), then why should port driver issue a resetBus and that too HwResetBus. Port driver can send SRB_FUNCTION_RESET_BUS (actually this might be initiated by disk class driver).
In Storport, you can pause the adapter and rest assured you will not get any more commands including HwResetBus().
What should be the ideal way in SCSI Miniport then? I guess returning only SRB_STATUS_BUSY.
Thoughts??
xxxxx@attotech.com wrote: This is still a timeout situation. The request you returned with busy
status is still not completed; the port driver is waiting for you to ask
for the next request so it can be retried, and the port driver is timing
it out.
Jerry.
xxxxx@lists.osr.com wrote on 05/11/2006 10:06:44 PM:
> Hi,
>
> Under which conditions other than mentioned below HwResetBus() can
> be called in a SCSI Miniport driver.
>
> 1. IO timeout.
> 2. Cluster Reset.
>
> I am facing an issue where I am completing a command with
> SRB_STATUS_BUSY and not asking for next request to the port driver.
> This I am doing when I dont have any outstanding request with the
driver.
> At times, in this situation, port driver is calling HwResetBus()
> even when I dont have any outstanding IOs in the driver.
>
> Is this a port driver issue or something which I am not aware of.
> I am using Windows XP SP2.
>
> Thanks in Advance.
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com — Questions? First check the Kernel Driver FAQ
at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit
> the List Server section of OSR Online at http://www.osronline.
> com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
---------------------------------
How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
Thanks Max,
This sounds promising.
So if my HW is not ready to accept any commands, I can map the Srb_status_busy to some special error value.
Can you share the information in detail so I can try this at my end.
“Maxim S. Shatskih” wrote: > What should be the ideal way in SCSI Miniport then? I guess returning only
>SRB_STATUS_BUSY.
SRB_STATUS_BUSY is a bad thing, so is SCSISTAT_BUSY.
Such requests are automatically retried by SCSIPORT after exactly 1 second, and
you cannot influence this behaviour or this timeout. They are retried IIRC till
the total TimeoutValue of the SRB will not elapse.
I once developed a hooking patch for SCSIPORT (it patched ScsiPortNotification)
which changes SRB_STATUS_BUSY and SCSISTAT_BUSY to some other error status.
This was to support some exotic hardware which failed the CDBs with
SCSISTAT_BUSY if there was a long background (Immed=1) operation in progress -
the wrong way, SCSI spec requires a check condition there with the special
sense info values, one of them being the percentage of the long operation done
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
---------------------------------
Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.
>send down. In this case, we cannot process the command and so the is returned
with a BUSY status till the FW is up and running.
Return CHECK CONDITION instead with the sense info of “lengthly operation in
progress”.
Or wait for 100% full FW init in your AdapterControl callback.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
I think I have already shared the details what more details do you
need? The sense info for “lengthly operation is in progress” is in the SCSI
spec.
Also note: for power resume, you have AdapterControl callback. Look in this
direction too. Proper use of AdapterControl callback will result in a situation
when your StartIo will never be called before your FW is up again.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Gurpreet Anand”
To: “Windows System Software Devs Interest List”
Sent: Saturday, May 13, 2006 10:38 AM
Subject: Re: [ntdev] Ref: SRB_STATUS_BUSY and HwResetBus
> Thanks Max,
>
> This sounds promising.
> So if my HW is not ready to accept any commands, I can map the
Srb_status_busy to some special error value.
> Can you share the information in detail so I can try this at my end.
>
> “Maxim S. Shatskih” wrote: > What should be the
ideal way in SCSI Miniport then? I guess returning only
> >SRB_STATUS_BUSY.
>
> SRB_STATUS_BUSY is a bad thing, so is SCSISTAT_BUSY.
>
> Such requests are automatically retried by SCSIPORT after exactly 1 second,
and
> you cannot influence this behaviour or this timeout. They are retried IIRC
till
> the total TimeoutValue of the SRB will not elapse.
>
> I once developed a hooking patch for SCSIPORT (it patched
ScsiPortNotification)
> which changes SRB_STATUS_BUSY and SCSISTAT_BUSY to some other error status.
>
> This was to support some exotic hardware which failed the CDBs with
> SCSISTAT_BUSY if there was a long background (Immed=1) operation in
progress -
> the wrong way, SCSI spec requires a check condition there with the special
> sense info values, one of them being the percentage of the long operation
done
>
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> ---------------------------------
> Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo!
Messenger with Voice.
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I think the Vista/Longhorn is coming up with a restriction of not staying too long in AdapterControl after resume. So that is the reason the processing has to be moved out.
Thanks for all the information Max. This should indeed help me fix this issue.
“Maxim S. Shatskih” wrote: >send down. In this case, we cannot process the command and so the is returned
>with a BUSY status till the FW is up and running.
Return CHECK CONDITION instead with the sense info of “lengthly operation in
progress”.
Or wait for 100% full FW init in your AdapterControl callback.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
When you return this status, you still have ask for the next request. SCSIPORT doesn’t like letting controllers just sit idle - 99% of the time it’s an indication of a software or device bug and reset tends to clear it up.
Why does your firmware take so long to start back up?
-p
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gurpreet Anand
Sent: Saturday, May 13, 2006 7:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Ref: SRB_STATUS_BUSY and HwResetBus
I think the Vista/Longhorn is coming up with a restriction of not staying too long in AdapterControl after resume. So that is the reason the processing has to be moved out.
Thanks for all the information Max. This should indeed help me fix this issue.
“Maxim S. Shatskih” wrote:
>send down. In this case, we cannot process the command and so the is returned
>with a BUSY status till the FW is up and running.
Return CHECK CONDITION instead with the sense info of “lengthly operation in
progress”.
Or wait for 100% full FW init in your AdapterControl callback.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
________________________________
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1?/min. — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer http:</http:>