usb surprise remove after d0exit on xp fails...

NTDEV
1

Hi all,

I am using osrfx2 device with winXP. I am loading composite driver (usbccgp) as a bus driver for fx2 device and then loaded osrfx2 function driver(WDF driver) on top it. It works well.

But it creates problem under following scenario:

When device goes to D0exit (D2 state) state and if I will unplug device, neither D0Entry event callback called nor driver is unloaded and the stack goes hang. Os Is working fine. I have to reboot OS to enumerate the device again.

It works well in normal case, like device is in D0 state and is unplugged device, then driver unloaded properly.

So, I did following tests:

  1. Test the same scene with win vista and win7, it works well in these OS and the driver unloaded properly.
  2. Test the vista usbccgp driver on XP, it works well, D0entry called when device is in D2 state and is unplugged and the driver unloaded properly.

Is there any suggestion or any body having same problems? , what can be the reason? Thanks for suggestion, help.

Regards,

Paras Prajapati

2

For USB, D2 means selective suspend. The rules for selective suspend indeed have changed (to the better) from XP to Vista/Win7. Please read documentation.

Good luck,
– pa

3

ya, thats fine but here the wdf framework is handling those things in kmdf based drivers for SS and pnp IRP handlings for surprise_remove of device, so which component is creating problem, usbccgp or framework ? because the same thing works with WDM based function driver over usbccgp.sys

whether its a known issue with xp usbccgp ?

4

hi all,

test scenario in winxp for kmdf based driver:

osrfx2.sys
|
usbccgp.sys
|
osr_device

if device goes to d0exit state and if we do surprise remove, driver not unloaded in case of above stack.

we have debugged the situation in this case and found that usbccgp calls usbSetParentD0() function ,which allocates power Irp to set device device in D0 state, because before removing device it was in d2 state. Now the function which allocates Irp and dispatch to top most driver of stack returns STATUS_PENDING to usbSetParentDo(), so this function going to wait by KeWaitForSingleObject() and waiting for event which will be signaled when that power(d0 state) irp will be completed.

So, we tried to put breakpoint on that completionRoutine for Irp but that completion routine never calls and the waiting (event) of usbccgp never satisfies.

stack is as below:

nt!KiSwapContext+0x2f

nt!KiSwapThread+0x8a

nt!KeWaitForSingleObject+0x1c2

usbccgp!ParentSetD0+0x59

usbccgp!HandleFunctionPdoPower+0x83

usbccgp!USBC_Power+0x44

usbccgp!USBC_Dispatch+0x1a7

nt!IopfCallDriver+0x31

nt!PopPresentIrp+0x57

nt!PoCallDriver+0x195

wdf01000!FxPkgFdo::RaiseDevicePower+0x7b

wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x96

wdf01000!FxPkgFdo::_DispatchSetPower+0x23

wdf01000!FxPkgPnp::Dispatch+0x207

wdf01000!FxDevice::Dispatch+0x7f

wdf01000!FxDevice::DispatchWithLock+0x7b

nt!IopfCallDriver+0x31

so, what can be the possible reasons ? thanks for help

5

You could check where the IRP is stuck using !irp in the
debugger.

On 6/23/2011 5:53 AM, xxxxx@lge.com wrote:
> hi all,
>
> test scenario in winxp for kmdf based driver:
>
> osrfx2.sys
> |
> usbccgp.sys
> |
> osr_device
>
> if device goes to d0exit state and if we do surprise remove, driver not unloaded in case of above stack.
>
> we have debugged the situation in this case and found that usbccgp calls usbSetParentD0() function ,which allocates power Irp to set device device in D0 state, because before removing device it was in d2 state. Now the function which allocates Irp and dispatch to top most driver of stack returns STATUS_PENDING to usbSetParentDo(), so this function going to wait by KeWaitForSingleObject() and waiting for event which will be signaled when that power(d0 state) irp will be completed.
>
> So, we tried to put breakpoint on that completionRoutine for Irp but that completion routine never calls and the waiting (event) of usbccgp never satisfies.
>
> stack is as below:
>
> nt!KiSwapContext+0x2f
>
> nt!KiSwapThread+0x8a
>
> nt!KeWaitForSingleObject+0x1c2
>
> usbccgp!ParentSetD0+0x59
>
> usbccgp!HandleFunctionPdoPower+0x83
>
> usbccgp!USBC_Power+0x44
>
> usbccgp!USBC_Dispatch+0x1a7
>
> nt!IopfCallDriver+0x31
>
> nt!PopPresentIrp+0x57
>
> nt!PoCallDriver+0x195
>
> wdf01000!FxPkgFdo::RaiseDevicePower+0x7b
>
> wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x96
>
> wdf01000!FxPkgFdo::_DispatchSetPower+0x23
>
> wdf01000!FxPkgPnp::Dispatch+0x207
>
> wdf01000!FxDevice::Dispatch+0x7f
>
> wdf01000!FxDevice::DispatchWithLock+0x7b
>
> nt!IopfCallDriver+0x31
>
> so, what can be the possible reasons ? thanks for help
>