Messages in this thread | | | Date | Thu, 08 May 2008 16:54:44 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error |
| |
Venki Pallipadi wrote: > On Thu, May 08, 2008 at 02:59:31PM -0700, Venkatesh Pallipadi wrote: >>> >> I agree we need a better range check in place. But, the current one was not >> really doing anything useful and actually causing the side-effect >> regression. So, I felt not having it is better solution for now. >> >> Other solution is to stay with start and end range check and just ignore the >> range check error with WC overlap in case where UC_MINUS is requested. >> >> Given the way MTRRs are defined, the only way to do the full range check >> seems to be to go over page by page (from start to end), and check which >> variable range MTTR it matches with, which is obviously very excessive. As, >> this is not a problem in typical usage scenario. >>
I don't believe that is true in the slightest. You can iterate over the variable MTRRs and see if any part of them overlaps the target range; doing exhaustive enumeration is clearly bogus, especially on 64-bit platforms.
> > Also, note that we only look for start while looking at fixed range MTRRs. > This is not as scary as it seems. We are finding the effective memory type > by just looking at the start of the address range. We still go through > the PAT reserve free mechanism, once we find the effective memory type > and that list will catch any other users with conflicting type anywhere > in the start to end range. And we will still keep effective type consistent > across all mappings. >
So what you're saying here is "it's bogus, but it doesn't really matter anyway?" Why bother having it at all, then?
Seriously, if it's not unconditionally correct, then:
a. it should be *clearly* labelled a heuristic. b. it should be *clearly* explained why having the heuristic is much better than not having anything.
In this case, neither of those conditions appear to be addressed.
-hpa
| |