user mem for DMA

Hello

We’re discussing about a general issue: Is it possible to allocate
non-pageable memory (i.e.64kB on one continous block) to use it for
DMA-transfer and access it from user mode directly? Our DMA-master is not
scatter-gather able yet, but still we would like to make burst transfers
over PCI with bulks bigger than 4k. If possible, with which command do we
have to alloc the memory?

Thanks for help
Daniel

Hi!
You can allocate common buffer in such way:

// Somethere in DeviceExtension:
PVOID m_TransferBuffer;
PHYSICAL_ADDRESS m_TransferBufferPa;

// In StartDevice routine:
PHYSICAL_ADDRESS paLimits[3]; // Limits
paLimits[0].QuadPart = (LONGLONG)0;
paLimits[1].QuadPart = (LONGLONG)0xfffff000UL;
paLimits[2].QuadPart = (LONGLONG)GetTransferBufferAlignment();

m_TransferBuffer =
MmAllocateContiguousMemorySpecifyCache(GetTransferBufferSize(),
paLimits[0], paLimits[1], paLimits[2], m_CachingType);

ASSERT(m_TransferBuffer); // Are we happy?
if (m_TransferBuffer)
{ // Check allocation result
m_TransferBufferPa = MmGetPhysicalAddress(m_TransferBuffer);
}

How to transfer address to user (e.g. on responce to DeviceIoControl call):

// In DispatchDeviceControl:
PMDL pMdl = IoAllocateMdl(m_TransferBuffer, GetTransferBufferSize(), false,
false, 0);
MmBuildMdlForNonPagedPool(pMdl);
PVOID pvAddress = MmMapLockedPagesSpecifyCache(pMdl, UserMode, CachingType,
0, FALSE, NormalPagePriority);
// return address to user

This code is unsafe, however idea is clear
S.Y.
Igor V. Slewsarev

Allocate in kernel mode, then MmMapLockedPages(UserMode) to user mode.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Daniel Luethi”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Monday, September 22, 2003 4:35 PM
Subject: [ntdev] user mem for DMA

> Hello
>
> We’re discussing about a general issue: Is it possible to allocate
> non-pageable memory (i.e.64kB on one continous block) to use it for
> DMA-transfer and access it from user mode directly? Our DMA-master is not
> scatter-gather able yet, but still we would like to make burst transfers
> over PCI with bulks bigger than 4k. If possible, with which command do we
> have to alloc the memory?
>
> Thanks for help
> Daniel
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> You can allocate common buffer in such way:

m_TransferBuffer =
MmAllocateContiguousMemorySpecifyCache(GetTransferBufferSize(),
paLimits[0], paLimits[1], paLimits[2], m_CachingType);

Wrong way. Use ->AllocateCommonBuffer on the adapter object.

> Wrong way. Use ->AllocateCommonBuffer on the adapter object.
It’s right, except you can’t precise specify caching type (e.g.
MmWriteCombined or MmHardwareCoherentCached), so really you have no choice.

> > Wrong way. Use ->AllocateCommonBuffer on the adapter object.

It’s right, except you can’t precise specify caching type (e.g.
MmWriteCombined or MmHardwareCoherentCached), so really you have no choice.

Sorry.

You must not specify any caching type for DMAble memory. Even if there is a
function parameter to do this - then set it to Cached, it is ignored on x86
machines due to hardware maintaining DMA/cache coherency. Just forget the word
“caching type” speaking about DMA.

Device memory-mapped stuff is another song. To it, MmWriteCombined or
MmNonCached makes sense.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

A DMA controller is just another master, and it’s independent of the
processors, hence, caching doesn’t even make sense in this context, right ?
Or am I missing something ?

Alberto.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, September 24, 2003 11:31 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

> Wrong way. Use ->AllocateCommonBuffer on the adapter object.
It’s right, except you can’t precise specify caching type (e.g.
MmWriteCombined or MmHardwareCoherentCached), so really you have no
choice.

Sorry.

You must not specify any caching type for DMAble memory. Even if there is a
function parameter to do this - then set it to Cached, it is ignored on x86
machines due to hardware maintaining DMA/cache coherency. Just forget the
word
“caching type” speaking about DMA.

