- Cancel Sub-Irps within a complete routine
- Posted by Christoph Diener on February 7th, 2008
The situation:
I have a USB driver using Bulk transfers. Large Bulk requests are splitted
into 512KB chunks.
To do so, the main Irp creates multiple sub Irps with a completion routine
down the USB stack.
After the last sub Irp completes, I complete the main Irp too.
Since the device is sometimes not able to deliver enough data, I like to
complete the main IRP of this
incomplete USB transfer as soon as possible then (so the device would be
able to send
immediately fresh data for the next overlapped request - in our case an
image).
The problem:
I detect a short transfer in my completion routine of a sub-irp and have to
cancel immediately
all other sub-irps as well. I know that this is usually done by IoCancelIrp,
but I am in an
awkward situation here, because I am already in a complete routine.
How can I complete the other sub-irps and the main irp from a completion
routine?
Thanks in advance,
Christoph
- Posted by Mark Roddy on February 7th, 2008
On Feb 7, 8:46*am, "Christoph Diener" <c.die...@crossmatch.com> wrote:
At the risk of stating the obvious: call IoCancelIrp for each of the
sub irps in your completion routine and then let the completion of all
those sub irps cause the completion of the original irp. Of course you
have to be able to find all of the sub irps.
- Posted by Christoph Diener on February 8th, 2008
Hmm, I was doing so, but my screen turned into blue. Some interrupt request
level
was too high or low and so I was believing that this kind of recursively
calling of
the same function could be not the thing drivers like to do.
"Mark Roddy" <markr@hollistech.com> schrieb im Newsbeitrag
news:a0cbf2fc-a23e-41c2-b5d2-de849d1f6233@e25g2000prg.googlegroups.com...
On Feb 7, 8:46 am, "Christoph Diener" <c.die...@crossmatch.com> wrote:
At the risk of stating the obvious: call IoCancelIrp for each of the
sub irps in your completion routine and then let the completion of all
those sub irps cause the completion of the original irp. Of course you
have to be able to find all of the sub irps.
- Posted by Vetzak on February 8th, 2008
On Feb 8, 10:17 am, "Christoph Diener" <c.die...@crossmatch.com>
wrote:
You have to move out the (sub)IRPs from your device context (device
extension) to local thread-safe variables in the spin-locked section,
and then call IoCancelIrp() outside the spin-locked section.
- Posted by Doron Holan [MSFT] on February 8th, 2008
that is not enough. you must also guard against the subirp completing back
to your driver (and being freed or completed up the stack) in another
context while you are attempting to cancel the irp. oney's book has a
solution on how to synchronize the cancelation with the completion of the
irp so you are not touching a freed irp
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Vetzak" <ptrshrn@gmail.com> wrote in message
news:2207fba0-3bcc-4869-8e71-780825af96d1@q21g2000hsa.googlegroups.com...
- Posted by Tim Roberts on February 10th, 2008
"Christoph Diener" <c.diener@crossmatch.com> wrote:
How large? USBD can do this splitting for you.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
- Posted by Walter Oney on February 13th, 2008
Tim Roberts wrote:
He may still need Win2K compatibility, where the max transfer size made
a difference.
--
Walter Oney, Consulting and Training
http://www.oneysoft.com
- Posted by Christoph Diener on March 10th, 2008
In my particular case the images are below 2MB, so -yes- USBD is capable to
split it. That works well for us under WindowsXP, but Vista is introducing a
time delay in this split mechanism. So after 512KB there is a too long delay
until the next USB IN token comes to lighten the devices FIFO. So after
512KB we get a FIFO overflow. The solution is to do the splitting by
ourself. This is working so far, but I must optimize the cancelation stuff
to react more quickly in case of a device failure.
"Tim Roberts" <timr@probo.com> schrieb im Newsbeitrag
news:5qksq3hvtude6ama650032s8m73chbgepp@4ax.com...
- Posted by Tim Roberts on March 11th, 2008
"Christoph Diener" <c.diener@crossmatch.com> wrote:
That's just a Vista bug. Have you had a chance to try this on Vista SP1?
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
- Posted by Christoph Diener on March 11th, 2008
No, unfortunately not yet.
"Tim Roberts" <timr@probo.com> schrieb im Newsbeitrag
news:894ct3lt0revpaoijp52oca2bfnjmr1rht@4ax.com...
- Posted by Christoph Diener on May 13th, 2008
Now, I tried Vista SP1 but it failed i.e. it has the same IN-token delay.
Meanwhile I found a solution. I split up large USB BULK transfers
into 512KB pieces in the same way the isousb example does.
"Tim Roberts" <timr@probo.com> schrieb im Newsbeitrag
news:894ct3lt0revpaoijp52oca2bfnjmr1rht@4ax.com...
