On Fri, 1 Jun 2007, Jesse Barnes wrote:
On Friday, June 1, 2007 6:05:39 Venki Pallipadi wrote:
On Fri, Jun 01, 2007 at 02:41:57PM -0700, Jesse Barnes wrote:
On Friday, June 1, 2007 2:19:43 Andi Kleen wrote:
And normally the MTRRs win, don't they (if I remember the table
correctly) So if the MTRR says UC and PAT disagrees it might not
actually help
I just checked, yes the MTRRs win for UC types. But it sounds like the
cases we're talking about are actually situations where there's no MTRR
coverage, so the default type is used. The manual doesn't specifically
call out how memory using the default type interacts with PAT, but it may
well be that it stays uncached if the default type is uncached. Again
that argues for fixing the MTRR mapping problem in some way.
I feel, having a silent/transparent workaround is not a good idea. With
that chances are BIOS bug will go unnoticed (having an error message in
dmesg may not get noticed either). Probably we should just panic at boot
with a
detailed message about the e820 mtrr discrepancy (which can be logged as
a BUG to BIOS provider) and suggest a temporary workaround of "mem=___".
That might be best, short of actually fixing the MTRRs...
Jesse
Indeed, at least it will inform the user of -what- is going on.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