Device memory-mapped stuff is another song. To it, MmWriteCombined or
MmNonCached makes sense.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.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@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

Moreira, Alberto alberto.moreira-at-compuware.com |ntdev/1.0-Allow| wrote:

A DMA controller is just another master, and it’s independent of the
processors, hence, caching doesn’t even make sense in this context, right ?
Or am I missing something ?

It does make sense because if you ask for non-cached memory and
try to map it, XP will eventually BSOD. It turns out that common
buffers are quietly allocated as cached memory because the
common ix86 systems are cache coherent w/ the PCI subsystem.

Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

>

A DMA controller is just another master, and it’s independent
of the processors, hence, caching doesn’t even make sense in
this context, right ? Or am I missing something ?

The issue is will the processors/cache system correctly reflect changes made
by external devices modifying physical memory. On current standard x86
systems the answer is yes they will.

But that may pollute the cache. For example, if we’re doing graphics output,
there’s no need even to use writeback, writethrough is enough, which means,
caching may not buy much. If for example I write to memory a stream of
commands to a graphics chip, or even a texture to be either loaded or
rendered directly from memory, I don’t need it to be cached. If I still
remember, the Intel graphics chip had the ability to render a texture
directly from main memory, which means there’s going to be a pretty sizable
texture cache implemented in main memory - well, I’m not sure we want those
textures to be in cacheable memory while they’re rendering, or we may end up
not having enough space in the cache for anything else.

Also, that’s curious enough, why would XP Bluescreen if one tries to map
uncached memory ?

Alberto.

-----Original Message-----
From: Stephen Williams [mailto:xxxxx@sneakemail.com]
Sent: Wednesday, September 24, 2003 12:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

Moreira, Alberto alberto.moreira-at-compuware.com |ntdev/1.0-Allow| wrote:

A DMA controller is just another master, and it’s independent of the
processors, hence, caching doesn’t even make sense in this context, right
?
Or am I missing something ?

It does make sense because if you ask for non-cached memory and
try to map it, XP will eventually BSOD. It turns out that common
buffers are quietly allocated as cached memory because the
common ix86 systems are cache coherent w/ the PCI subsystem.

Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

I believe NT handles video memory as a separate case in order to support
write combined mode.

=====================
Mark Roddy

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, September 24, 2003 3:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

But that may pollute the cache. For example, if we’re doing
graphics output, there’s no need even to use writeback,
writethrough is enough, which means, caching may not buy
much. If for example I write to memory a stream of commands
to a graphics chip, or even a texture to be either loaded or
rendered directly from memory, I don’t need it to be cached.
If I still remember, the Intel graphics chip had the ability
to render a texture directly from main memory, which means
there’s going to be a pretty sizable texture cache
implemented in main memory - well, I’m not sure we want those
textures to be in cacheable memory while they’re rendering,
or we may end up not having enough space in the cache for
anything else.

Also, that’s curious enough, why would XP Bluescreen if one
tries to map uncached memory ?

Alberto.

-----Original Message-----
From: Stephen Williams [mailto:xxxxx@sneakemail.com]
Sent: Wednesday, September 24, 2003 12:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

Moreira, Alberto alberto.moreira-at-compuware.com
|ntdev/1.0-Allow| wrote:
> A DMA controller is just another master, and it’s
independent of the
> processors, hence, caching doesn’t even make sense in this context,
> right
?
> Or am I missing something ?

It does make sense because if you ask for non-cached memory
and try to map it, XP will eventually BSOD. It turns out that
common buffers are quietly allocated as cached memory because
the common ix86 systems are cache coherent w/ the PCI subsystem.

Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Moreira, Alberto alberto.moreira-at-compuware.com |ntdev/1.0-Allow| wrote:

But that may pollute the cache. For example, if we’re doing graphics output,
there’s no need even to use writeback, writethrough is enough, which means,
caching may not buy much. If for example I write to memory a stream of
commands to a graphics chip, or even a texture to be either loaded or
rendered directly from memory, I don’t need it to be cached. If I still
remember, the Intel graphics chip had the ability to render a texture
directly from main memory, which means there’s going to be a pretty sizable
texture cache implemented in main memory - well, I’m not sure we want those
textures to be in cacheable memory while they’re rendering, or we may end up
not having enough space in the cache for anything else.

