WdfIoTargetStop calls FxUsbPipe::WaitForSentIoToComplete even with WdfIoTargetLeaveSentIoPending?

I've set up a completion routine for a bulk endpoint continuous reader
using KMDF which reads data into a buffer.

If my buffer is about to overflow, I want to stop the reader until the
buffer is emptied by my application.

I'm at DISPATCH_LEVEL inside the completion routine, so I call
WdfIoTargetStop() with argument WdfIoTargetLeaveSentIoPending.
According to the docs, this is the only way it's acceptable to call
WdfIoTargetStop at IRQL <= DISPATCH_LEVEL.

However, this still blue screens for me. When I look at the stack
backtrace, it looks like WDF is still trying to wait for some sort of
cleanup, which causes the blue screen.

You can also see from the trace that I passed 0x00000003 to
WdfIoTargetStop() which is the enumerated value for
leave-sent-IO-pending. Any ideas?

8047166c f38d1aef 8365e748 8364e690 00000000
Wdf01000!FxUsbPipeContinuousReader::CancelRepeaters+0x31
8047167c f38ca634 8364e690 00000000 00000000
Wdf01000!FxUsbPipe::WaitForSentIoToComplete+0x109
80471694 f38c613d 00000003 83b940d0 8364e690
Wdf01000!FxIoTarget::Stop+0x41
804716b0 f396d61a 8365e800 7c9b1968 00000003
Wdf01000!imp_WdfIoTargetStop+0xba
804716c4 f39713d2 7c9b1968 00000003 54434163
xxx!WdfIoTargetStop+0x1a [...kmdf10\inc\wdfiotarget.h @ 375]
80471700 f38d2272 7c9b1968 7c9c3ff0 00000003
xxx!xxxEvtBulkInCompletion+0xe2 [c:\xxx\readwrit.c @ 326]
80471730 f38f270d 7c97a1c8 7c9b1968 83653b14
Wdf01000!FxUsbPipeContinuousReader::_FxUsbPipeRequestComplete+0x3e
80471758 f38cb1dc ae08bff8 8364e690 00000000
Wdf01000!FxRequestBase::CompleteSubmitted+0x89
80471774 f38cb296 01685e30 ae08bf00 804717cc
Wdf01000!FxIoTarget::RequestCompletionRoutine+0x195
80471784 80528ee6 00000000 ae08bf00 83685e30
Wdf01000!FxIoTarget::_RequestCompletionRoutine+0x35
804717cc f742e8ae ae08bf00 83679568 85e39028
nt!IovSpecialIrpCompleteRequest+0x18c
80471820 f742e5a1 46616d64 43707269 00000000
USBPORT!USBPORT_CompleteTransfer+0x306
80471850 f742fdcd 546e6f02 80464224 83651708
USBPORT!USBPORT_DoneTransfer+0x135
8047187c f74324c8 85e39028 80464224 85e391f0
USBPORT!USBPORT_FlushDoneTransferList+0x15f
804718ac f74401a1 85e39028 80464224 85e39028
USBPORT!USBPORT_DpcWorker+0x2d2
804718f4 f7440309 85e39028 00000001 8046d6f0
USBPORT!USBPORT_IsrDpcWorker+0x36f
80471910 804644c7 85e39608 6b755044 00000000
USBPORT!USBPORT_IsrDpc+0x15b
80471924 80464462 0000000e 00000000 00000000
nt!KiRetireDpcList+0x30
ffdff800 85e3962c 00000001 80471928 0006e721
nt!KiIdleLoop+0x26
WARNING: Frame IP not in any known module. Following frames may be
wrong.
ffdff804 00000000 80471928 0006e721 0006e718 0x85e3962c

chris
Wed Sep 06 17:44:48 CDT 2006

chris.aseltine@gmail.com wrote:

