> The test application slides the buffer size from 1K up to 2M. Each block
size
performs 10,000 transfers, after which transfer rates are calculated and
printed.
So … does four overlapping 2MB transfers cause the crash? That’s only 8
MB mapped – doesn’t sound like enough. Unless you or somebody else is
doing something else that’s consuming large chunks of system memory. You
should try watching system PTE consumption in Performance Monitor
(Object = Memory, Counter = Free System Page Table Entries). When you run
your test util, you should see this counter decrease. If there are no
leaks, then it should bounce back to its previous level when you terminate
the util before it leads to a crash.
I need is an MDL to lock it down for the DMA transfer and a
system address.
Careful … if we are understanding each other, it’s getting a system
address for the big data buffer that’s killing you. And you don’t need
it for DMA.
The only user buffer access I need is the 94 byte transport
packet that I
use
to build the FcRB and pass status and CDB information to the
user. That
packet is already MDL backed and accessible at any IRQL. So,
I don’t need
the MmProbeAndLockPages, or the MmUnlockPages.
Right, the 94-byte packet doesn’t need to be locked, but it needs to be
mapped so you can see your parameters.
The data buffer needs to be locked but not mapped.
Hmmm, since it’s IoAllocateMdl links it to
IRP->MdlAddress->Next, do I need
to call IoFreeMdl, or will that happen when IoCompleteRequest
tears down theIRP?
I’ve never paid much attention to chaining MDLs with the Next ptr, but
it sounds like the system is cleaning up the portion you append; this
is how it is able to unmap your data buffers from system space currently.
If it did not, a few large I/Os would exhaust your PTEs immediately,
overlapped or not.
Dave Cox
Hewlett-Packard Co.
NSSO/SANS/SMSO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com