drive verifier makes DMA impossible

Dear all,

Im writing a WDM driver for a PCI device doing bus master packed based
DMA. The device and the driver are working well so far, until I followed
the suggestion of some experts to turn on driver verifier. OK, I did
that and ran into several problems (which actually was caused by my not
so correct code). The most ones I could solve but there was one I
couldn't get rid of: The DMA runs perfectly but the data are always
0x0E, no matter what was in my user buffer!
The device is not "scatter/gather-able" so I split up the DMA transfer
into several small one-page DMA transfers. The logical address
determined by MapTransfer() seemed to be NOT describing my user buffer.
When DMA checking of driver verifier is disabled the transfer works
perfect and the logical address determined by MapTransfer() is higher
(e.g. 0x0a2ed1f8), but I don't know if the address has anything to do
with that problem.

Thanks for help
Daniel

pavel_a
Wed Oct 13 13:45:03 CDT 2004

Is your system XP SP2? Which CPU? (AMD or Intel?)

--PA

"user@domain.invalid" wrote:
> Dear all,
>
> Im writing a WDM driver for a PCI device doing bus master packed based
> DMA. The device and the driver are working well so far, until I followed
> the suggestion of some experts to turn on driver verifier. OK, I did
> that and ran into several problems (which actually was caused by my not
> so correct code). The most ones I could solve but there was one I
> couldn't get rid of: The DMA runs perfectly but the data are always
> 0x0E, no matter what was in my user buffer!
> The device is not "scatter/gather-able" so I split up the DMA transfer
> into several small one-page DMA transfers. The logical address
> determined by MapTransfer() seemed to be NOT describing my user buffer.
> When DMA checking of driver verifier is disabled the transfer works
> perfect and the logical address determined by MapTransfer() is higher
> (e.g. 0x0a2ed1f8), but I don't know if the address has anything to do
> with that problem.
>
> Thanks for help
> Daniel
>
>

Daniel
Thu Oct 14 00:47:37 CDT 2004

Pavel A. wrote:
> Is your system XP SP2? Which CPU? (AMD or Intel?)
>
> --PA

No, the OS we use is still XP SP1 (5.1.2600).
The CPU is an Intel Pentium 4 / 2.4GHz / 512MB RAM.
Why? Do you know about a bug?

Regards,
Daniel

>
> "user@domain.invalid" wrote:
>
>>Dear all,
>>
>>Im writing a WDM driver for a PCI device doing bus master packed based
>>DMA. The device and the driver are working well so far, until I followed
>>the suggestion of some experts to turn on driver verifier. OK, I did
>>that and ran into several problems (which actually was caused by my not
>>so correct code). The most ones I could solve but there was one I
>>couldn't get rid of: The DMA runs perfectly but the data are always
>>0x0E, no matter what was in my user buffer!
>>The device is not "scatter/gather-able" so I split up the DMA transfer
>>into several small one-page DMA transfers. The logical address
>>determined by MapTransfer() seemed to be NOT describing my user buffer.
>> When DMA checking of driver verifier is disabled the transfer works
>>perfect and the logical address determined by MapTransfer() is higher
>>(e.g. 0x0a2ed1f8), but I don't know if the address has anything to do
>>with that problem.
>>
>>Thanks for help
>>Daniel
>>
>>

pavel_a
Thu Oct 14 15:25:06 CDT 2004

"Daniel Luethi" wrote:
> Pavel A. wrote:
> > Is your system XP SP2? Which CPU? (AMD or Intel?)
> >
> > --PA
>
> No, the OS we use is still XP SP1 (5.1.2600).
> The CPU is an Intel Pentium 4 / 2.4GHz / 512MB RAM.
> Why? Do you know about a bug?

SP2 can force PAE mode on some machines that normally never used PAE before
SP2.
This can _in theory_ break some old DMA drivers.

--PA

Alexander
Thu Oct 14 16:14:03 CDT 2004

Make sure to call FlushAdapterBuffers and (may not be necessary on x86)
KeFlushIoBuffers.
Also make sure you specify proper direction (WriteToDevice=TRUE) in
MapTransfer call.

