Cancel Sub-Irps within a complete routine

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

Mark
Thu Feb 07 09:46:02 CST 2008

On Feb 7, 8:46=A0am, "Christoph Diener" <c.die...@crossmatch.com> wrote:
> 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 t=
o
> cancel immediately
> all other sub-irps as well. I know that this is usually done by IoCancelIr=
p,
> 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

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.

Christoph
Fri Feb 08 03:17:59 CST 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:
> 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

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.

Vetzak
Fri Feb 08 03:31:52 CST 2008

On Feb 8, 10:17 am, "Christoph Diener" <c.die...@crossmatch.com>
wrote:
> 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" <ma...@hollistech.com> schrieb im Newsbeitragnews:a0cbf2fc-a23e-41c2-b5d2-de849d1f6233@e25g2000prg.googlegroups.com...
> On Feb 7, 8:46 am, "Christoph Diener" <c.die...@crossmatch.com> wrote:
>
>
>
> > 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
>
> 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.

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.

Doron
Fri Feb 08 13:10:48 CST 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...
> On Feb 8, 10:17 am, "Christoph Diener" <c.die...@crossmatch.com>
> wrote:
>> 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" <ma...@hollistech.com> schrieb im
>> Newsbeitragnews:a0cbf2fc-a23e-41c2-b5d2-de849d1f6233@e25g2000prg.googlegroups.com...
>> On Feb 7, 8:46 am, "Christoph Diener" <c.die...@crossmatch.com> wrote:
>>
>>
>>
>> > 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
>>
>> 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.
>
> 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.

Tim
Sat Feb 09 19:28:49 CST 2008

"Christoph Diener" <c.diener@crossmatch.com> wrote:
>
>The situation:
>I have a USB driver using Bulk transfers. Large Bulk requests are splitted
>into 512KB chunks.

How large? USBD can do this splitting for you.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Walter
Wed Feb 13 08:56:32 CST 2008

Tim Roberts wrote:
> >I have a USB driver using Bulk transfers. Large Bulk requests are splitted
> >into 512KB chunks.
>
> How large? USBD can do this splitting for you.

He may still need Win2K compatibility, where the max transfer size made
a difference.

--
Walter Oney, Consulting and Training
http://www.oneysoft.com

Christoph
Mon Mar 10 04:21:59 CDT 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...
> "Christoph Diener" <c.diener@crossmatch.com> wrote:
>>
>>The situation:
>>I have a USB driver using Bulk transfers. Large Bulk requests are splitted
>>into 512KB chunks.
>
> How large? USBD can do this splitting for you.
> --
> Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.

Tim
Mon Mar 10 23:57:43 CDT 2008

"Christoph Diener" <c.diener@crossmatch.com> wrote:

>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.

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.

Christoph
Tue Mar 11 03:10:35 CDT 2008

No, unfortunately not yet.

"Tim Roberts" <timr@probo.com> schrieb im Newsbeitrag
news:894ct3lt0revpaoijp52oca2bfnjmr1rht@4ax.com...
> "Christoph Diener" <c.diener@crossmatch.com> wrote:
>
>>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.
>
> 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.

Christoph
Tue May 13 07:51:45 CDT 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...
> "Christoph Diener" <c.diener@crossmatch.com> wrote:
>
>>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.
>
> 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.