KMDF driver METHOD_NEITHER and high CPU usage questions
in [Device Drivers]
|
Prev: Any wifi / bluetooth keyboard / mouse receiver driver source c
Next: Removing standard Unidrv property sheets from printer preferences/properties
From: gti4ever on 18 Jan 2010 04:22 Tim, We were using UVC driver before. What I am doing now is trying to create a new UMDF/KMDF hybrid driver to experimenting some of the features that we plan to move down to driver level. G. "Tim Roberts" wrote: > gti4ever <gti4ever(a)discussions.microsoft.com> wrote: > > > >I am trying to port an old video straming WDM driver into a new KMDF driver > >and I have been struggling with the following problems. > > Is there a reason you don't just write this as an AVStream driver? That > way, you inherit a whole bunch of known-good streaming behavior, and it > lets you use the driver from standard DirectShow apps. > -- > Tim Roberts, timr(a)probo.com > Providenza & Boekelheide, Inc. > . >
From: gti4ever on 18 Jan 2010 04:29 Hi Doron, Following statement is from MSDN regarding WdfRequestProbeAndLockUserBufferForWrite(): "The user-mode buffer that the Buffer parameter specifies can be the buffer that WdfRequestRetrieveUnsafeUserOutputBuffer retrieves, or it can be a different user-mode output buffer. For example, an I/O control code that uses the buffered access method might pass a structure that contains an embedded pointer to a user-mode buffer. In such a case, the driver can use WdfRequestProbeAndLockUserBufferForWrite to obtain a memory object for the buffer. " So WdfRequestProbeAndLockUserBufferForWrite() can be used for METHOD_BUFFERED and METHOD_NEITHER, but how about METHOD_OUT_DIRECT? I kept getting bug check if I try to call that function with METHOD_OUT_DIRECT. G. "Doron Holan [MSFT]" wrote: > are you probing and locking the embedded pointer value (by calling > WdfRequestProbeAndLockUserBufferForRead/Write) in EvtIoInCallerContext or in > an EvtIoDeviceIoControl or EvtIoDefault routine? you must be in the correct > process context to probe and lock and only EvtIoInCallerContext is > guaranteed to be in the process's context. EvtIoDeviceIoControl and > EvtIoDefault do not have such a guarantee which is probably why you are > seeing the occassional bluescreen (based on the guess that this is where you > are touching the embedded pointer) > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > >
From: Doron Holan [MSFT] on 18 Jan 2010 12:42 which buffer are you passing to probe and lock? the pointer embedded in the input or output buffer? or the caller's input/output buffer pointer itself? -- This posting is provided "AS IS" with no warranties, and confers no rights. "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message news:C78DD202-5CAB-40AF-8D3B-E2CB1498D414(a)microsoft.com... > Hi Doron, > > Following statement is from MSDN regarding > WdfRequestProbeAndLockUserBufferForWrite(): > > "The user-mode buffer that the Buffer parameter specifies can be the > buffer > that WdfRequestRetrieveUnsafeUserOutputBuffer retrieves, or it can be a > different user-mode output buffer. For example, an I/O control code that > uses > the buffered access method might pass a structure that contains an > embedded > pointer to a user-mode buffer. In such a case, the driver can use > WdfRequestProbeAndLockUserBufferForWrite to obtain a memory object for the > buffer. " > > So WdfRequestProbeAndLockUserBufferForWrite() can be used for > METHOD_BUFFERED and METHOD_NEITHER, but how about METHOD_OUT_DIRECT? I > kept > getting bug check if I try to call that function with METHOD_OUT_DIRECT. > > G. > > "Doron Holan [MSFT]" wrote: > >> are you probing and locking the embedded pointer value (by calling >> WdfRequestProbeAndLockUserBufferForRead/Write) in EvtIoInCallerContext or >> in >> an EvtIoDeviceIoControl or EvtIoDefault routine? you must be in the >> correct >> process context to probe and lock and only EvtIoInCallerContext is >> guaranteed to be in the process's context. EvtIoDeviceIoControl and >> EvtIoDefault do not have such a guarantee which is probably why you are >> seeing the occassional bluescreen (based on the guess that this is where >> you >> are touching the embedded pointer) >> >> d >> >> -- >> >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >> >
From: gti4ever on 18 Jan 2010 19:48
Doron, You are right again. I used the wrong buffer. I should have probed and locked the embedded pointers instead of the input/output buffer. Now WdfRequestProbeAndLockUserBufferForRead/Write is working. But still, without using METHOD_NEITHER and probe and lock in EvtIoInCallerContext, I am still getting out of context embedded pointers sometimes. Guess I really have to push for the design change to get rid of the embedded pointers. Thanks a lot. G. "Doron Holan [MSFT]" wrote: > which buffer are you passing to probe and lock? the pointer embedded in the > input or output buffer? or the caller's input/output buffer pointer itself? > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > |