what are the factors can lead a DMA failure ?

I am writing a WDF PCIE dirver under Win7 x64 refer to the PLX9x5x example. I just use the Packet-Based DMA, so I eliminate all the ingredient of Common-Buffer DMA design of the PLX9x5x. Then I launch a DMA operation in the Read IRP.
I have tested and verified the PCIE card on a XP system by write a dirver using DriverStudio.

But the DMA can’t not carry out. I am sure the regiters be opreated correctly in the WDF driver ,and the WDF framework structure is simply enough .
What are ohter factors can lead a DMA failure ?

What you mean by DMA failure?

The DMA can not start .

That’s STILL not much of a description. We don’t read minds Mr. CyberPunkerX. So, if you could be specific, we’d be more likely to be able to help you.

Are you not getting called-back at your EvtProgramDma Event Processing Callback? Or are you getting the callback, but the actual device not doing the DMA as you expect?

Peter
OSR
@OSRDrivers

xxxxx@gmail.com wrote:

I am writing a WDF PCIE dirver under Win7 x64 refer to the PLX9x5x example. I just use the Packet-Based DMA, so I eliminate all the ingredient of Common-Buffer DMA design of the PLX9x5x. Then I launch a DMA operation in the Read IRP.
I have tested and verified the PCIE card on a XP system by write a dirver using DriverStudio.

But the DMA can’t not carry out. I am sure the regiters be opreated correctly in the WDF driver ,and the WDF framework structure is simply enough .
What are ohter factors can lead a DMA failure ?

One of the common failures here is grabbing the wrong physical
addresses, so your DMA actually works but writes into random locations
in memory. Does your DMA engine handle 64-bit physical addresses?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I debug the source.

It does run into the EvtProgramDma routine.The DMA using the sglist->Elements[0].Address.LowPart as the physical addresses. The card just using 32-bit addresses.

After I had set the register to start a DMA , then I read the interrupt regeister , it shows no interrupt coming, and the ISR does not aroused . And the return value of the WdfDmaTransactionGetCurrentDmaTransferLenght( ) just the same as the sglist->Elements[0].Address.Length. It seems the DMA does not run .

The only possible answer is: You are not correctly programming your hardware. I realize that you have asserted that you’re programming the hardware correctly, but if the hardware is t doing what you expect, then the only answer is that you’re programming your hardware wrong.

Peter
OSR
@OSRDrivers

You cannot use WdfDmaTransactionGetCurrentDmaTransferLenght for bus master devices.

And you should be telling your DMA object that your hardware only supports 32 bit address (seriously, who’s doing that anymore? it year 2015, FFS).

xxxxx@gmail.com wrote:

It does run into the EvtProgramDma routine.The DMA using the sglist->Elements[0].Address.LowPart as the physical addresses. The card just using 32-bit addresses.

And did you, in fact, tell the system that your hardware is crippled and
only supports 32-bit physical addresses? Have you verified that that
Address.HighPart is 0?

After I had set the register to start a DMA , then I read the interrupt regeister , it shows no interrupt coming, and the ISR does not aroused.

As Peter said, that’s a pretty good indication that the hardware is not
setup properly. The hardware doesn’t know whether the addresses are
reasonable.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

If you have a bus-mastering device, Windows doesn’t do any actual DMA for you. It just moves data into buffers your device can reach.

If the device indicated an interrupt in its registers but the ISR wasn’t invoked I might think it was a resource configuration problem.

But since the device’s registers don’t indicate that a DMA is running or complete, it’s most likely that cyberpunkerex incorrectly programmed the device somewhere.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, February 9, 2016 9:31 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] what are the factors can lead a DMA failure ?

xxxxx@gmail.com wrote:
> It does run into the EvtProgramDma routine.The DMA using the sglist->Elements[0].Address.LowPart as the physical addresses. The card just using 32-bit addresses.

And did you, in fact, tell the system that your hardware is crippled and only supports 32-bit physical addresses? Have you verified that that Address.HighPart is 0?

> After I had set the register to start a DMA , then I read the interrupt regeister , it shows no interrupt coming, and the ISR does not aroused.

As Peter said, that’s a pretty good indication that the hardware is not setup properly. The hardware doesn’t know whether the addresses are reasonable.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

> After I had set the register to start a DMA

Carefully manually inspect all your common buffer physical memory at this moment of time, after setting a debugger breakpoint. Ensure that all of your scatter-gather list is correct.

You can have an absolutely primitive bug in your logic which forms the SGLs, which often arises since humans are not perfect, and thus have not 100% attention.

Such a primitive bug (off by 1 or such) can cause exactly the picture you see. The HW just behaves as garbage-in->garbage-out.

The bug can be trivial to fix, but not-trivial-at-all to find.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Thanks for your suggestion.

In the DMA initializaion routine,there are only two parameteres should set . I did like this:

WdfDeviceSetAlignmentRequirement( Device, FILE_BYTE_ALIGNMENT );