DriverVerifier may force use of intermediate buffers.

<user@domain.invalid> wrote in message
news:OOEmcLSsEHA.376@TK2MSFTNGP09.phx.gbl...
> Dear all,
>
> Im writing a WDM driver for a PCI device doing bus master packed based
> DMA. The device and the driver are working well so far, until I followed
> the suggestion of some experts to turn on driver verifier. OK, I did that
> and ran into several problems (which actually was caused by my not so
> correct code). The most ones I could solve but there was one I couldn't
> get rid of: The DMA runs perfectly but the data are always 0x0E, no matter
> what was in my user buffer!
> The device is not "scatter/gather-able" so I split up the DMA transfer
> into several small one-page DMA transfers. The logical address determined
> by MapTransfer() seemed to be NOT describing my user buffer. When DMA
> checking of driver verifier is disabled the transfer works perfect and the
> logical address determined by MapTransfer() is higher (e.g. 0x0a2ed1f8),
> but I don't know if the address has anything to do with that problem.
>
> Thanks for help
> Daniel
>

Maxim
Thu Oct 14 16:44:03 CDT 2004

There was some known bug in DV on some platforms which caused it to disable
DMA by filling the buffer with 0xeeeeeee pattern or such.

Nevertheless, FlushAdapterBuffers is absolutely mandatory, think of it as
of undo for MapTransfer.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:u7908KjsEHA.160@TK2MSFTNGP11.phx.gbl...
> Make sure to call FlushAdapterBuffers and (may not be necessary on x86)
> KeFlushIoBuffers.
> Also make sure you specify proper direction (WriteToDevice=TRUE) in
> MapTransfer call.
>
> DriverVerifier may force use of intermediate buffers.
>
> <user@domain.invalid> wrote in message
> news:OOEmcLSsEHA.376@TK2MSFTNGP09.phx.gbl...
> > Dear all,
> >
> > Im writing a WDM driver for a PCI device doing bus master packed based
> > DMA. The device and the driver are working well so far, until I followed
> > the suggestion of some experts to turn on driver verifier. OK, I did that
> > and ran into several problems (which actually was caused by my not so
> > correct code). The most ones I could solve but there was one I couldn't
> > get rid of: The DMA runs perfectly but the data are always 0x0E, no matter
> > what was in my user buffer!
> > The device is not "scatter/gather-able" so I split up the DMA transfer
> > into several small one-page DMA transfers. The logical address determined
> > by MapTransfer() seemed to be NOT describing my user buffer. When DMA
> > checking of driver verifier is disabled the transfer works perfect and the
> > logical address determined by MapTransfer() is higher (e.g. 0x0a2ed1f8),
> > but I don't know if the address has anything to do with that problem.
> >
> > Thanks for help
> > Daniel
> >
>
>

Daniel
Fri Oct 15 00:34:50 CDT 2004

Maxim S. Shatskih wrote:
> There was some known bug in DV on some platforms which caused it to disable
> DMA by filling the buffer with 0xeeeeeee pattern or such.
>
> Nevertheless, FlushAdapterBuffers is absolutely mandatory, think of it as
> of undo for MapTransfer.
>
I use KeFlushIoBuffer() before calling MapTransfer() for the first time
in the AdapterControl Routine. FlashAdapterBuffer() is one of the first
thing I do in the DPC after finishing one part of the DMA transfer; it
happens before calling MapTransfer() for preparing for a the next part
of the DMA.

Where can I get more information about this bug you mentioned? I think
it's actually a bug because I'm not the only one fighting with this
problem. In another newsgroup (osr) I found somebody having the same
problem but also couldn't solve it. Their workaround was to disable "DMA
checking" in driver verifier.

Regards,
Daniel

Maxim
Mon Oct 18 17:36:06 CDT 2004

> problem. In another newsgroup (osr) I found somebody having the same
> problem but also couldn't solve it. Their workaround was to disable "DMA

Correct. I also know about this Verifier bug from the OSR's forum.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com