> I'm at DISPATCH_LEVEL inside the completion routine, so I call
> WdfIoTargetStop() with argument WdfIoTargetLeaveSentIoPending.
> According to the docs, this is the only way it's acceptable to call
> WdfIoTargetStop at IRQL <= DISPATCH_LEVEL.
>
> However, this still blue screens for me. When I look at the stack
> backtrace, it looks like WDF is still trying to wait for some sort of
> cleanup, which causes the blue screen.

By the way -- if I pass WdfIoTargetSentIoUndefined ( == 0), I don't
blue screen (and the outstanding reads all complete asynchronously,
which is okay because I stop the reader well before I am out of buffer
space).

chris
Wed Sep 06 17:55:27 CDT 2006

chris.aseltine@gmail.com wrote:

> By the way -- if I pass WdfIoTargetSentIoUndefined ( == 0), I don't
> blue screen (and the outstanding reads all complete asynchronously,
> which is okay because I stop the reader well before I am out of buffer
> space).

Unfortunately, this doesn't seem to actually stop the reader, either.

Eliyas
Wed Sep 06 19:06:48 CDT 2006

Can you check the IFR log of your driver to see if the framework is changing
the stop action? Looking at the code, for continuous reader, framework
changes your action under the cover from WdfIoTargetLeaveSentIoPending to
WdfIoTargetCancelSentIo and then later blows up when it tries to wait at
DISPATCH_LEVEL. Doron might be able to tell you the reason behind making
that change.

Othen than queueing a workitem to get to passive-level, I don't know how
else you can stop the reader from posting more reads from your completion
rotuine.

-Eliyas

<chris.aseltine@gmail.com> wrote in message
news:1157583327.616677.288390@d34g2000cwd.googlegroups.com...
> chris.aseltine@gmail.com wrote:
>
>> By the way -- if I pass WdfIoTargetSentIoUndefined ( == 0), I don't
>> blue screen (and the outstanding reads all complete asynchronously,
>> which is okay because I stop the reader well before I am out of buffer
>> space).
>
> Unfortunately, this doesn't seem to actually stop the reader, either.
>

chris
Wed Sep 06 22:12:59 CDT 2006

Eliyas Yakub [MSFT] wrote:

> Can you check the IFR log of your driver to see if the framework is changing
> the stop action?

I've never tried the in-flight recorder stuff before, but I'll give it
a shot. But based on what you say below, and the fact that I
bugchecked, I don't think I'll find any evidence to the contrary.

> Looking at the code, for continuous reader, framework
> changes your action under the cover from WdfIoTargetLeaveSentIoPending to
> WdfIoTargetCancelSentIo and then later blows up when it tries to wait at
> DISPATCH_LEVEL. Doron might be able to tell you the reason behind making
> that change.

Yikes. Are there many other gotchas like this lurking about, waiting
to be found? (I still don't know why I need a hub to talk to the
second interface of my composite device, either.)

I would think that at the very least, this should be mentioned in the
documentation -- or perhaps the call to WdfIoTargetStop() could fail if
that Stop Action flag is passed.

> Othen than queueing a workitem to get to passive-level, I don't know how
> else you can stop the reader from posting more reads from your completion
> rotuine.

This is exactly what I've done in the meantime. Since I'm now inside
the work item I've changed my approach to just wait (synchronously) for
all the pended reads to clean up.

-Chris

Doron
Wed Sep 06 22:40:17 CDT 2006

stopping the continuous reader on the device is a bit of a red herring here.
let's say you stop sending reads. your device will run out of buffers and
start tossing data. now you have lost all of your state. instead, keep the
reader going and start tossing out buffers returned to you if you have
reached some limit. this way your device will not have a buffer overrun and
you can maintain the correct state.

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.


