I’ve developed a KMDF USB driver and I have implemented a continuous reader on a bulk endpoint. The size of the data transfer ranges from a few hundred thousand bytes to several megabytes. I’ve configured the reader with a transfer length of 4k and 0 for the number of readers.
Now to the problem: If I interrupt the transfer before it is completed, occassionally on subsequent transfers I get more data than I was anticipating. After monitoring various hardware control lines in my device, it appears that the hardware is transferring the proper number of bytes.
Since the extra bytes is always a multiple of 512, the maximum packet size for high speed bulk endpoints, I’m speculating that an amount of data less than 4K has already reached the active buffer in the continuous reader. So when I start the transfer again, this buffer contains old data as well as the new data being transferred.
Ok, so my question is this: Is there a way to abort or cancel the current read without effecting the other pended reads?
Your assumption about the buffer containing both old and new data is not correct. The c.r. will reallocate a buffer each time it completes the request back to your driver (through a lookaside list). Now the lookaside alloc could return the same buffer as a previous read, but the number of bytes returned will not include the old number of bytes. How are you determining that the buffer contains old and new data? Inspecting the buffer itself? Or are you also looking at the number of bytes returned to look at the data?
Now, what you describe could be happening in the usb core, but I doubt that as well since this would manifest itself in many other drivers and I have not heard of this happening before.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@piacton.com
Sent: Thursday, December 18, 2008 12:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB Continuous Reader question
I’ve developed a KMDF USB driver and I have implemented a continuous reader on a bulk endpoint. The size of the data transfer ranges from a few hundred thousand bytes to several megabytes. I’ve configured the reader with a transfer length of 4k and 0 for the number of readers.
Now to the problem: If I interrupt the transfer before it is completed, occassionally on subsequent transfers I get more data than I was anticipating. After monitoring various hardware control lines in my device, it appears that the hardware is transferring the proper number of bytes.
Since the extra bytes is always a multiple of 512, the maximum packet size for high speed bulk endpoints, I’m speculating that an amount of data less than 4K has already reached the active buffer in the continuous reader. So when I start the transfer again, this buffer contains old data as well as the new data being transferred.
Ok, so my question is this: Is there a way to abort or cancel the current read without effecting the other pended reads?
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, December 18, 2008 9:58 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] USB Continuous Reader question
Now, what you describe could be happening in the usb core,
but I doubt that as well since this would manifest itself in
many other drivers and I have not heard of this happening before.
I saw it and had to change our software to avoid issues. It occurs when
multiple URBs are queued and cancelled before device stops generating
data (i.e. answers bulk-in or interrupt-in requests). When the next
transfer is started, one bulk packet from previous transfer can be
received as the first one. It was necessary to use dummy read before
starting transfer which reads out stale data.
I’m not quite sure if it occurs with OS drivers only, it is long time
before I fixed it. It for sure occured with VMware when our software was
running inside VM.
"The c.r. will reallocate a buffer each time it completes the request
back to your driver (through a lookaside list). "
Doron,
I understand what you’re saying, but what if I set the reader buffer size to 4K and the source stops sending data before that buffer receives a full 4K. The transfer that was aborted doesn’t assert a PKTEND in the case of a transfer size not being a multiple of 512 because the transfer was aborted. However many packets of 512 were read by the reader, but if they don’t add up to 4K I shouldn’t expect that read to complete. Therefore I imagine there would still be data in the c.r. buffer when a new transfer starts.
I’ve developed a KMDF USB driver and I have implemented a continuous reader on a bulk endpoint. The size of the data transfer ranges from a few hundred thousand bytes to several megabytes. I’ve configured the reader with a transfer length of 4k and 0 for the number of readers.
Now to the problem: If I interrupt the transfer before it is completed, …
How are you interrupting the transfer? That phrase doesn’t have a
precise meaning in USB. Do you mean you forced the device to stop
sending, or you stopped the continuous reader, or you took some action
to abort the pipe from the host side?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sorry for the confusion. What I meant by that is that the source of the data stops transferring data to the PC.
I tried something else in the meantime. After aborting a lengthy transfer, I instructed the device to send 512 bytes at a time. The continuous reader signalled complete after the 5th transfer. This leads me to believe that after cancelling the previous transfer, there were still 1536 bytes in the 4K c.r. buffer. And after 5 additional 512 byte transfers, enough data( 4K ) was received to fire off the completion routine.
Sorry for the confusion. What I meant by that is that the source of the data stops transferring data to the PC.
I tried something else in the meantime. After aborting a lengthy transfer, I instructed the device to send 512 bytes at a time. The continuous reader signalled complete after the 5th transfer. This leads me to believe that after cancelling the previous transfer, there were still 1536 bytes in the 4K c.r. buffer. And after 5 additional 512 byte transfers, enough data( 4K ) was received to fire off the completion routine.
I’m still a little bit confused. There are no timeouts here, so the
continuous reader can’t tell the difference between 8x 512-byte packets
that are delivered within 125us, and 8x 512-byte packets that are spread
across 60 seconds. Or 60 minutes, for that matter. Time has no meaning
to the continuous reader. When your device stops transferring, that
doesn’t mean anything to the continuous reader. It will just break out
the knitting and mark time until more URBs complete, or you call
WdfIoTargetStop, or you abort the pipe.
Am I misunderstanding what you’re asking?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
What you just stated is the assumption that I had made. My question is this: After a lengthy transfer from a device has either completed or has been aborted, is there a way cancel only the current pending read? I would like for the c.r. to continue after that.
What you just stated is the assumption that I had made. My question is this: After a lengthy transfer from a device has either completed or has been aborted, is there a way cancel only the current pending read? I would like for the c.r. to continue after that.
Can’t you just call WdfIoTargetStop and then WdfIoTargetStart? Sure,
that invokes a certain amount of overhead, but since you’re doing this
specifically because you know there’s a gap in the data stream, that
shouldn’t matter.
Cautionary disclaimer: I have not yet used the KMDF continuous reader.
I work mostly with isochronous pipes, so I roll my own.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.