Hi all,
Just a short question ,i am developing a USB driver , and starting up continuous reader hooked up onto bulk in pipe.I set Numpendingreads = 1 ,for the reason that it is important for my driver receive data buffers in the exact order that device delivers the data. I started
up sending 10M bytes file from device to PC ,the whole data can be received in the exact order in Win XP .but with the same code was built in the Win 7 32 environment. I found the driver would lost data every time I am calling wdfiotargetstop() to stop reader with the ring buffer is full. I suspect that Numpendingreads did not take effect on Win 7 32 bit . it use the deafult value = 2,am i right ?
The one-request-at-a-time is OK for my device in Win XP 32 bit ,and Is there any difference in Win 7 32 from WDF side?
Any clues will be welcome! thanks in advance!
NumPendingReads == 1 on win7 works, if not, it is a bug. I am guessing that 1 reader is not enough to get the data off of the device before the device’s buffer is overflowed.
d
>>NumPendingReads == 1 on win7 works, if not, it is a bug. I am guessing that 1
>reader is not enough to get the data off of the device before the device’s
>buffer is overflowed.
Thanks Doron !
Do you have any advice to me ?
If setting Numpendingreads >1 will no guarantee of ordering , that will make problem more serious.
and additonal information,
>I am guessing that 1 reader is not enough to get the data off of the device before the device’s
>buffer is overflowed.
I don’t know if the device buffer is overflowed , But i suspect that is not the root cause .
only after wdfiotargetstop() is invoked, it lost exactly 1 data package. and during reader stopping ,
it does not lost data , after driver ring buffer is empty, i call wdfiotargetstart() to start reader ,it continue reading in right order(i.e. before wdfiotargetstop() i get package index 1, and after wdfiotargetstart() i get package index 3,4,5…)
On 12/20/2010 2:58 PM, xxxxx@hotmail.com wrote:
the whole data can be received in the exact order in Win XP
The USB bus is non-routed, so your driver will always get your data in
the exact order the device has sent it.
If you have more than one read thread in your application, and you don’t
use any timestamp or ordering counter there, your *application threads*
might get the data in the wrong order. But this is a completely
different problem.
Looks to me you are trying to solve a problem you don’t actually have.
>>Looks to me you are trying to solve a problem you don’t actually have.
Thanks Hagen,
Just make it clear, no matter what value the NumPendingReads is , the data is ordered .
this confused me that why would lost data . Is it matter with raising a spinlock ?
I process continuous reader compltetion like this :
1.print data
2.raise spinlock
3.push data into ring buffer
4.if there was a read request then fill the request buffer with ring buffer
5.if ring buffer full ,then stop reader
last release spinlock
I can see the detail data in the first step .and It shows the data is lost when i stop reader by invoked wdfiotargetstop().
while Evtbulkincomplete routine is called at DISPATCH_LEVEL ,will spin lock take effect?
Could any one show me a feasible design in continuous reader ?
Best regards!
Hagen Patzke wrote:
If you have more than one read thread in your application,
and you don’t use any timestamp or ordering counter there,
your *application threads* might get the data in the wrong
order. But this is a completely different problem.
Doron has stated previously that a continuous reader with NumPendingReads > 1 does not guarantee in order delivery regardless of what your application is or is not doing. The rationale was that two URBs could be completed rapidly, thus the host controller fires two DPCs, and then the second of these is scheduled to execute first for some reason. Or something like that.
On 12/21/2010 4:22 PM, xxxxx@gmail.com wrote:
Doron has stated previously that a continuous reader with
NumPendingReads > 1 does not guarantee in order delivery regardless
of what your application is or is not doing.
My bad - dealing with WDM only. Thanks, Chris!
http://msdn.microsoft.com/en-us/library/ff560395(VS.85).aspx
states:
"Set NumPendingReads to one if it is important that your driver receive
data buffers in the exact order in which the device delivers the data.
If the framework queues more than one read request, the driver might not
receive the data buffers in same the order in which the device delivers
the data."
I’ll read up a bit on the Continuous Reader… if you get data buffers
in a different order BUT can sort them in the driver – because you also
get a count value or something – this should not be a problem.
Thanks, Chris and Hagen!
I thought this issue all night long ,
I would like to process continuous reader like this:
EvtbulkinCompletionRoutine:
IF (pending read request)
{
Fill with request buffer with WDFMEMORY
Complete request (concern cancel and timeout)
}
ELSE
Reference WDFMEMORY and put it into List_Entry
I should not to try to stop reader any more, should I ? for the problem is generated while i am stopping the reader . and this pattern can avoid the problem.
If i take this pattern .some quesion confused me ,
-
Does List_entry have the limitation like Max number of member? will the List entry consumes a lot of memory ?
2.If there is a quantity of data from reader .and I keep all of the WDFMEMORY for a longer lifetime ,will it bring down the efficiency ? As i know i reference WDFMEMORY (I will not to allocate new buffer to keep it ) this would be better to my driver ,but how about with lower driver who generated the WDFMEMORY ?
-
If i keep so many WDFMEMORYs ,will the lower driver(or framework) failed to create a new WDFMEMORY or failed the NumPendingReads request inside the reader?
I think i recommended that you don’t stop the reader in this scenario at the start of this question.
-
no, LIST_ENTRY is a doubly linked list. its only upper limit is the amount of free memory that is available on the machine
-
yes and no. you should not store an unlimited number of WDFMEMORYs and thus endlessly consume memory. Put an upper bound on the number you store (let’s say a 100 as an arbitrary number, it can probably be lower). There is no lower driver who generated the WDFMEMORY, KMDF allocated on behalf of your driver when it sent the IO down ths stack. the WDFMEMORY is yours.
-
it is possible that a new allocation for a WDFMEMORY will fail in the cont reader, but that can happen for any number of reasons, not just your driver holding on to a few WDFMEMORYs.
d
> 1. Does List_entry have the limitation like Max number of member?
No.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks Doron for your explict statement!
Thanks Maxim S!
And i will going on with this pattern !