If your customer is describing an IO address using an MDL, and is not
building that MDL using MmBuildMdlForNonPagedPool, your customer is breaking
the rules. (And in addition, this form of DMA is not officially supported in
NT anyhow.) You should turn verifier on for *his* driver.
-----Original Message-----
From: Dave Taylor [mailto:xxxxx@aja.com]
Sent: Wednesday, August 14, 2002 12:22 PM
To: NT Developers Interest List
Subject: [ntdev] Re: METHOD_OUT_DIRECT: unwanted byte-access
caused by probe-and-lock?I actually don’t know exactly what my customer is doing. I
do know that he is somehow invoking my IOCTL from his driver.
What my driver sees is a IOCTL request to DMA a frame of
video from my board to a virtual address, which happens to be
on his board. I don’t know if his driver runs under Verifier
(mine does), but whatever he is doing is working for him in
the ‘Write’ direction (Writing to my board, using my
METHOD_IN_DIRECT IOCTL), but not in the ‘Read’ direction.
Perhaps since he’s calling my driver from his driver, the
buffer referencing problems that you and Mark refer to do not
exist? (Well, I like to hope for the
best.)
Thanks for the response!
-Dave Taylor
AJA Video SystemsPeter Viscarola wrote:
> wrote in message news:xxxxx@ntdev…
> > >
> > > I have a customer who is trying to use our board’s DMA
> engine to
> > > transfer data from our board to his board. I have implemented an
> > > IOCTL using METHOD_OUT_DIRECT. When the IOCTL is called, the OS
> > > probes his board’s memory to make sure it is writable.
> However, the
> > > OS seems to use a byte-access to perform this probe. His board
> > > cannot handle byte-accesses, and he gets memory corruption.
> > > At least, it seems like this is what is going on.
> > > Is there a way to tell the OS that the target memory for this
> > > operation is 32-bit-aligned?
> > >
> >
> > No.
> >
> > In fact, it’s not entirely clear to me that what you’re
> trying to do
> > is even supported by the operating system. Have you run
> this driver
> > under the checked build of the O/S and under Verifier?
> >
> > If what you’re telling me is that you have a region of
> device-resident
> > memory that you’re trying to pass as an input buffer to another
> > device, using an METHOD_xxx_DIRECT IOCTL, this doesn’t seem
> legal to
> > me. The probe is the LEAST of your worries… consider
> that the LOCK
> > operation is going to attempt to increment the reference
> count on the
> > page in which the user’s data buffer resides. This count
> is kept in
> > the PFN. So what’s the probelm? There no PFN entries created for
> > device memory!
> >
> > Note that changing the transfer type to _IN_DIRECT instead of
> > _OUT_DIRECT doesn’t solve this problem.
> >
> > Perhaps I’m missing something in your description. But, as
> I started
> > out
> > asking: Please tell me you’ve tried to run this driver
> under the checked
> > build and under Verifier. If you indeed have, can you
> please provide us
> > with a more detailed description of the operations you’re
> undertaking and
> > with which you’re having the difficulty?
> >
> > Peter
> > OSR
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@aja.com
> > To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> %%email.unsub%%
>