Also, that’s curious enough, why would XP Bluescreen if one tries to map
uncached memory ?

Tries to map is cached, detects the confusing flag in the page
table, and panics. You can’t map it to process address space
without it being cached, or XP will panic. That’s all I rememer,
having struggled with it myself.

I didn’t say I agree with the policy, just that it is enforced
by the O/S, reasonable or not.

Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

I used to know these things backwards, but it’s been over three years now, I
as yet haven’t written any low level graphics code in this millenium ! So,
my mind is going. Makes sense, though, although I’m not totally convinced
that write combining buys a heck of a lot; but I may be wrong. What I do
think may end up making difference is to be able to render textures directly
from host memory, specially if it’s true what the press is saying about the
new Longhorn API: if people do their job right, you may end up being able to
render a window as a texture directly from the window image itself.

Now, this is probably off-topic, but for an interesting concept, I suggest
taking a look at http://www.3dna.com.

Alberto.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Wednesday, September 24, 2003 3:17 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

I believe NT handles video memory as a separate case in order to support
write combined mode.

=====================
Mark Roddy

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, September 24, 2003 3:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

But that may pollute the cache. For example, if we’re doing
graphics output, there’s no need even to use writeback,
writethrough is enough, which means, caching may not buy
much. If for example I write to memory a stream of commands
to a graphics chip, or even a texture to be either loaded or
rendered directly from memory, I don’t need it to be cached.
If I still remember, the Intel graphics chip had the ability
to render a texture directly from main memory, which means
there’s going to be a pretty sizable texture cache
implemented in main memory - well, I’m not sure we want those
textures to be in cacheable memory while they’re rendering,
or we may end up not having enough space in the cache for
anything else.

Also, that’s curious enough, why would XP Bluescreen if one
tries to map uncached memory ?

Alberto.

-----Original Message-----
From: Stephen Williams [mailto:xxxxx@sneakemail.com]
Sent: Wednesday, September 24, 2003 12:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

Moreira, Alberto alberto.moreira-at-compuware.com
|ntdev/1.0-Allow| wrote:
> A DMA controller is just another master, and it’s
independent of the
> processors, hence, caching doesn’t even make sense in this context,
> right
?
> Or am I missing something ?

It does make sense because if you ask for non-cached memory
and try to map it, XP will eventually BSOD. It turns out that
common buffers are quietly allocated as cached memory because
the common ix86 systems are cache coherent w/ the PCI subsystem.

Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com 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@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

x86 CPUs maintain cache coherency with one another - and with DMA masters -
automatically. So, no need in any kind of cache-related measures for DMA.

Another thing is mapping the device memory and device registers. There you can
specify the caching type - noncached for registers, write-combine for memory
like video.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, September 24, 2003 7:40 PM
Subject: [ntdev] Re: user mem for DMA

> A DMA controller is just another master, and it’s independent of the
> processors, hence, caching doesn’t even make sense in this context, right ?
> Or am I missing something ?
>
> Alberto.
>
> -----Original Message-----
> From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> Sent: Wednesday, September 24, 2003 11:31 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: user mem for DMA
>
>
> > > Wrong way. Use ->AllocateCommonBuffer on the adapter object.
> > It’s right, except you can’t precise specify caching type (e.g.
> > MmWriteCombined or MmHardwareCoherentCached), so really you have no
> choice.
>
> Sorry.
>
> You must not specify any caching type for DMAble memory. Even if there is a
> function parameter to do this - then set it to Cached, it is ignored on x86
> machines due to hardware maintaining DMA/cache coherency. Just forget the
> word
> “caching type” speaking about DMA.
>
> Device memory-mapped stuff is another song. To it, MmWriteCombined or
> MmNonCached makes sense.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.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@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify us immediately
> and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Yes, it is impossible to remap the same memory with different caching types.
This leads to nasty aliasing problems, thus the OS BSODs to prevent you from
catching them.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Stephen Williams”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, September 24, 2003 8:05 PM
Subject: [ntdev] Re: user mem for DMA

