Re: how to block other instructions

You can’t completely avoid it, unless you want to block inbound IRPs from
above you while you are processing your action. That means you have to
queue them up while you are busy, then deliver them all once you are done.
Since only your app is dependent on SET MAX ADDRESS success to make forward
progress, and the system continues to make forward progress whether SET MAX
ADDRESS succeeds or not, the simpler case is to simply retry the READ
NATIVE MAX/SET MAX ADDRESS pair until you succeed. Unless you are
competing with a disk intensive workload, you should probably complete
relatively quickly. If this is something that is expected to work on a
busy server, as one example of a difficult environment where the simple
retry strategy will probably fail for a long time, you should probably
block inbound IRPs.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

Leo
> To
Sent by: “Windows System Software Devs
bounce-217141-643 Interest List”
xxxxx@lists.osr.com
No Phone Info cc
Available
Subject
[ntdev] [ntdev]how to block other
08/15/2005 08:31 instructions
AM

Please respond to
“Windows System
Software Devs
Interest List”
com>

Hi, all:
My driver will send two ata instructions(READ NATIVE MAX and SET
NATIVE MAX) to disk. I use the ATA_PASS_THROUGH ioctl which was
provided by atapi.sys.

ATA specification says that if READ NATIVE MAX does not follow up
with SET NATIVE MAX immediately, the SET NATIVE MAX instruction will
not success. But atapi.sys may insert some other instructions between
READ and SET when my driver send those in sequence.

My dirver is a filter driver upon atapi.sys, how can i avoid above
situation.


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

Philip:
Thanks for reply.
I have thought both ways to do that.
I can block any irp when I send my ioctl code, but I can not block
the irp before I send my ioctl code. So, when i send my ioctl,
atapi.sys may not complete the irp previous, and it may insert some
other instructions (such as Write DMA) between READ and SET command.
In my test, this case occurs frequently.
Block irp may also cause the deadlock when computer resume from
s3/s4 hibernate.

I use retry strategy to deal with this problem. But it seems not
work very well. I use 15 times retry to set native max, but in some
case, this failed.
Should i use a infinite loop to retry this ?

Leo

On 8/16/05, Philip D Barila wrote:
> You can’t completely avoid it, unless you want to block inbound IRPs from
> above you while you are processing your action. That means you have to
> queue them up while you are busy, then deliver them all once you are done.
> Since only your app is dependent on SET MAX ADDRESS success to make forward
> progress, and the system continues to make forward progress whether SET MAX
> ADDRESS succeeds or not, the simpler case is to simply retry the READ
> NATIVE MAX/SET MAX ADDRESS pair until you succeed. Unless you are
> competing with a disk intensive workload, you should probably complete
> relatively quickly. If this is something that is expected to work on a
> busy server, as one example of a difficult environment where the simple
> retry strategy will probably fail for a long time, you should probably
> block inbound IRPs.
>
> Phil
>
> Philip D. Barila
> Seagate Technology LLC
> (720) 684-1842
>
>
>
> Leo
> > > To
> Sent by: “Windows System Software Devs
> bounce-217141-643 Interest List”
> xxxxx@lists.osr.com
> No Phone Info cc
> Available
> Subject
> [ntdev] [ntdev]how to block other
> 08/15/2005 08:31 instructions
> AM
>
>
> Please respond to
> “Windows System
> Software Devs
> Interest List”
> > com>
>
>
>
>
>
>
> Hi, all:
> My driver will send two ata instructions(READ NATIVE MAX and SET
> NATIVE MAX) to disk. I use the ATA_PASS_THROUGH ioctl which was
> provided by atapi.sys.
>
> ATA specification says that if READ NATIVE MAX does not follow up
> with SET NATIVE MAX immediately, the SET NATIVE MAX instruction will
> not success. But atapi.sys may insert some other instructions between
> READ and SET when my driver send those in sequence.
>
> My dirver is a filter driver upon atapi.sys, how can i avoid above
> situation.
>
> —
> 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
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

You have to load early (as in boot group), and keep track of all the IRPs
you see. When you decide you want to issue your commands, start queuing
all inbound IRPs, and wait for all outstanding IRPs to complete. Then
issue your command pair. Then start delivering the IRPs from your queue
when you’ve completed your work.

There are still some possible problems with the above approach.
If someone is using a hanging IOCTL as an inverted call mechanism, you
might end up deadlocked if you are waiting for that to complete. Haven’t
thought through the right approach to that one.
If someone else issues a long operation through the APTI, such as a long
DST, you might interpret that as being deadlocked as well, even though you
aren’t. It wouldn’t be too hard to catch that one, but it would require
detecting the APT IOCTL and then peeking into the timeout value, and making
sure you don’t panic if it’s really long. Actually, if that’s the only
thing outstanding, you could just submit your own IOCTL at that point, it
won’t interrupt the current one, and ATAPI.SYS will process it as soon as
it resolves the current one.

