“Dan Partelly” wrote in message news:xxxxx@ntdev…
> MmMapLockedPagesSpecifyCache relay internaly on a
> call to MiMapLockedPagesInUserSpace for performing a user space mapping.
…
> The DDK (at least not mine)does not statuates that this particual API can
> raise an exception.
>
I made a few discrete inquiries. This is a apparently a documentation bug.
Whenever you call MmMapLockedPagesSpecifyCache, and specify UserMode as the
AccessMode argument, the call can raise an exception. Thus, you need to
wrap the call in an exception handler. Apparently this has been true since
the “SpecifyCache” flavor of this function was implemented.
The exception is returned to caller because this provides more information
than just returning NULL (so you have a clue as to WHY it didn’t work, not
just that it didn’t work).
Peter
OSR
>> And what should I do with said exception? Just fail the whole operation?
Fix the situation , ensure cache coherency. Make sure you use the same
attributtes for caching everywhere.
> MmCached vs. MmNonCached
Yes . The main reason for this added check in XP is because this would
result into a conflicting TLB entry in CPU.
> … VERY nice analysis
thank you for your oppinion about this , Mr Viscarola
----- Original Message -----
From: “Stephen Williams”
To: “NT Developers Interest List”
Sent: Thursday, June 20, 2002 10:29 PM
Subject: [ntdev] Re: posible bug in XP kernel - was MmMapLockedPages… on
XP vs. 2000
>
> xxxxx@rdsor.ro said:
> > Encapsulate yor code into try except statemts, and youll catch
> > this exception.
>
> >
> xxxxx@rdsor.ro said:
> > STATUS_INVALID_ADDRESS is raised as a result to a call to a function
> > called MiMustFrameBeCached, so I still think you are facing a cache
> > collision.
>
> Is this something that would be affected by the MmCached vs. MmNonCached
> parameter?
>
> –
> Steve Williams “The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> steve at picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
> abuse@xo.com
> xxxxx@ftc.gov
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
Hmm, yes I just checked the __try block bounds in older NT versions, and the
handlers wont catch raised status in the situations like this. Lets hope
the DDK docs will be fixed.
Thank you all
----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Thursday, June 20, 2002 11:14 PM
Subject: [ntdev] DOC BUG - was posible bug in XP kernel - was
MmMapLockedPages… on XP vs. 2000
> “Dan Partelly” wrote in message
news:xxxxx@ntdev…
> > MmMapLockedPagesSpecifyCache relay internaly on a
> > call to MiMapLockedPagesInUserSpace for performing a user space
mapping.
> …
> > The DDK (at least not mine)does not statuates that this particual API
can
> > raise an exception.
> >
>
> I made a few discrete inquiries. This is a apparently a documentation
bug.
>
> Whenever you call MmMapLockedPagesSpecifyCache, and specify UserMode as
the
> AccessMode argument, the call can raise an exception. Thus, you need to
> wrap the call in an exception handler. Apparently this has been true
since
> the “SpecifyCache” flavor of this function was implemented.
>
> The exception is returned to caller because this provides more information
> than just returning NULL (so you have a clue as to WHY it didn’t work, not
> just that it didn’t work).
>
> Peter
> OSR
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
xxxxx@osr.com said:
Remember that one of the changes from Win2K to XP/.NET was a fix
whereby memory mappings must be consistent with regard to cache type.
xxxxx@osr.com said:
I think Mr. Partelly has hit upon your solution,
But I created these pages with AllocateCommonBuffer, and the
CachEnabled parameter set to FALSE. Then I only get this symptom
when I pass MmNonCached to MmMapLockedPagesSpecifyCached. That
*is* consistent, is it not?
Also, the exception is not tossed every time, only once in a while.
Maybe every 10-20 attempts? And at that it depends on the size of
the frame I’m allocating. On some tests with smaller frames, I’ve
seen no error at all, for example.
I really don’t want the memory cached in the user mode, because
it is shared with a PCI device. That’s the whole point of all this.
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
>> And what should I do with said exception? Just fail the whole operation?
xxxxx@rdsor.ro said:
Fix the situation , ensure cache coherency. Make sure you use the same
attributtes for caching everywhere.
But these pages are supposedly noncached everywhere! I’m asking the
AllocateCommonBuffer function to make them non-cached. And if I weren’t,
wouldn’t it crash every time?
–
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
xxxxx@osr.com said:
The exception is returned to caller because this provides more
information than just returning NULL (so you have a clue as to WHY it
didn’t work, not just that it didn’t work).
Pardon my ignorance, but how does it tell me why?
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
I think the reason why you get this problem are large 4Mb pages. The
posibility to have a cache colision with those in very big,
basically inevitable. AllocateCommonBuffer basically tryes to allocate
contigous memeory from non-paged pool. You might be forced to use cached
memory in this case. This is an assumption. I might be wrong, but I doubt.
Im too tired to veryify this in debugger. Paste for me from your system the
values from the folowing variables
MmNonPagedPoolStart
MmNonPagedPoolEnd
MmNonPagedPool
when you get the pointer back from AllocateCommonBuffer , write it down and
put it in the mail as well.
Then tell me how much RAM your machine is using , I think you have more than
128mb of physicall memory. You see this portion (512 Mb from 80000000,
ending 9FFFFFFF) can be mapped using large pages, and this is very probable.
Also on many systems, the nonpaged pool start is there , in this are, also.
Is very probable that AllocateCommonBuffer will return memory from this
area.
Regards, Dan
----- Original Message -----
From: “Stephen Williams”
To: “NT Developers Interest List”
Sent: Thursday, June 20, 2002 11:20 PM
Subject: [ntdev] Re: posible bug in XP kernel - was MmMapLockedPages… on
XP vs. 2000
>
> xxxxx@osr.com said:
> > Remember that one of the changes from Win2K to XP/.NET was a fix
> > whereby memory mappings must be consistent with regard to cache type.
>
> xxxxx@osr.com said:
> > I think Mr. Partelly has hit upon your solution,
>
> But I created these pages with AllocateCommonBuffer, and the
> CachEnabled parameter set to FALSE. Then I only get this symptom
> when I pass MmNonCached to MmMapLockedPagesSpecifyCached. That
> is consistent, is it not?
>
> Also, the exception is not tossed every time, only once in a while.
> Maybe every 10-20 attempts? And at that it depends on the size of
> the frame I’m allocating. On some tests with smaller frames, I’ve
> seen no error at all, for example.
>
> I really don’t want the memory cached in the user mode, because
> it is shared with a PCI device. That’s the whole point of all this.
> –
> Steve Williams “The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> steve at picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
> abuse@xo.com
> xxxxx@ftc.gov
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
xxxxx@rdsor.ro said:
I think the reason why you get this problem are large 4Mb pages. The
posibility to have a cache colision with those in very big, basically
inevitable. AllocateCommonBuffer basically tryes to allocate contigous
memeory from non-paged pool.
I allocate memory from AllocateCommonBuffer a page at a time. The
memory does not need to be contiguous for my device, just shared
with the application, so I allocate it a page at a time so that it
is scattered and easier to get. Might XP be making its own decisions
about Cached/NonCached a page at a time? Ugh!
MmNonPagedPoolStart
MmNonPagedPoolEnd
MmNonPagedPool
Where are these declared?
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
“Stephen Williams” wrote in message news:xxxxx@ntdev…
>
> xxxxx@osr.com said:
> > The exception is returned to caller because this provides more
> > information than just returning NULL (so you have a clue as to WHY it
> > didn’t work, not just that it didn’t work).
>
> Pardon my ignorance, but how does it tell me why?
>
The exception code that is returned to you… right?
Peter
OSR
> Pardon my ignorance, but how does it tell me why?
xxxxx@osr.com said:
The exception code that is returned to you… right?
Well, with GetExceptionCode I can get the generic information, but
what would any particular code mean? The documentation for the
MmMapLockedPagesSpecifyCache doesn’t say anything about exceptions,
so how do I learn what code X is telling me?
–
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
Even if you have kseg0 and large pages, you can ask
AllocateCommonBuffer to create a noncached buffer.
In this case, it will allocate system PTEs to point to the pages and
will set them as noncached. kseg0 address for the buffer will not be
used.
Max
----- Original Message -----
From: “Dan Partelly”
To: “NT Developers Interest List”
Sent: Friday, June 21, 2002 1:17 AM
Subject: [ntdev] Re: posible bug in XP kernel - was
MmMapLockedPages… on XP vs. 2000
> I think the reason why you get this problem are large 4Mb pages. The
> posibility to have a cache colision with those in very big,
> basically inevitable. AllocateCommonBuffer basically tryes to
allocate
> contigous memeory from non-paged pool. You might be forced to use
cached
> memory in this case. This is an assumption. I might be wrong, but I
doubt.
> Im too tired to veryify this in debugger. Paste for me from your
system the
> values from the folowing variables
>
> MmNonPagedPoolStart
> MmNonPagedPoolEnd
> MmNonPagedPool
>
> when you get the pointer back from AllocateCommonBuffer , write it
down and
> put it in the mail as well.
>
> Then tell me how much RAM your machine is using , I think you have
more than
> 128mb of physicall memory. You see this portion (512 Mb from
80000000,
> ending 9FFFFFFF) can be mapped using large pages, and this is very
probable.
> Also on many systems, the nonpaged pool start is there , in this
are, also.
> Is very probable that AllocateCommonBuffer will return memory from
this
> area.
>
>
>
> Regards, Dan
>
> ----- Original Message -----
> From: “Stephen Williams”
> To: “NT Developers Interest List”
> Sent: Thursday, June 20, 2002 11:20 PM
> Subject: [ntdev] Re: posible bug in XP kernel - was
MmMapLockedPages… on
> XP vs. 2000
>
>
> >
> > xxxxx@osr.com said:
> > > Remember that one of the changes from Win2K to XP/.NET was a fix
> > > whereby memory mappings must be consistent with regard to cache
type.
> >
> > xxxxx@osr.com said:
> > > I think Mr. Partelly has hit upon your solution,
> >
> > But I created these pages with AllocateCommonBuffer, and the
> > CachEnabled parameter set to FALSE. Then I only get this symptom
> > when I pass MmNonCached to MmMapLockedPagesSpecifyCached. That
> > is consistent, is it not?
> >
> > Also, the exception is not tossed every time, only once in a
while.
> > Maybe every 10-20 attempts? And at that it depends on the size of
> > the frame I’m allocating. On some tests with smaller frames, I’ve
> > seen no error at all, for example.
> >
> > I really don’t want the memory cached in the user mode, because
> > it is shared with a PCI device. That’s the whole point of all
this.
> > –
> > Steve Williams “The woods are lovely, dark and
deep.
> > steve at icarus.com But I have promises to keep,
> > steve at picturel.com and lines to code before I sleep,
> > http://www.picturel.com And lines to code before I sleep.”
> >
> > abuse@xo.com
> > xxxxx@ftc.gov
> >
> >
> >
> > —
> > 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@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
xxxxx@storagecraft.com said:
Even if you have kseg0 and large pages, you can ask
AllocateCommonBuffer to create a noncached buffer. In this case, it
will allocate system PTEs to point to the pages and will set them as
noncached. kseg0 address for the buffer will not be used.
It turns out not to be the case. I called Micro$oft on this one, and
as was guessed on this list, HalAllocateCommonBuffer, even through
AllocateCommonBuffer, ignores the “non-cached” flag. It always gives
a cached mapping.
At least, that’s the party line from Redmond.
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
Wow! You are correct, this flag is completely ignored.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Stephen Williams
Sent: Friday, June 21, 2002 9:36 AM
To: NT Developers Interest List
Subject: [ntdev] Re: posible bug in XP kernel - was MmMapLockedPages…
on XP vs. 2000
xxxxx@storagecraft.com said:
Even if you have kseg0 and large pages, you can ask
AllocateCommonBuffer to create a noncached buffer. In this case, it
will allocate system PTEs to point to the pages and will set them as
noncached. kseg0 address for the buffer will not be used.
It turns out not to be the case. I called Micro$oft on this one, and
as was guessed on this list, HalAllocateCommonBuffer, even through
AllocateCommonBuffer, ignores the “non-cached” flag. It always gives
a cached mapping.
At least, that’s the party line from Redmond.
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
>> as was guessed on this list, HalAllocateCommonBuffer, even through
Really it wasnt a guess =). Not even a educated one. I used a debugger.
But Max is right on the basic problem as described. I was wrong abt. 4mb
pages. HalAllocateCommonBuffer simply ignores the parameter, its not linked
to this issue.
The Mm manager itself seems to be capable to honor such a non-cached
request, by unlinking some pages
from the zeroed or free physicall page list and subsequently MmMapIoSpace,
which will reserve fresh
system PTEs. (this is very grosso modo explanation)
Thats beeing said, What said Redmond ? Any explanation why they decided to
ignore NonCached in HalAllocateCommonbuffer and brothers ?
----- Original Message -----
From: “Stephen Williams”
To: “NT Developers Interest List”
Sent: Friday, June 21, 2002 7:35 PM
Subject: [ntdev] Re: posible bug in XP kernel - was MmMapLockedPages… on
XP vs. 2000
>
> xxxxx@storagecraft.com said:
> > Even if you have kseg0 and large pages, you can ask
> > AllocateCommonBuffer to create a noncached buffer. In this case, it
> > will allocate system PTEs to point to the pages and will set them as
> > noncached. kseg0 address for the buffer will not be used.
>
> It turns out not to be the case. I called Micro$oft on this one, and
> as was guessed on this list, HalAllocateCommonBuffer, even through
> AllocateCommonBuffer, ignores the “non-cached” flag. It always gives
> a cached mapping.
>
> At least, that’s the party line from Redmond.
> –
> Steve Williams “The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> steve at picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
> abuse@xo.com
> xxxxx@ftc.gov
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
xxxxx@rdsor.ro said:
Thats beeing said, What said Redmond ? Any explanation why they
decided to ignore NonCached in HalAllocateCommonbuffer and brothers ?
Performance. The idea is that since PCI bus mastering devices will
implicitly invalidate the cached memory anyhow (snooping) there is
no reason to map the memory non-cached in the processor. Therefore,
it silently ignored the flag.
Never mind that that caused MmMapLockedPagesSpecifyCache to behave
sporadically. Interesting to note, however, that MmMapLockedPages
*does* mark it as cached, so that it consistent with AllocateCommon…
behavior.
–
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
> > Even if you have kseg0 and large pages, you can ask
> AllocateCommonBuffer to create a noncached buffer. In this case,
it
> will allocate system PTEs to point to the pages and will set them
as
> noncached. kseg0 address for the buffer will not be used.It turns out not to be the case. I called Micro$oft on this one, and
as was guessed on this list, HalAllocateCommonBuffer, even through
AllocateCommonBuffer, ignores the “non-cached” flag. It always gives
a cached mapping.
Sorry, at least MmAllocateNonCachedMemory works as I described.
BTW - MmAllocateNonCachedMemory and MmAllocateContiguousMemory APIs
are strange a bit. Am I wrong that AllocateCommonBuffer must be used
instead in nearly all cases? What is the need in having noncached or
physically contiguous RAM except for DMA?
Max
> Thats beeing said, What said Redmond ? Any explanation why they
decided to
ignore NonCached in HalAllocateCommonbuffer and brothers ?
I can only suspect that this is because x86 platforms provide
cache/DMA coherency in hardware.
On non-x86 machines, HalAllocateCommonbuffer possibly honors the
NonCached parameter.
Max
Steven,
As a last suggestion, which is rather a generic suggestion then linked pnly
to this subject, Id say you should always run your drivers on a XP system
which has the driver verifier enabled. This is a very good driver
“debugging” practice anyway, and can not harm. I use this toy all the time.
Is wonderfull. MS did a good job with the driver verifier, and the toy is
able to catch many many errors and instantly throw some light on the
problem.
For example , in your particular situation, the driver verifier would
instantly bugcheck the system with a bugcheck code of
DRIVER_VERIFIER_DETECTED_VIOLATION , with P1 = 0x8A, which is clearly
documented in Windbg help on bugcodes as a cache coherency problem
associated witn MmMapLockedPagesXxxx The help file is pretty clear regarding
the bugchecks cause by the driver verifier, and full of meaninfull
information. It would also help us, the other ppl on the list, to track down
faster the roots of a problem.
Best regards and good luck, Dan