Hi all
We have developed a PCIe device and use Wdf DMA framework to send data to it. However we found sometimes one transfer can not send all of data to our device in a long time. Thus we have to write a timer in device to handle DMA transfer time out. My question is whether this kind of data lose is reasonable? I didn’t find any WDF DMA interface to check whether there are any errors in last transfer. If the answer is NO, could you show me any advice where the bug possibly comes from.
Thanks for any suggestion.
>However we found sometimes one transfer can not send all of data to our device in a long time.
Do you see PCIe transaction timeout?
xxxxx@sina.com wrote:
We have developed a PCIe device and use Wdf DMA framework to send data to it. However we found sometimes one transfer can not send all of data to our device in a long time. Thus we have to write a timer in device to handle DMA transfer time out. My question is whether this kind of data lose is reasonable? I didn’t find any WDF DMA interface to check whether there are any errors in last transfer. If the answer is NO, could you show me any advice where the bug possibly comes from.
There is no possible way for KMDF to know whether a DMA operation
completed. It relies completely on your callbacks to provide that
information, because only you know how your hardware responds. Your
hardware will fire an interrupt when the transfer is completed, and your
ISR will tell KMDF how many bytes were transferred.
One way you can get in trouble is if your ISR assumes it will never get
another completion while it is handling the first one.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hello Alex
Do you see PCIe transaction timeout?
Yes, we saw transaction timeout. Then We rely on device to detect the timeout and fire the signal.
Hello Tim
Thanks for your reply.
There is no possible way for KMDF to know whether a DMA operation completed. It relies completely on your callbacks to provide that information, because only you know how your hardware responds.
Thanks, I see. If DMA lost data KMDF does not responsible for it even doesn’t know it. I am wondering whether the data loose is a driver bug or a normal case. Shall I find where it comes from, or just let device and driver tolerant it.
Your hardware will fire an interrupt when the transfer is completed, and your ISR will tell KMDF how many bytes were transferred.
When device detected timeout, then it will fire the interrupt before received all of content. Then in EvtInterruptDpc, the WdfDmaTransactionGetCurrentDmaTransferLength always returns zero. I think it should return the size of data which has been transferred before timeout is detected.
One way you can get in trouble is if your ISR assumes it will never get another completion while it is handling the first one.
Why? Could you tell me more? The MS DMA document said “if WdfDmaTransactionExecute determines that multiple DMA transfers are necessary to fulfill the DMA transaction, the framework performs these transfer serially” So we should not get another transfer before the last transfer is completed.
Thanks
>WdfDmaTransactionGetCurrentDmaTransferLength always returns zero
How do you think kmdf (magically) would know how many bytes have transferred without your driver updating the transaction state? Read http://msdn.microsoft.com/en-us/library/windows/hardware/ff547039(v=vs.85).aspx
d
Bent from my phone
From: xxxxx@sina.commailto:xxxxx
Sent: ?10/?21/?2013 5:29 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Wdf DMA may lose some data
Hello Tim
Thanks for your reply.
> There is no possible way for KMDF to know whether a DMA operation completed. It relies completely on your callbacks to provide that information, because only you know how your hardware responds.
Thanks, I see. If DMA lost data KMDF does not responsible for it even doesn’t know it. I am wondering whether the data loose is a driver bug or a normal case. Shall I find where it comes from, or just let device and driver tolerant it.
> Your hardware will fire an interrupt when the transfer is completed, and your ISR will tell KMDF how many bytes were transferred.
When device detected timeout, then it will fire the interrupt before received all of content. Then in EvtInterruptDpc, the WdfDmaTransactionGetCurrentDmaTransferLength always returns zero. I think it should return the size of data which has been transferred before timeout is detected.
> One way you can get in trouble is if your ISR assumes it will never get another completion while it is handling the first one.
Why? Could you tell me more? The MS DMA document said “if WdfDmaTransactionExecute determines that multiple DMA transfers are necessary to fulfill the DMA transaction, the framework performs these transfer serially” So we should not get another transfer before the last transfer is completed.
Thanks
—
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</mailto:xxxxx></mailto:xxxxx>
xxxxx@sina.com wrote:
> There is no possible way for KMDF to know whether a DMA operation completed. It relies completely on your callbacks to provide that information, because only you know how your hardware responds.
Thanks, I see. If DMA lost data KMDF does not responsible for it even doesn’t know it. I am wondering whether the data loose is a driver bug or a normal case. Shall I find where it comes from, or just let device and driver tolerant it.
DMA data loss is NOT a normal condition. It is a problem in your hardware.
When device detected timeout, then it will fire the interrupt before received all of content. Then in EvtInterruptDpc, the WdfDmaTransactionGetCurrentDmaTransferLength always returns zero. I think it should return the size of data which has been transferred before timeout is detected.
KMDF doesn’t know that. It CAN’T know that. Please remember, YOUR
HARDWARE is in complete control of the DMA transfer. You are the “bus
master”. If the transfer timed out, it timed out because your hardware
stopped transferring. That’s a problem you need to solve.
> One way you can get in trouble is if your ISR assumes it will never get another completion while it is handling the first one.
Why? Could you tell me more? The MS DMA document said “if WdfDmaTransactionExecute determines that multiple DMA transfers are necessary to fulfill the DMA transaction, the framework performs these transfer serially” So we should not get another transfer before the last transfer is completed.
It depends on the hardware. Some hardware interrupts in the middle of a
transfer to indicate progress.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Doron
How do you think kmdf (magically) would know how many bytes have transferred without your driver updating the transaction state?
I guess there may be some internal DMA error checking mechanism in KMDF framework. Now I know there is NOT such things.
Hello Tim
DMA data loss is NOT a normal condition. It is a problem in your hardware.
I think so. Currently we still rely on device to detect DMA timeout to bypass this error. We will try to diagnose it later. Thanks.
How would kmdf know there is an error? DMA is very device specific, kmdf is HW agnostic. Kmdf provides a data flow, not a data model
d
Bent from my phone
From: xxxxx@sina.commailto:xxxxx
Sent: ?10/?21/?2013 8:29 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Wdf DMA may lose some data
Doron
> How do you think kmdf (magically) would know how many bytes have transferred without your driver updating the transaction state?
I guess there may be some internal DMA error checking mechanism in KMDF framework. Now I know there is NOT such things.
—
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</mailto:xxxxx></mailto:xxxxx>