lkml.org 
[lkml]   [2008]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-05-09 01:59    [W:0.436 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site