There are probably a few more issues with that approach that I haven’t
thought about,

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

Leo
> To
Sent by: “Windows System Software Devs
bounce-217146-643 Interest List”
xxxxx@lists.osr.com
No Phone Info cc
Available
Subject
Re: [ntdev] how to block other
08/15/2005 10:36 instructions
AM

Please respond to
“Windows System
Software Devs
Interest List”
com>

Philip:
Thanks for reply.
I have thought both ways to do that.
I can block any irp when I send my ioctl code, but I can not block
the irp before I send my ioctl code. So, when i send my ioctl,
atapi.sys may not complete the irp previous, and it may insert some
other instructions (such as Write DMA) between READ and SET command.
In my test, this case occurs frequently.
Block irp may also cause the deadlock when computer resume from
s3/s4 hibernate.

I use retry strategy to deal with this problem. But it seems not
work very well. I use 15 times retry to set native max, but in some
case, this failed.
Should i use a infinite loop to retry this ?

Leo

On 8/16/05, Philip D Barila wrote:
> You can’t completely avoid it, unless you want to block inbound IRPs from
> above you while you are processing your action. That means you have to
> queue them up while you are busy, then deliver them all once you are
done.
> Since only your app is dependent on SET MAX ADDRESS success to make
forward
> progress, and the system continues to make forward progress whether SET
MAX
> ADDRESS succeeds or not, the simpler case is to simply retry the READ
> NATIVE MAX/SET MAX ADDRESS pair until you succeed. Unless you are
> competing with a disk intensive workload, you should probably complete
> relatively quickly. If this is something that is expected to work on a
> busy server, as one example of a difficult environment where the simple
> retry strategy will probably fail for a long time, you should probably
> block inbound IRPs.
>
> Phil
>
> Philip D. Barila
> Seagate Technology LLC
> (720) 684-1842
>
>
>
> Leo
> > > To
> Sent by: “Windows System Software Devs
> bounce-217141-643 Interest List”
> xxxxx@lists.osr.com
> No Phone Info cc
> Available
> Subject
> [ntdev] [ntdev]how to block other
> 08/15/2005 08:31 instructions
> AM
>
>
> Please respond to
> “Windows System
> Software Devs
> Interest List”
> > com>
>
>
>
>
>
>
> Hi, all:
> My driver will send two ata instructions(READ NATIVE MAX and SET
> NATIVE MAX) to disk. I use the ATA_PASS_THROUGH ioctl which was
> provided by atapi.sys.
>
> ATA specification says that if READ NATIVE MAX does not follow up
> with SET NATIVE MAX immediately, the SET NATIVE MAX instruction will
> not success. But atapi.sys may insert some other instructions between
> READ and SET when my driver send those in sequence.
>
> My dirver is a filter driver upon atapi.sys, how can i avoid above
> situation.
>
> —
> 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
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


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

It will also depend on when you want to send these. If you could
restrict it to handling IRP_MJ_PNP/IRP_MN_START_DEVICE then you could be
reasonably assured that nothing would send another request in between
the two operations.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Monday, August 15, 2005 9:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] how to block other instructions

You can’t completely avoid it, unless you want to block inbound IRPs
from above you while you are processing your action. That means you
have to queue them up while you are busy, then deliver them all once you
are done.
Since only your app is dependent on SET MAX ADDRESS success to make
forward progress, and the system continues to make forward progress
whether SET MAX ADDRESS succeeds or not, the simpler case is to simply
retry the READ NATIVE MAX/SET MAX ADDRESS pair until you succeed.
Unless you are competing with a disk intensive workload, you should
probably complete relatively quickly. If this is something that is
expected to work on a busy server, as one example of a difficult
environment where the simple retry strategy will probably fail for a
long time, you should probably block inbound IRPs.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

Leo


>
To
Sent by: “Windows System Software Devs

bounce-217141-643 Interest List”

xxxxx@lists.osr.com

No Phone Info
cc
Available

Subject
[ntdev] [ntdev]how to block other

08/15/2005 08:31 instructions

AM

Please respond to

“Windows System

Software Devs

Interest List”


com>

Hi, all:
My driver will send two ata instructions(READ NATIVE MAX and SET
NATIVE MAX) to disk. I use the ATA_PASS_THROUGH ioctl which was provided
by atapi.sys.

ATA specification says that if READ NATIVE MAX does not follow up
with SET NATIVE MAX immediately, the SET NATIVE MAX instruction will not
success. But atapi.sys may insert some other instructions between READ
and SET when my driver send those in sequence.

My dirver is a filter driver upon atapi.sys, how can i avoid above
situation.


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


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