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 Systems
Peter 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%%