don't go to stanby from C3 state

I am makeing WDM streaming driver like USBintel.
we supported selective suspend.
But we faced a new problem.
Some PC can go to Stanby mode with pluging in our capture driver.
But some PC can NOT go to Stanby mode with pluging in our capture driver.
All PC that we can test, can go to Stanby mode with pluging in our capture
driver
before we building SelfSuspend mode ( or selective suspend mode )
in our capture driver.

Unfortunately, the PC can not go to Stanby mode was not near me.

I think that,
when a PC go to suspend mode,
IdleNotificationRequestCompletion must be called.

some PC's may not call that routin.

I don't write codes for WaitWake because
our device not support remote wake.

I hope to some advice for facing that Bug.

martinbo
Thu Aug 11 19:01:26 CDT 2005

------=_NextPart_0001_089BE004
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Off-hand I don't see why submitting an idle notification IRP would
interfere with going into standby. You will probably need to get a machine
that you can repro this behavior on and debug it.


Martin Borve
Windows DDK Support
This posting is provided "AS IS" with no warranties, and confers no rights.

------=_NextPart_0001_089BE004
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Off-hand I don't see why submitting an idle notification IRP would interfere with going into standby. You will probably need to get a machine that you can repro this behavior on and debug it.
\par
\par
\par Martin Borve
\par Windows DDK Support
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par }
------=_NextPart_0001_089BE004--

shinji
Fri Aug 12 09:31:19 CDT 2005

Thank you for your reply.

if I get a machine,
I will debug it.


""Martin Borve [MSFT]"" <martinbo@online.microsoft.com> wrote in message
news:kwgx9DtnFHA.3120@TK2MSFTNGXA01.phx.gbl...
> Off-hand I don't see why submitting an idle notification IRP would
> interfere with going into standby. You will probably need to get a
> machine
> that you can repro this behavior on and debug it.
>
>
> Martin Borve
> Windows DDK Support
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

shinji
Thu Sep 08 09:19:17 CDT 2005

I get the machine.

When the machine went into stanby,
our capture driver didn't receive requests at all,
IdleNotificationCallback complete routin did not called.

What prevented from completing of IdleNotificationCallback ?

I would like to investigate parent driver of our capture driver.
But I did not able to find "FILES A" from XP pro sp2 checked build ( network
install ).
I did not run the installer.
I unpacked "FILES A" from installer.

"FILES A" is tsbyuv.dll, usbd.sys, usbcamd2.dll.

Would you tel me where are checked build version of "FILES A" ?

Thanks in advance

""Martin Borve [MSFT]"" <martinbo@online.microsoft.com> wrote in message
news:kwgx9DtnFHA.3120@TK2MSFTNGXA01.phx.gbl...
> Off-hand I don't see why submitting an idle notification IRP would
> interfere with going into standby. You will probably need to get a
> machine
> that you can repro this behavior on and debug it.
>
>
> Martin Borve
> Windows DDK Support
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

shinji
Fri Sep 09 04:10:19 CDT 2005

I was able to find FILES A" from "XP pro la checked/build".

When a PC ( can suspend ) went into standby,
Function (A) can return.

When a PC ( can not suspend ) went into standby,
Function (A) can not return.

powerState.DeviceState = PowerDeviceD2;
KeInitializeEvent(&irpCompletionEvent, NotificationEvent, FALSE);
irpContext->pDC = pDC;
irpContext->Event = &irpCompletionEvent;
SSDbgPrint(3, ("PoRequestPowerIrp to PwrLev=%d\n",
powerState.DeviceState ));
ntStatus = PoRequestPowerIrp(
....
IRP_MN_SET_POWER,
powerState,
(PREQUEST_POWER_COMPLETE) PoIrpCompletionFunc,
irpContext,
NULL);
if(STATUS_PENDING == ntStatus) {
SSDbgPrint(3, ("IdleNotificationCallback::"
"waiting for the power irp to complete\n"));
KeWaitForSingleObject(&irpCompletionEvent, //
....................(A)
Executive,
KernelMode,
FALSE,
NULL);
SSDbgPrint(3, ("IdleNotificationCallback::"
" the power irp to completed\n"));
}


