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 15 Jan 2010 13:20 Hi all the WDF gurus, 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. 1. The client apps use DeviceIoControl to read a video frame back from the device. The input and output buffer is the same structure with a pointer inside points to a 64K user buffer. In this case, should I use METHOD_NEITHER or METHOD_OUT_DIRECT? The old WDM code use METHOD_OUT_DIRECT, but if I use METHOD_OUT_DIRECT in the KMDF driver, occasionally I got BSOD when trying to write to that 64K buffer. 2. Can I use METHOD_NEITHER even if all the existing client apps is calling DeviceIoControl with METHOD_OUT_DIRECT? Will I still be able to use WdfRequestRetrieveUnsafeUserInputBuffer and WdfRequestProbeAndLockUserBufferForRead to make it safe? 3. I have noticed that when client app calls this DeviceIoControl repeatedly, the CPU usage jump to almost 50% (old WDM driver only use 4%) on a dual core system. I tried commenting out all the code in the DeviceIOControl and only left a 100 ms delay in it and the CPU usage is still 50%. Correct me if I am wrong, but it seems to me by passing a structure with a pointer inside, the framework consumes a lot of CPU cycles. Could it be because the wrong IO method I used? Thanks. G.
From: Don Burn on 15 Jan 2010 13:29 You should get rid of the pointer in the structure if at all possible, this is a great way to cause problems. You do not give the BSOD data, but I suspect that you are having a context change and the reference to the buffer is not referring to the correct processes data. As far as your questions, if possible avoid METHOD_NEITHER it is a great way to create problems. No you cannot change the IOCTL's buffering unless you change all the client applications. The framework does add overhead, but your numbers are excessive, I think we need to know more. -- Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr Remove StopSpam to reply "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message news:1150D89F-865A-45EA-8092-7A1797F4C8D2(a)microsoft.com... > Hi all the WDF gurus, > > 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. > > 1. The client apps use DeviceIoControl to read a video frame back from the > device. The input and output buffer is the same structure with a pointer > inside points to a 64K user buffer. In this case, should I use > METHOD_NEITHER > or METHOD_OUT_DIRECT? The old WDM code use METHOD_OUT_DIRECT, but if I use > METHOD_OUT_DIRECT in the KMDF driver, occasionally I got BSOD when trying > to > write to that 64K buffer. > > 2. Can I use METHOD_NEITHER even if all the existing client apps is > calling > DeviceIoControl with METHOD_OUT_DIRECT? Will I still be able to use > WdfRequestRetrieveUnsafeUserInputBuffer and > WdfRequestProbeAndLockUserBufferForRead to make it safe? > > 3. I have noticed that when client app calls this DeviceIoControl > repeatedly, the CPU usage jump to almost 50% (old WDM driver only use 4%) > on > a dual core system. I tried commenting out all the code in the > DeviceIOControl and only left a 100 ms delay in it and the CPU usage is > still > 50%. Correct me if I am wrong, but it seems to me by passing a structure > with > a pointer inside, the framework consumes a lot of CPU cycles. Could it be > because the wrong IO method I used? > > Thanks. > > G. > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4775 (20100115) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4775 (20100115) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
From: Doron Holan [MSFT] on 15 Jan 2010 13:50 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. "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message news:1150D89F-865A-45EA-8092-7A1797F4C8D2(a)microsoft.com... > Hi all the WDF gurus, > > 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. > > 1. The client apps use DeviceIoControl to read a video frame back from the > device. The input and output buffer is the same structure with a pointer > inside points to a 64K user buffer. In this case, should I use > METHOD_NEITHER > or METHOD_OUT_DIRECT? The old WDM code use METHOD_OUT_DIRECT, but if I use > METHOD_OUT_DIRECT in the KMDF driver, occasionally I got BSOD when trying > to > write to that 64K buffer. > > 2. Can I use METHOD_NEITHER even if all the existing client apps is > calling > DeviceIoControl with METHOD_OUT_DIRECT? Will I still be able to use > WdfRequestRetrieveUnsafeUserInputBuffer and > WdfRequestProbeAndLockUserBufferForRead to make it safe? > > 3. I have noticed that when client app calls this DeviceIoControl > repeatedly, the CPU usage jump to almost 50% (old WDM driver only use 4%) > on > a dual core system. I tried commenting out all the code in the > DeviceIOControl and only left a 100 ms delay in it and the CPU usage is > still > 50%. Correct me if I am wrong, but it seems to me by passing a structure > with > a pointer inside, the framework consumes a lot of CPU cycles. Could it be > because the wrong IO method I used? > > Thanks. > > G.
From: gti4ever on 15 Jan 2010 15:06 Now I am doing lock and probe in the EvtIoInCallerContext and I will see if this makes any improvement with my new METHOD_NEITHER test app. Back to my original question. What will be the shortcoming if I have no choice but to stay with METHOD_OUT_DIRECT? It seems to me WDF can still handle the embedded pointer using direct IO. 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. > > > "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message > news:1150D89F-865A-45EA-8092-7A1797F4C8D2(a)microsoft.com... > > Hi all the WDF gurus, > > > > 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. > > > > 1. The client apps use DeviceIoControl to read a video frame back from the > > device. The input and output buffer is the same structure with a pointer > > inside points to a 64K user buffer. In this case, should I use > > METHOD_NEITHER > > or METHOD_OUT_DIRECT? The old WDM code use METHOD_OUT_DIRECT, but if I use > > METHOD_OUT_DIRECT in the KMDF driver, occasionally I got BSOD when trying > > to > > write to that 64K buffer. > > > > 2. Can I use METHOD_NEITHER even if all the existing client apps is > > calling > > DeviceIoControl with METHOD_OUT_DIRECT? Will I still be able to use > > WdfRequestRetrieveUnsafeUserInputBuffer and > > WdfRequestProbeAndLockUserBufferForRead to make it safe? > > > > 3. I have noticed that when client app calls this DeviceIoControl > > repeatedly, the CPU usage jump to almost 50% (old WDM driver only use 4%) > > on > > a dual core system. I tried commenting out all the code in the > > DeviceIOControl and only left a 100 ms delay in it and the CPU usage is > > still > > 50%. Correct me if I am wrong, but it seems to me by passing a structure > > with > > a pointer inside, the framework consumes a lot of CPU cycles. Could it be > > because the wrong IO method I used? > > > > Thanks. > > > > G. > > . >
From: Tim Roberts on 16 Jan 2010 20:55
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. |