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 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.
Indeed, the address was really strange, something like 0x15000 which is
somehow pretty low (my personal impression). When DMA checking of driver
verifier is disabled the transfer works perfect and the logical address
determined by MapTransfer() was higher (e.g. 0x0a2ed1f8), but I don’t
know if the address has anything to do with that problem.
However, I discovered that one year ago somebody seemed to have the same
problem (Stephane Bureau) but Peter couldn’t help him. Stephane, did you
made a report to DDK support group now and did you get an answer?
Attached an abstract of the found discussion
Thanks for help
Daniel
-------------------- 25.9.03 ------------------------
“Stephane Bureau” wrote in message news:xxxxx@ntdev…
>>
>> Ok… so here are the info about my O/S version:
>> Microsoft Windows XP
>> Version 5.1 (Build 2600.xpsp2.021108-1929 : Service Pack 1)
>>
>> So I’m not sure but it looks quite up-to-date to me.
>>
Yeah, me too. This IS the system on which your driver is running, right?
Not the system on which you’re building? (sorry, but I have to ask – One
can take nothing for granted in email these days).
>>
>> Ok, I looked at the bytes right before and after the auxiliary buffer in
>> memory, and the bytes are…
>> 0x44, 0x6D, 0x61, 0x56, 0x72, 0x66, 0x66, 0x79, 0x30. In other words,
>> it’s written “DmaVrfy0”. And that is so for all the pages/segments
>> returned by the SG list (each segment of 4kB has “DmaVrfy0” written
before
>> and after it).
>>
OK, well we know for sure that DMA Verifier is “engaged” and is managing
these segments then.
>>
>> So… have any idea how I could get that function name?
>>
Ah, it doesn’t matter. You’re clearly running on a relatively recent build
of the O/S, and driver verifier is managing your DMA segments.
Let me try to restate your problem, to see if I have it right: Given an
arbitrary buffer in main memory (not device memory) that’s properly
described by an MDL (the MDL is probed and locked and valid), you can verify
the contents of that buffer directly via that MDL by looking at the pages
pointed to by the PFNs in the MDL’s page vector (NOT by looking at any VA
contained in the MDL), but during your execution routine callback from
GetScatterGatherList the contents of the pages that the scatter/gather
elements point to is DIFFERENT from the contents of the pages pointed to by
the PFNs in your MDL’s page vector. And this is only true when using Driver
Verifier. When you do NOT use driver verifier, your driver works perfectly.
Finally, your testing your driver on Windows XP SP1, using the checked
kernel and hal.
Does the describe the problem precisely?
If you’re quite certain this is the case, you have a real, honest to
goodness mystery on your hands. I’d strongly suggest getting in touch with
the DDK Support folks at Microsoft. They would certainly be aware of any
existing problems wth DMA support in driver verifier. Here at OSR we use
the DMA support in verifier rather frequently, and have not experienced any
such problem.
OTOH, if the above does not describe your problem, please let us know how
your problem is different from that described above.
Peter
OSR
---------------
Indeed, this is the machine on which I am both building and running my
driver. But just so you know, I can reproduce this bug on all the
machines we have here (all running Windows XP SP1).
>> Does the describe the problem precisely?
In fact, that’s all right. Maybe except for the part when you say:
“…using the checked kernel and hal”. I’m not sure, but I would guess
we’re running the release versions of the kernel and hal. Could it
change anything? Should I try with the checked version?
>> I’d strongly suggest getting in touch
>> with the DDK Support folks at Microsoft. They would certainly be aware
>> of any existing problems wth DMA support in driver verifier. Here at
>> OSR we use the DMA support in verifier rather frequently, and have
not > experienced any such problem.
Ok, well I already sent a message to the Microsoft Development NewsGroup
(microsoft.public.development.device.drivers). Is that the right place,
or should I contact them by some other way?
Thanks again for your help.
Stephane