"shinji wata" <watashin@mvision.co.jp> wrote in message
news:OXEoOBItFHA.3236@TK2MSFTNGP09.phx.gbl...
>I get the machine.
>
> When the machine went into stanby,
> our capture driver didn't receive requests at all,
> IdleNotificationCallback complete routin did not called.
>
> What prevented from completing of IdleNotificationCallback ?
>
> I would like to investigate parent driver of our capture driver.
> But I did not able to find "FILES A" from XP pro sp2 checked build (
> network install ).
> I did not run the installer.
> I unpacked "FILES A" from installer.
>
> "FILES A" is tsbyuv.dll, usbd.sys, usbcamd2.dll.
>
> Would you tel me where are checked build version of "FILES A" ?
>
> Thanks in advance
>
> ""Martin Borve [MSFT]"" <martinbo@online.microsoft.com> wrote in message
> news:kwgx9DtnFHA.3120@TK2MSFTNGXA01.phx.gbl...
>> Off-hand I don't see why submitting an idle notification IRP would
>> interfere with going into standby. You will probably need to get a
>> machine
>> that you can repro this behavior on and debug it.
>>
>>
>> Martin Borve
>> Windows DDK Support
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>

shinji
Fri Sep 09 20:14:05 CDT 2005

I'm sorry.
A part of my report was wrong.

When every PC( what I tested) went into standby,
Function (A) and Point (B) was passed.

When some PC went into standby completely,
PoIrpCompletionFunc was called.

When some PC didn't go into standby completely,
PoIrpCompletionFunc was not called.

Why CompletionFunction of PoRequestPowerIrp was not called ?

Thanks in Advance

shinji

> powerState.DeviceState = PowerDeviceD2;
> KeInitializeEvent(&irpCompletionEvent, NotificationEvent, FALSE);
> irpContext->pDC = pDC;
> irpContext->Event = &irpCompletionEvent;
> SSDbgPrint(3, ("PoRequestPowerIrp to PwrLev=%d\n",
> powerState.DeviceState ));
> ntStatus = PoRequestPowerIrp(
> ....
> IRP_MN_SET_POWER,
> powerState,
> (PREQUEST_POWER_COMPLETE) PoIrpCompletionFunc,
> irpContext,
> NULL);
> if(STATUS_PENDING == ntStatus) {
> SSDbgPrint(3, ("IdleNotificationCallback::"
> "waiting for the power irp to complete\n"));
> ....................(A)
> KeWaitForSingleObject(&irpCompletionEvent, // Executive,
> KernelMode,
> FALSE,
> NULL);
> SSDbgPrint(3, ("IdleNotificationCallback::"
> " the power irp to completed\n"));
......................(B)
> }



"shinji wata" <watashin@mvision.co.jp> wrote in message
news:e0SzQ5RtFHA.3528@TK2MSFTNGP15.phx.gbl...
>I was able to find FILES A" from "XP pro la checked/build".
>
> When a PC ( can suspend ) went into standby,
> Function (A) can return.
>
> When a PC ( can not suspend ) went into standby,
> Function (A) can not return.
>

shinji
Sun Sep 11 21:30:05 CDT 2005

I used DELL Latitude D600.

I used PoRegisterForIdelDetection instead of "Idle notification Request
IRP".
I was able to get our device D2 state by PoRegisterForIdelDetection.
But I was not able to go to C3 state.

I think PoRegisterForIdelDetection is not perfect for notebook.

I think I have to use "Idle notification Request IRP" to raise C3 time
percentage.


I would like to make clear my problem.
/////////////////////////////////////////
case of FMV-BIBLO NB75K

When our capture device is idle and go to stanby mode ,
the PC can be suspended completely.

/////////////////////////////////////////
case of DELL Latitude D600

When our capture device is idle and go to stanby mode ,
the PC can not be suspended completely.

Because when the PC go to stanby mode,
IdleNotificationRequestComplete was not callled.

When ControlCode is IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION and
IoCallDriver is almost called,
IdleNotificationRequestComplete is set by IoSetCopleteRoutine.