<chris.aseltine@gmail.com> wrote in message
news:1157598779.744521.310810@d34g2000cwd.googlegroups.com...
> Eliyas Yakub [MSFT] wrote:
>
>> Can you check the IFR log of your driver to see if the framework is
>> changing
>> the stop action?
>
> I've never tried the in-flight recorder stuff before, but I'll give it
> a shot. But based on what you say below, and the fact that I
> bugchecked, I don't think I'll find any evidence to the contrary.
>
>> Looking at the code, for continuous reader, framework
>> changes your action under the cover from WdfIoTargetLeaveSentIoPending to
>> WdfIoTargetCancelSentIo and then later blows up when it tries to wait at
>> DISPATCH_LEVEL. Doron might be able to tell you the reason behind making
>> that change.
>
> Yikes. Are there many other gotchas like this lurking about, waiting
> to be found? (I still don't know why I need a hub to talk to the
> second interface of my composite device, either.)
>
> I would think that at the very least, this should be mentioned in the
> documentation -- or perhaps the call to WdfIoTargetStop() could fail if
> that Stop Action flag is passed.
>
>> Othen than queueing a workitem to get to passive-level, I don't know how
>> else you can stop the reader from posting more reads from your completion
>> rotuine.
>
> This is exactly what I've done in the meantime. Since I'm now inside
> the work item I've changed my approach to just wait (synchronously) for
> all the pended reads to clean up.
>
> -Chris
>

chris
Wed Sep 06 22:53:03 CDT 2006

Doron Holan [MS] wrote:

> stopping the continuous reader on the device is a bit of a red herring here.
> let's say you stop sending reads. your device will run out of buffers and
> start tossing data. now you have lost all of your state. instead, keep the
> reader going and start tossing out buffers returned to you if you have
> reached some limit. this way your device will not have a buffer overrun and
> you can maintain the correct state.

I guess my approach to the situation was that if there was a buffer
overrun anywhere in the system, all bets are off (or, I've lost my
"state").

Or, put another way, what's the difference between the device throwing
away the data and the PC driver throwing away the data? (or, taking
your logic a step further, why allow the continuous reader to be
stopped at all, outside of a power state change or device removal?)

I suppose if the PC driver is throwing away data, it can at least
(maybe) keep track of where the device thinks it "is", even if it's
throwing away the actual data, which could possibly lead to a recovery
later. In my particular situation this doesn't really apply / wouldn't
work, but I suppose in others it would.

At any rate, I suppose I still have the humble opinion that silently
ignoring the user's stop action without any warning, and thus causing a
blue screen, could probably be handled better.

Doron
Wed Sep 06 23:05:10 CDT 2006

yes, it could be. you can blame me, i wrote this code. the reasons behind
why it works this way is a bit complicated, but it boils down to there can
only be one stop occurring at at time and b/c you don't control the i/o
being sent by the cont reader, asynchronously completing the stop is hard
b/c you don't know when it is done.

since you are chucking data, queue a work item and perform the stop there.
even if you could stop the reader at dispatch level, there are still pending
reads that can complete later, so the queueing of the work item just makes
this window a little larger.

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.


<chris.aseltine@gmail.com> wrote in message
news:1157601183.794369.186360@d34g2000cwd.googlegroups.com...
> Doron Holan [MS] wrote:
>
>> stopping the continuous reader on the device is a bit of a red herring
>> here.
>> let's say you stop sending reads. your device will run out of buffers
>> and
>> start tossing data. now you have lost all of your state. instead, keep
>> the
>> reader going and start tossing out buffers returned to you if you have
>> reached some limit. this way your device will not have a buffer overrun
>> and
>> you can maintain the correct state.
>
> I guess my approach to the situation was that if there was a buffer
> overrun anywhere in the system, all bets are off (or, I've lost my
> "state").
>
> Or, put another way, what's the difference between the device throwing
> away the data and the PC driver throwing away the data? (or, taking
> your logic a step further, why allow the continuous reader to be
> stopped at all, outside of a power state change or device removal?)
>
> I suppose if the PC driver is throwing away data, it can at least
> (maybe) keep track of where the device thinks it "is", even if it's
> throwing away the actual data, which could possibly lead to a recovery
> later. In my particular situation this doesn't really apply / wouldn't
> work, but I suppose in others it would.
>
> At any rate, I suppose I still have the humble opinion that silently
> ignoring the user's stop action without any warning, and thus causing a
> blue screen, could probably be handled better.
>