This problem turned out to be an issue with a macro I wrote to round up a
physical base address to start on a 64 block boundary. even now I cant
understand why it didn’t work, but this is a copy of the original macro
which didn’t work.
#define SGT_BLOCK_SIZE 0x10000
#define SGT_ROUND_TO_64K(Size) (((ULONG_PTR)(Size) + SGT_BLOCK_SIZE - 1) &
~(SGT_BLOCK_SIZE - 1))
ULONG LocalAddress = SGT_ROUND_TO_64K(ScatterGatherReadBasePA.LowPart);
Bearing in mind ScatterGatherReadBasePA is a type of PHYSICAL_ADDRESS This
would result in the LocalAddress being set to zero.
modifying the macro and removing the ULONG_PTR cast
#define SGT_ROUND_TO_64K(Size) (((Size) + SGT_BLOCK_SIZE - 1) &
~(SGT_BLOCK_SIZE - 1))
would no longer return zero, and now rounds up to the next 64k block
address. weird! I must admit using ULONG_PTR was probably the wrong thing to
do if I was to use this code for a 64bit driver.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Alberto Moreira
Sent: 09 November 2005 13:24
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] My [Free/Release] Build Driver doesn’t function
correctly!
The debugger should be able to tell you if the physical and
logical addresses match. I don’t know how to do it in Windbg,
but the “page” and “phys” commands in SoftICE should suffice:
you jot down the logical address(es) of your buffer, you do a
“page” command and jot down the physical address, and then you
peek into your scatter-gather list and check. It also doesn’t
take that long to write a little loop that looks at your buffer
and builds a scatter-gather list by hand, and you can use that
to compare results. Now, the next thing you must make sure is
that your device is actually filling that physical memory, that
is, under the assumption that it is actually receiving the
correct scatter-gather list. That, again, can be done with the
debugger. If you can actually see the data in your physical
memory but not in your user buffer, then you have something
wrong in the way you use the API. Sometimes what I do to test
this kind of thing is, I write test code to manually copy the
user buffer to or from my own kernel-side buffer and do the DMA
from my kernel buffer: I find that kind of code is much easier
to bring up than an API-based implementation. However, that
totally bypasses the API, so, you must know what’s going on
around you!
Alberto.
----- Original Message -----
From: “Tim Roberts”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, November 08, 2005 12:04 PM
Subject: Re: [ntdev] My [Free/Release] Build Driver doesn’t
function correctly!
> James Dunning wrote:
>
>>I have noticed that my PCI device driver doesn’t function
>>correctly under
>>the Free Build configuration. When I try to read data from
>>the device using
>>ReadFile, it returns successfully however nothing is written
>>to the User
>>Buffer? …
>>I suspect that the DMA operation is working correctly, writing
>>data from the
>>onboard memory to system physical addresses. but how can I
>>prove this? how
>>is it possible probe the physical addresses from the
>>scattergather table to
>>ensure data is actually there? Ideally it would be nice to
>>probe the
>>physical memory during the read completion routine prior to
>>calling
>>ReadAdapter->DmaOperations->PutScatterGatherList… However I
>>am not quite
>>sure how to do this.
>>
>
> DbgPrint is one way.
>
>>I am wondering whether there’s a problem with windows is not
>>copying the
>>DMA’s data written to system’s physical memory to the user’s
>>virtual memory
>>(I am not sure how the windows virtual memory manager works)
>>
>
> None of us can answer this question unless you show us the
> code in your ReadFile handler.
>
> The Windows virtual memory manager does not get involved in
> DMA. It’s entirely up to you. Are you locking the user’s
> buffer into kernel space and using that for the DMA, or are
> you using a common buffer and then copying to the user’s
> buffer?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.