// Create a new DMA Enabler instance.
WDF_DMA_ENABLER_CONFIG_INIT( &dmaConfig,
WdfDmaProfilePacket,
MAXNLEN );

Then , in the EvtProgramDma Event Processing Callback routine. The sglist->Elements[0].Address.LowPart is given to the hardware register . sglist->Elements[0].Address.HighPart is ZERO.

I am sure the operation of the hardware register is correct.
I am a little crazy now .

How can I know if he hardware know whether the physical addresses are reasonable?

How to tell the system that your hardware is crippled and only supports 32-bit physical addresses unambiguously ?

xxxxx@gmail.com wrote:

In the DMA initializaion routine,there are only two parameteres should set . I did like this:

WdfDeviceSetAlignmentRequirement( Device, FILE_BYTE_ALIGNMENT );
// Create a new DMA Enabler instance.
WDF_DMA_ENABLER_CONFIG_INIT( &dmaConfig,
WdfDmaProfilePacket,
MAXNLEN );

Then , in the EvtProgramDma Event Processing Callback routine. The sglist->Elements[0].Address.LowPart is given to the hardware register . sglist->Elements[0].Address.HighPart is ZERO.
How to tell the system that your hardware is crippled and only supports 32-bit physical addresses unambiguously ?

WdfDmaProfilePacket does that. If you supported 64-bit addresses, you’d
ise WdfDmaProfilePacket64. Are you quite sure your DMA engine supports
arbitrary byte alignment? Most DMA engines have alignment limitations.

I am sure the operation of the hardware register is correct.
I am a little crazy now .

Remember that the operating system is not involved here. The kernel
gave you a physical address, but that’s the end of its involvement.
There are no other players – it’s just you and your hardware. If the
DMA is not running, then you are not setting up the hardware correctly.
It’s as simple as that. Some hardware requires that the DMA engine be
enabled at initialization time. Are you doing anything like that?

You should even be able to simulate this action in the debugger by
writing the registers individually. If that doesn’t trigger a DMA, then
your DMA engine is not set up properly.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim ? I have tried all the FILE_xxxx_ALIGNMENT options, None can arouse the ISR .

The operation of the hardware’s register is excatly the same as the demo in WinXP by the DriverStudio .

I meet my wit’s end now.

The demo which made by the DriverStudio runs well in WinXP on the same PC .
So , the harrdware platform is verified.

Three days ago I gave you the answer. I’m sorry it’s not the answer you want, but it’s got to be the right answer:

Peter
OSR
@OSRDrivers

Will the ISR kee checking the interrupt in WDF ?
When I restart the PC after installing the driver , the ISR is keeping running. In my memory, this does not happened in the WDM era.

But ,the DMA interrupt never comes .

There’s no “checking”… the interrupt occurs through an IDT entry. The kernel dispatches the interrupt via a KINTERRUPT. The ISR is called. That’s all that happens. The only difference between WDM and WDF is there’s one added level of indirection in WDF (KINTERRUPT to interrupt dispatcher to ISR in WDM versus KINTERRUPT to interrupt dispatcher to WDF to ISR in WDF).

If the DMA interrupt doesn’t occur, that means either that your ISR isn’t connected to the interrupt (WdfInterruptCreate wasn’t done or done correctly… something worth checking that only occurred to me right now) or the hardware isn’t generating the interrupt. That is the entire universe of the problem space.

There’s no magic between your hardware and your ISR that Windows or WDM or WDF mediates, as I explained above.

I’m sorry, but seriously… that’s all there is to it.

Peter
OSR
@OSRDrivers

Are you using an actual PLX PCI9x5x? I use a custom board with a 9056 and
it’s not very different from 9054 or 9656. If you can share your code
where you are actually setting the DMA registers (DMAMODE, DMADPR, DMACSR)
I can sanity check it. Also, have you made sure the interrupt is enabled
in the INTCSR (bit 18 for channel 0 and bit 19 for channel 1)? You must
enable it there in addition to DMAMODE bit 17.

  • Phil

On Fri, Feb 12, 2016 at 8:56 AM, wrote:

>


>
> There’s no “checking”… the interrupt occurs through an IDT entry. The
> kernel dispatches the interrupt via a KINTERRUPT. The ISR is called.
> That’s all that happens. The only difference between WDM and WDF is
> there’s one added level of indirection in WDF (KINTERRUPT to interrupt
> dispatcher to ISR in WDM versus KINTERRUPT to interrupt dispatcher to WDF
> to ISR in WDF).
>
> If the DMA interrupt doesn’t occur, that means either that your ISR isn’t
> connected to the interrupt (WdfInterruptCreate wasn’t done or done
> correctly… something worth checking that only occurred to me right now)
> or the hardware isn’t generating the interrupt. That is the entire
> universe of the problem space.
>
> There’s no magic between your hardware and your ISR that Windows or WDM or
> WDF mediates, as I explained above.
>
> I’m sorry, but seriously… that’s all there is to it.
>
> Peter
> OSR
> @OSRDrivers
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>