Sometimes during a long sequence of dma requests a custom DeviceIoControl that access a amcc5335 pci board do not return after wdfrequestcompletewithinformation.
Ioctl and dma operation have two separate sequential dispatching ioqueues. All the driver is serialized to reduce complexity since is not a issue with performance and features.
The getioqueuestatus after completion return 0 queued request and 0 dispatched. Once triggered the dma is still working.
Once paused the user space sw I can see that the output buffer is correctly written.
There is a way to intercept the path between completion and deviceiocontrol return to see where it stops?
On Oct 8, 2014, at 12:05 PM, xxxxx@hotmail.com wrote:
Sometimes during a long sequence of dma requests a custom DeviceIoControl that access a amcc5335 pci board do not return after wdfrequestcompletewithinformation.
Ioctl and dma operation have two separate sequential dispatching ioqueues.
That?s irrelevant here. Once you have begun processing, the fact that it came from a queue doesn?t matter.
All the driver is serialized to reduce complexity since is not a issue with performance and features.
I don?t think you have established that yet.
Are there filter drivers above you in the driver stack? The request cannot be returned to user mode until all drivers have completed it. After you call WdfRequestComplete, it doesn?t matter what your driver does. The request is out of your control
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks for the answer Tim.
Every ioctl are just a read or a write register into a memory mapped Bar of the board, I’ve checked trough traceview that this operation is successful, if it is a read I copy in the output buffer the value and then I complete. Could be a timing issue? It happen only on heavy load.
I converted the read register DeviceIoControl to overlapped mode with event, and now magically everythings work, I tested on a long acquisition run (500GB) and never stucked.
Could be a wdf bug?
xxxxx@hotmail.com wrote:
I converted the read register DeviceIoControl to overlapped mode with event, and now magically everythings work, I tested on a long acquisition run (500GB) and never stucked.
Could be a wdf bug?
No. That’s all handled by I/O manager, above the level of your driver.
Individual drivers don’t even know whether overlapped I/O is being used.
You do understand that, if you are not using overlapped I/O, then you
can only have one request at a time on a file handle, no matter how many
threads you are running?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
No, not a wdf bug. Your bug.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, October 9, 2014 10:46 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DeviceIoControl not returning after wdfrequestcomplete
I converted the read register DeviceIoControl to overlapped mode with event, and now magically everythings work, I tested on a long acquisition run (500GB) and never stucked.
Could be a wdf bug?
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
On 09-Oct-2014 20:45, xxxxx@hotmail.com wrote:
I converted the read register DeviceIoControl to overlapped mode with event, and now magically everythings work, I tested on a long acquisition run (500GB) and never stucked.
Could be a wdf bug?
Nope, then it looks like a bug in your usermode app.
– pa
my user space sw, has two thread that do overlapped read request and one more that do some deviceIoControl to read the status registers of the board. If the DeviceIoControl are not overlapped it is normal what i’m seeing?
So it was the user space sw bugged all this time seem.
xxxxx@hotmail.com wrote:
my user space sw, has two thread that do overlapped read request and one more that do some deviceIoControl to read the status registers of the board. If the DeviceIoControl are not overlapped it is normal what i’m seeing?
If the file handle is opened as overlapped, then all I/O requests to
that handle must use overlapped I/O. Some people have tried to sneak
some non-overlapped requests down an overlapped handle, and because it
doesn’t crash, they think it’s proper. (It DID crash on Windows 95/98.)
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.