My book is a little old, so my section on PAT programming is 9.12.4. However
it does address P4-P6 PAT programming, and it claims that one must not use
both WC and any of the cached modes (WT/WB) on a page. It implies, but does
not state, that other combined modes work fine. I’ll buy that. As far as I
know WC is used only for video, and for the specific problem I’m concerned
with, that is not an issue, it is the various and assorted random (no pun
intended,) pages of virtual memory that are an issue.
-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Saturday, June 22, 2002 12:18 PM
To: NT Developers Interest List
Subject: [ntdev] Re: posible bug in XP kernel - was
MmMapLockedPages… . on XP vs. 2000Mark,
Im debating with myself too, and Intel architecture manuals:
check Intel Architecture Software Developer’s Manual Volume
3: System Programming Guidepart number 24319202
Section 9.13.5 Programming the PAT
Now, this seems very consistent , and folowed by XP kernel.
The guidelines are folowed, as well they ensure corectly that
any PAT entry is validate by flushing the TLB and caches are
invalidated by sending an IPI to all processors, which will
basically just execute a wbinvd. (check MmMapIoSpace in
debugger) This is done only for p6+ . I think the problem is
WITH actual processors and not older one.I wait for your feedback after you read this
----- Original Message -----
From: “Mark Roddy”
> To: “NT Developers Interest List”
> Sent: Saturday, June 22, 2002 6:52 PM
> Subject: [ntdev] Re: posible bug in XP kernel - was
> MmMapLockedPages… . on XP vs. 2000
>
>
> > I’m debating with myself here
> >
> > We thought about the cached writer problem (the non-cached reader
> > could get stale, thus incoherent data,) but we came up with this
> > falsification: pci devices doing dma will fetch data from
> cpu cache’s
> > if required rather than physical memory due to the
> intervention of the
> > memory bus chipset. Bus snooping will prevent either cached
> writers or
> > non-cached writers from presenting an out of order sequence
> to memory
> > readers.
> >
> > So we continue to be puzzled about exactly what bug the
> change in XP
> > mm code was fixing. Perhaps it is fixing a bug that does
> not exist on
> > current pentium* architecture platforms?
> >
> > > -----Original Message-----
> > > From: Roddy, Mark [mailto:xxxxx@stratus.com]
> > > Sent: Friday, June 21, 2002 12:22 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: posible bug in XP kernel - was
> > > MmMapLockedPages… . on XP vs. 2000
> > >
> > >
> > > Actually I think it is the cached writers who are the
> problem, not
> > > the non-cached writers. The non-cached write to memory
> will indeed
> > > invalidate the cache lines of the cached writer cpus, due
> to memory
> > > bus snooping, however the cached writers will not invalidate the
> > > cache lines of the non-cached writer, 'cause he ain’t using the
> > > cache. The cpus using cache will have a coherent view, the cpu(s)
> > > doing non-cached access may not. Particularly a problem if
> > > invalidates can be statisfied from cache rather than from memory.
> > >
> > > > -----Original Message-----
> > > > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> > > > Sent: Friday, June 21, 2002 10:53 AM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] Re: posible bug in XP kernel - was
> > > > MmMapLockedPages… . on XP vs. 2000
> > > >
> > > >
> > > > > everywhere, but can somebody explain exactly how the cache
> > > > coherency
> > > > > protocol gets violated in this case and memory access gets
> > > > potentially
> > > > > incoherent?
> > > >
> > > > Imagine the same page double-mapped to the address space by 2
> > > > different PTEs, one with caching on, other with caching
> off. Now
> > > > imagine some code writes a value via noncached PTE. The
> value is
> > > > updated in memory and not updated in the cache. The read from
> > > > cached PTE will read the stale value.
> > > >
> > > > This is a good old problem which is known to people working on
> > > > hardware which requires the software to know on cache coherency
> > > > issues (i.e. PowerPC).
> > > >
> > > > Max
> > > >
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as:
> xxxxx@stratus.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%%
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@rdsor.ro 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%%
>