"shinji wata" <watashin@mvision.co.jp> wrote in message
news:%23py$zTatFHA.4080@TK2MSFTNGP12.phx.gbl...
> I'm sorry.
> A part of my report was wrong.
>
> When every PC( what I tested) went into standby,
> Function (A) and Point (B) was passed.
>
> When some PC went into standby completely,
> PoIrpCompletionFunc was called.
>
> When some PC didn't go into standby completely,
> PoIrpCompletionFunc was not called.
>
> Why CompletionFunction of PoRequestPowerIrp was not called ?
>
> Thanks in Advance
>
> shinji
>
>> powerState.DeviceState = PowerDeviceD2;
>> KeInitializeEvent(&irpCompletionEvent, NotificationEvent, FALSE);
>> irpContext->pDC = pDC;
>> irpContext->Event = &irpCompletionEvent;
>> SSDbgPrint(3, ("PoRequestPowerIrp to PwrLev=%d\n",
>> powerState.DeviceState ));
>> ntStatus = PoRequestPowerIrp(
>> ....
>> IRP_MN_SET_POWER,
>> powerState,
>> (PREQUEST_POWER_COMPLETE) PoIrpCompletionFunc,
>> irpContext,
>> NULL);
>> if(STATUS_PENDING == ntStatus) {
>> SSDbgPrint(3, ("IdleNotificationCallback::"
>> "waiting for the power irp to complete\n"));
>> ....................(A)
>> KeWaitForSingleObject(&irpCompletionEvent, // Executive,
>> KernelMode,
>> FALSE,
>> NULL);
>> SSDbgPrint(3, ("IdleNotificationCallback::"
>> " the power irp to completed\n"));
> ......................(B)
>> }
>
>
>
> "shinji wata" <watashin@mvision.co.jp> wrote in message
> news:e0SzQ5RtFHA.3528@TK2MSFTNGP15.phx.gbl...
>>I was able to find FILES A" from "XP pro la checked/build".
>>
>> When a PC ( can suspend ) went into standby,
>> Function (A) can return.
>>
>> When a PC ( can not suspend ) went into standby,
>> Function (A) can not return.
>>
>

shinji
Wed Sep 14 05:31:15 CDT 2005

I used WinDbg and checked build files of stream.sys.
When I plugged in our capture device in PC.
int 3 occured.

if I userd free build file of stream.sys,
int 3 didn't occure.

When int 3 occured,
WinDbg said following log.

SC: Allocate log buffer for 1024 entries
MvDevice:Driver Entry
MvDevice:Driver Entry return
'StreamClassInitialize: Adapter has no interrupt.
MvDevice:AdapterReceivePacket SRB_INITIALIZE_DEVICE
MvDevice:SRB_INITIALIZE_DEVICE
MvDevice:CamConfigureEx
MvDevice:CamConfigureEx end
MvDevice:CamInitialize start
MvDevice:CamInitialize end
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
804e5b14 cc int 3
kd> .reload
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
...............................................................................................................
Loading unloaded module list
....................
Loading User Symbols
kd> g
'ScCallback: NOT calling back request - Irp = 81D953B0
MvDevice:SRB_INITIALIZE_DEVICE end


What is "NOT calling back request - Irp = 81D953B0" ?
What should I do to investigate more ?

Thanks in advance

regards

Shinji

""Martin Borve [MSFT]"" <martinbo@online.microsoft.com> wrote in message
news:kwgx9DtnFHA.3120@TK2MSFTNGXA01.phx.gbl...
> Off-hand I don't see why submitting an idle notification IRP would
> interfere with going into standby. You will probably need to get a
> machine
> that you can repro this behavior on and debug it.
>
>
> Martin Borve
> Windows DDK Support
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

martinbo
Mon Sep 19 15:59:17 CDT 2005

------=_NextPart_0001_D0CD1496
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

For a USB device, using PoRegisterForIdleDetection will not have the effect
of putting the USB host controller into a lower D-state, which is what is
normally required for the processor to enter C3. For this you must use
IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION.

Martin Borve
Windows DDK Support
This posting is provided "AS IS" with no warranties, and confers no rights.



------=_NextPart_0001_D0CD1496
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 For a USB device, using PoRegisterForIdleDetection will not have the effect of putting the USB host controller into a lower D-state, which is what is normally required for the processor to enter C3. For this you must use IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION.
\par
\par Martin Borve
\par Windows DDK Support
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par
\par
\par }
------=_NextPart_0001_D0CD1496--