Prev: get USBDSTATUS using KMDF
Next: Printer Driver hangs in installation on Vista
From: jdh28 on 5 Nov 2008 12:09
I'm looking at developing a driver for an FX2 based device and looking at the
feasibility of using the UMDF. Performance is a concern for this driver, so I
wanted to do a quick benchmark.

I thought that the FX2 sample would be a good starting point, so I've taken
that from the 6001.18002 WDK. My hardware has two alternate settings, so I
added a call to pIUsbInterface->SelectSetting() in
CMyDevice::CreateUsbIoTargets and tweaked the logic that selects the pipes
and the device now correctly enumerates.

However, if I unplug the device I get a BSOD, with the following stack trace:
bacfb978 af9d170c 0000010d 00000005 76d5d5a0 nt!KeBugCheckEx+0x1b
bacfb994 af9c7f0f 89180d48 00000005 76d5d5a0 wdf01000!FxVerifierBugCheck+0x24
bacfb9c0 af9ae879 89180d48 76d5d5a0 00001200
wdf01000!FxObjectHandleGetPtr+0x71
bacfb9ec b7697e85 89180e00 76d5d5a0 00000001 wdf01000!imp_WdfIoTargetStop+0xc4
bacfba18 af9f5902 00000050 00000005 afa11c30 WinUSB!WinUSB_D0Exit+0xb7
bacfba38 af9f550b 89145c08 afa11900 89145c08
wdf01000!FxPkgPnp::PowerGotoD3Stopped+0x14e
bacfbab0 af9f6c97 00000314 00000000 89145c08
wdf01000!FxPkgPnp::PowerEnterNewState+0x169
bacfbad8 af9f7047 bacfbaf0 0000055b afa1357c
wdf01000!FxPkgPnp::PowerProcessEventInner+0x22a
bacfbafc af9fbe3a 00000001 bacfbb80 af9fc49a
wdf01000!FxPkgPnp::PowerProcessEvent+0x20d
bacfbb08 af9fc49a 89145c08 afa129e0 89145c08
wdf01000!FxPkgPnp::PowerPolStopping+0x1a
bacfbb80 af9fcff3 0000055b 00000000 89145c08
wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
bacfbba8 af9fd72f bacfbbc0 00000129 00000008
wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x21e
bacfbbcc af9f8a29 00000001 bacfbc00 af9f9038
wdf01000!FxPkgPnp::PowerPolicyProcessEvent+0x218
bacfbbd8 af9f9038 89145c08 afa12270 89145c08
wdf01000!FxPkgPnp::PnpEventFailedIoStarting+0x12
bacfbc00 af9f9d8c 00000127 89145ca8 89145c08
wdf01000!FxPkgPnp::PnpEnterNewState+0x15c
bacfbc28 af9fa0b9 bacfbc40 89145c08 afa117a0
wdf01000!FxPkgPnp::PnpProcessEventInner+0x1f5
bacfbc50 af9f0b53 00000400 bacfbc68 af9f735d
wdf01000!FxPkgPnp::PnpProcessEvent+0x1cf
bacfbc5c af9f735d bacfbc88 bacfbc8c af9f1bcf
wdf01000!FxPkgPnp::PnpSurpriseRemoval+0x29
bacfbc68 af9f1bcf 89145c08 bacfbc88 891429f0
wdf01000!FxPkgFdo::_PnpSurpriseRemoval+0x10
bacfbc8c af9db665 891429f0 bacfbcb4 af9db888 wdf01000!FxPkgPnp::Dispatch+0x2a6
bacfbc98 af9db888 891d7110 891429f0 891429f0 wdf01000!FxDevice::Dispatch+0x7f
bacfbcb4 804ef19f 891d7110 891429f0 89317120
wdf01000!FxDevice::DispatchWithLock+0x7b
bacfbcc4 af9964bc 891429f0 89317120 00000000 nt!IopfCallDriver+0x31
bacfbd0c af996264 89317120 af9a3300 af9a2e40
wudfrd!RdPnpTracker::RdPnpProcessor+0x32e
bacfbd54 af996673 89159c08 89429630 89e3b8b8
wudfrd!RdPnpTracker::RdPnpProcessor+0xd6
bacfbd68 80576ad5 89429630 89317120 8056485c
wudfrd!RdPnpTracker::RdPnpCallbackAtPassiveInSystemProcess+0x43
bacfbd7c 8053877d 89159c08 00000000 89e3b8b8 nt!IopProcessWorkItem+0x13
bacfbdac 805cff70 89159c08 00000000 00000000 nt!ExpWorkerThread+0xef
bacfbddc 805460ee 8053868e 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


Any ideas what I might be doing wrong?

thanks,
John
From: Tim Roberts on 6 Nov 2008 00:26
jdh28 <jdh28(a)discussions.microsoft.com> wrote:
>
>I'm looking at developing a driver for an FX2 based device and looking at the
>feasibility of using the UMDF. Performance is a concern for this driver, so I
>wanted to do a quick benchmark.

