[lkml]   [2003]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: no more MTRRs available ?
On Wed, Jan 29, 2003 at 10:00:11AM -0800, William Lee Irwin III wrote:

> >> reg00: base=0xc0000000 (49152MB), size=16384MB: uncachable, count=1
> >> reg01: base=0x00000000 ( 0MB), size=524288MB: write-back, count=1
> >> reg02: base=0x800000000 (524288MB), size=262144MB: write-back, count=1
> >> Yes, this is standard ia32 (P-III/Coppermine cpus), and hence the
> >> numbers here are utter garbage.
> On Wed, Jan 29, 2003 at 05:48:42PM +0000, Dave Jones wrote:
> > Bizarre. The size field isn't being shifted, and your base is somewhere
> > off in 64bit land.
> > See Andi's "RED-PEN" comments in various parts of arch/i386/kernel/cpu/mtrr/
> > They need fixing at some point, and could be the cause of your problems.
> OTOH since 0-512GB are in there this explains why the (massive) perf.
> decrease only happens sometimes. The MTRR corruption issues are only
> visible with 48GB atm. I haven't been focusing on MTRR's but I may
> arrange to trace the codepaths etc. in the eventual future to find
> where the bits are going bad esp. as benchmark time approaches.

ohhh, 48GB. I forgot you were doing the silly-amounts-of-mem thing.
Its extremely likely you'll have to fix up those comments Andi made,
and possibly some other parts too. That code should be 64bit clean
now (due to x86-64 sharing it), but there may still be some gotchas,
especially on weird-ass systems like what you've been playing with 8)


| Dave Jones.
| SuSE Labs
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.063 / U:2.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site