> Moreira, Alberto alberto.moreira-at-compuware.com |ntdev/1.0-Allow| wrote:
> > A DMA controller is just another master, and it’s independent of the
> > processors, hence, caching doesn’t even make sense in this context, right ?
> > Or am I missing something ?
>
> It does make sense because if you ask for non-cached memory and
> try to map it, XP will eventually BSOD. It turns out that common
> buffers are quietly allocated as cached memory because the
> common ix86 systems are cache coherent w/ the PCI subsystem.
> –
> Steve Williams “The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> http://www.icarus.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> texture cache implemented in main memory - well, I’m not sure we want those

textures to be in cacheable memory while they’re rendering, or we may end up
not having enough space in the cache for anything else.

There is no need at all to access any portion of main system RAM in noncached
mode, at least on x86.
The thing is that the only memory accessors are other CPUs and DMA cards, and
the cache coherency is always maintained. So, the cache is transparent.

Possible cache pollution is an issue for sure, but this requires measurement -
since we have cache pollution on one side against the overhead of noncached
accesses from the other side.

Also, that’s curious enough, why would XP Bluescreen if one tries to map
uncached memory ?

If 2 PTEs point to the same page, one in cached mode and another in noncached -
this is a source of nasty aliasing problems. For instance, write from the
noncached PTE will not update the cache line, so the next read from cached PTE
will read stale data.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> I believe NT handles video memory as a separate case in order to support

write combined mode.

IIRC this is done by MmWriteCombined flag to MmMapIoSpace.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Forgive my ignorance, but what hardware mechanism guarantees coherency of
PCI memory ? In the case of accesses to main memory, the request is snooped
by other processors in the system bus, and the MESI protocol takes care of
it. How do processors get notified that a piece of memory that’s not on the
system bus got updated, so that they invalidate their corresponding cache
lines ? Do PCI bridges have special support for this kind of thing ?

Alberto.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, September 25, 2003 11:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

texture cache implemented in main memory - well, I’m not sure we want
those
textures to be in cacheable memory while they’re rendering, or we may end
up
not having enough space in the cache for anything else.

There is no need at all to access any portion of main system RAM in
noncached
mode, at least on x86.
The thing is that the only memory accessors are other CPUs and DMA cards,
and
the cache coherency is always maintained. So, the cache is transparent.

Possible cache pollution is an issue for sure, but this requires measurement

since we have cache pollution on one side against the overhead of noncached
accesses from the other side.

Also, that’s curious enough, why would XP Bluescreen if one tries to map
uncached memory ?

If 2 PTEs point to the same page, one in cached mode and another in
noncached -
this is a source of nasty aliasing problems. For instance, write from the
noncached PTE will not update the cache line, so the next read from cached
PTE
will read stale data.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.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@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

I think the answer is that nothing guarantees the coherency of PCI memory,
which is why it is usually mapped into system space as non-cached. It is PCI
access to system memory that is cache coherent.

=====================
Mark Roddy

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, September 25, 2003 12:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

Forgive my ignorance, but what hardware mechanism guarantees
coherency of PCI memory ? In the case of accesses to main
memory, the request is snooped by other processors in the
system bus, and the MESI protocol takes care of it. How do
processors get notified that a piece of memory that’s not on
the system bus got updated, so that they invalidate their
corresponding cache lines ? Do PCI bridges have special
support for this kind of thing ?

Alberto.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, September 25, 2003 11:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: user mem for DMA

> texture cache implemented in main memory - well, I’m not
sure we want
those
> textures to be in cacheable memory while they’re rendering,
or we may
> end
up
> not having enough space in the cache for anything else.

There is no need at all to access any portion of main system
RAM in noncached mode, at least on x86. The thing is that the
only memory accessors are other CPUs and DMA cards, and the
cache coherency is always maintained. So, the cache is transparent.

Possible cache pollution is an issue for sure, but this
requires measurement

since we have cache pollution on one side against the
overhead of noncached accesses from the other side.

> Also, that’s curious enough, why would XP Bluescreen if one
tries to
> map uncached memory ?

If 2 PTEs point to the same page, one in cached mode and
another in noncached - this is a source of nasty aliasing
problems. For instance, write from the noncached PTE will not
update the cache line, so the next read from cached PTE will
read stale data.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.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@compuware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Hello

Thanks to all for your reply. I will check out your suggestions as soon as
the PCI board is ready for DMA transfers and give you a feedback which one
worked on our system!

regards,
Daniel