When you say "performance is a concern", what kind of performance do you
mean? Do you mean raw throughput? Low latency? What kind of pipes?
Remember that UMDF can't do isochronous yet.

>I thought that the FX2 sample would be a good starting point, so I've taken
>that from the 6001.18002 WDK. My hardware has two alternate settings, so I
>added a call to pIUsbInterface->SelectSetting() in
>CMyDevice::CreateUsbIoTargets and tweaked the logic that selects the pipes
>and the device now correctly enumerates.
>
>However, if I unplug the device I get a BSOD, with the following stack trace:
>bacfb978 af9d170c 0000010d 00000005 76d5d5a0 nt!KeBugCheckEx+0x1b
>bacfb994 af9c7f0f 89180d48 00000005 76d5d5a0 wdf01000!FxVerifierBugCheck+0x24
>bacfb9c0 af9ae879 89180d48 76d5d5a0 00001200
>wdf01000!FxObjectHandleGetPtr+0x71

Bug check 10D is a violation detected by the WDF Verifier. 10D/5 is
"invalid handle". Are you trying to do USB I/O in your removal handlers?
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: jdh28 on 6 Nov 2008 04:09
"Tim Roberts" wrote:

> jdh28 <jdh28(a)discussions.microsoft.com> wrote:
> >I'm looking at developing a driver for an FX2 based device and
> >looking at the feasibility of using the UMDF. Performance is a
> >concern for this driver, so I wanted to do a quick benchmark.
>
> When you say "performance is a concern", what kind of performance do
> you mean? Do you mean raw throughput? Low latency? What kind of
> pipes? Remember that UMDF can't do isochronous yet.

Tim,

Thanks for the response. We need both raw throughput and low latency. I
have a WDM driver for the previous version of the hardware, so I'm
running benchmarks to compare performance against this. We don't use
isochronous transfers.

UMDF does extra copying between kernel and user-space, and I just want
to check what the performance hit of this is.

> >I thought that the FX2 sample would be a good starting point, so I've
> >taken that from the 6001.18002 WDK. My hardware has two alternate
> >settings, so I added a call to pIUsbInterface->SelectSetting() in
> >CMyDevice::CreateUsbIoTargets and tweaked the logic that selects the
> >pipes and the device now correctly enumerates.
> >
> >However, if I unplug the device I get a BSOD, with the following stack trace:
> >bacfb978 af9d170c 0000010d 00000005 76d5d5a0 nt!KeBugCheckEx+0x1b
> >bacfb994 af9c7f0f 89180d48 00000005 76d5d5a0 wdf01000!FxVerifierBugCheck+0x24
> >bacfb9c0 af9ae879 89180d48 76d5d5a0 00001200
> >wdf01000!FxObjectHandleGetPtr+0x71
>
> Bug check 10D is a violation detected by the WDF Verifier. 10D/5 is
> "invalid handle". Are you trying to do USB I/O in your removal handlers?

I don't think so - all I've done is take the example driver and do
SelectSetting when the device is started (OnPrepareHardware).

Regards,
John

From: jdh28 on 7 Nov 2008 04:50
"jdh28" wrote:

> I'm looking at developing a driver for an FX2 based device and looking at the
> feasibility of using the UMDF. Performance is a concern for this driver, so I
> wanted to do a quick benchmark.
>
> I thought that the FX2 sample would be a good starting point, so I've taken
> that from the 6001.18002 WDK. My hardware has two alternate settings, so I
> added a call to pIUsbInterface->SelectSetting() in
> CMyDevice::CreateUsbIoTargets and tweaked the logic that selects the pipes
> and the device now correctly enumerates.
>
> However, if I unplug the device I get a BSOD, with the following stack trace:

Interestingly, if I go back to the Vista DDK (6000), and make the same
modifications to the sample there, it works correctly.

regards,
John
From: Tim Roberts on 8 Nov 2008 17:52
jdh28 <jdh28(a)discussions.microsoft.com> wrote:
>
>Thanks for the response. We need both raw throughput and low latency.

Those two goals are, essentially, mutually exclusive in a USB device. To
get maximum throughput on a bulk pipe, you MUST use large transfers, and
have several transfers queued up at once. However, large transfers by
their very nature increase the latency.

Most people who say "we need raw throughput and low latency" have not
really done the math to figure out what the real requirements are. Without
real numbers, your goal cannot be achieved.

>UMDF does extra copying between kernel and user-space, and I just want
>to check what the performance hit of this is.

A maximum-throughput bulk pipe runs about 45 MB/sec. On today's typical
processor, a memcpy of that magnitude is less than 0.5% CPU usage.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
 |  Next  |  Last
Pages: 1 2
Prev: get USBDSTATUS using KMDF
Next: Printer Driver hangs in installation on Vista