Siddha, Suresh B wrote:
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
So now I have this, which is pretty much
what
I wanted:
reg00: base=0x ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1
reg02:
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
> Hi, was wondering if anyone else has been tripped up by this... I've got
> 4GB of
> RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
> default, my system boots up with these MTRR settings:
>
> reg00:
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
Hi, was wondering if anyone else has been tripped up by this... I've got
4GB of
RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
default, my system boots up with these MTRR settings:
reg00: base=0x
Siddha, Suresh B wrote:
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
So now I have this, which is pretty much
what
I wanted:
reg00: base=0x ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1
reg02:
On Thursday, September 20, 2007, Jesse Barnes wrote:
> On Wednesday, September 19, 2007 11:50:23 pm Andi Kleen wrote:
> > Jesse Barnes <[EMAIL PROTECTED]> writes:
> > > To do this in a nicer way (and be less vulnerable to similar BIOS
> > > funkiness) the kernel really needs full PAT support.
On Wednesday, September 19, 2007 11:50:23 pm Andi Kleen wrote:
> Jesse Barnes <[EMAIL PROTECTED]> writes:
> > To do this in a nicer way (and be less vulnerable to similar BIOS
> > funkiness) the kernel really needs full PAT support. That should allow
> > WC over WB and WC over UC mappings to
Andi Kleen wrote:
Is there any reason not to set the MTRRs to define the entire memory as
write back, and use PAT exclusively for setting cacheability?
That risks breaking SMM or BIOS code.
Yes. Too bad.
--
error compiling committee.c: too many arguments to function
-
To
> Is there any reason not to set the MTRRs to define the entire memory as
> write back, and use PAT exclusively for setting cacheability?
That risks breaking SMM or BIOS code.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Andi Kleen wrote:
Jesse Barnes <[EMAIL PROTECTED]> writes:
To do this in a nicer way (and be less vulnerable to similar BIOS
funkiness) the kernel really needs full PAT support. That should allow
WC over WB and WC over UC mappings to occur, at least if I'm
remembering the docs right...
Jesse Barnes <[EMAIL PROTECTED]> writes:
>
> To do this in a nicer way (and be less vulnerable to similar BIOS
> funkiness) the kernel really needs full PAT support. That should allow
> WC over WB and WC over UC mappings to occur, at least if I'm
> remembering the docs right...
PAT only
Jesse Barnes [EMAIL PROTECTED] writes:
To do this in a nicer way (and be less vulnerable to similar BIOS
funkiness) the kernel really needs full PAT support. That should allow
WC over WB and WC over UC mappings to occur, at least if I'm
remembering the docs right...
PAT only really
Andi Kleen wrote:
Jesse Barnes [EMAIL PROTECTED] writes:
To do this in a nicer way (and be less vulnerable to similar BIOS
funkiness) the kernel really needs full PAT support. That should allow
WC over WB and WC over UC mappings to occur, at least if I'm
remembering the docs right...
Is there any reason not to set the MTRRs to define the entire memory as
write back, and use PAT exclusively for setting cacheability?
That risks breaking SMM or BIOS code.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Andi Kleen wrote:
Is there any reason not to set the MTRRs to define the entire memory as
write back, and use PAT exclusively for setting cacheability?
That risks breaking SMM or BIOS code.
Yes. Too bad.
--
error compiling committee.c: too many arguments to function
-
To
On Thursday, September 20, 2007, Jesse Barnes wrote:
On Wednesday, September 19, 2007 11:50:23 pm Andi Kleen wrote:
Jesse Barnes [EMAIL PROTECTED] writes:
To do this in a nicer way (and be less vulnerable to similar BIOS
funkiness) the kernel really needs full PAT support. That should
On Friday, September 14, 2007 9:33 am Howard Chu wrote:
> So the question is - was there an easier/correct way to do this?
>
> It might have been nice if the MTRR ioctls allowed the register
> number to be specified on the Set commands, though I'm not sure that
> would have helped in this case.
On Friday, September 14, 2007 9:33 am Howard Chu wrote:
So the question is - was there an easier/correct way to do this?
It might have been nice if the MTRR ioctls allowed the register
number to be specified on the Set commands, though I'm not sure that
would have helped in this case.
To do
Howard Chu <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> but Andi and Eric said resetting mtrr is not good... when someone from
>>> intel try to trim the MTRR for intel CPU.
>>
>> There are a couple issues with changing the MTRR configuration.
>> - You may not have perfect
Eric W. Biederman wrote:
but Andi and Eric said resetting mtrr is not good... when someone from
intel try to trim the MTRR for intel CPU.
There are a couple issues with changing the MTRR configuration.
- You may not have perfect information on the cpu, the AMD revF is a good
example.
- Code
Howard Chu [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
but Andi and Eric said resetting mtrr is not good... when someone from
intel try to trim the MTRR for intel CPU.
There are a couple issues with changing the MTRR configuration.
- You may not have perfect information on the cpu,
Eric W. Biederman wrote:
but Andi and Eric said resetting mtrr is not good... when someone from
intel try to trim the MTRR for intel CPU.
There are a couple issues with changing the MTRR configuration.
- You may not have perfect information on the cpu, the AMD revF is a good
example.
- Code
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 9/16/07, Howard Chu <[EMAIL PROTECTED]> wrote:
>> Yinghai Lu wrote:
>> > On 9/14/07, Howard Chu <[EMAIL PROTECTED]> wrote:
>> >> Hi, was wondering if anyone else has been tripped up by this... I've got
> 4GB of
>> >> RAM in my Asus A8V Deluxe and
On 9/16/07, Howard Chu <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > On 9/14/07, Howard Chu <[EMAIL PROTECTED]> wrote:
> >> Hi, was wondering if anyone else has been tripped up by this... I've got
> >> 4GB of
> >> RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
> >>
Yinghai Lu wrote:
On 9/14/07, Howard Chu <[EMAIL PROTECTED]> wrote:
Hi, was wondering if anyone else has been tripped up by this... I've got 4GB of
RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
default, my system boots up with these MTRR settings:
reg00:
Yinghai Lu wrote:
On 9/14/07, Howard Chu [EMAIL PROTECTED] wrote:
Hi, was wondering if anyone else has been tripped up by this... I've got 4GB of
RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
default, my system boots up with these MTRR settings:
reg00:
On 9/16/07, Howard Chu [EMAIL PROTECTED] wrote:
Yinghai Lu wrote:
On 9/14/07, Howard Chu [EMAIL PROTECTED] wrote:
Hi, was wondering if anyone else has been tripped up by this... I've got
4GB of
RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
default, my system
Yinghai Lu [EMAIL PROTECTED] writes:
On 9/16/07, Howard Chu [EMAIL PROTECTED] wrote:
Yinghai Lu wrote:
On 9/14/07, Howard Chu [EMAIL PROTECTED] wrote:
Hi, was wondering if anyone else has been tripped up by this... I've got
4GB of
RAM in my Asus A8V Deluxe and memory hole mapping enabled
On 9/14/07, Howard Chu <[EMAIL PROTECTED]> wrote:
> Hi, was wondering if anyone else has been tripped up by this... I've got 4GB
> of
> RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
> default, my system boots up with these MTRR settings:
>
> reg00: base=0x (
Hi, was wondering if anyone else has been tripped up by this... I've got 4GB of
RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
default, my system boots up with these MTRR settings:
reg00: base=0x ( 0MB), size=4096MB: write-back, count=1
reg01:
Hi, was wondering if anyone else has been tripped up by this... I've got 4GB of
RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
default, my system boots up with these MTRR settings:
reg00: base=0x ( 0MB), size=4096MB: write-back, count=1
reg01:
On 9/14/07, Howard Chu [EMAIL PROTECTED] wrote:
Hi, was wondering if anyone else has been tripped up by this... I've got 4GB
of
RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
default, my system boots up with these MTRR settings:
reg00: base=0x ( 0MB),
On Wed, 20 Jun 2007, Andi Kleen wrote:
>
> From: Andrea Righi <[EMAIL PROTECTED]>
>
> BUG: at include/linux/slub_def.h:77 kmalloc_index()
This was never a bug, and should have been named a warning. It's also gone
in the current source-tree, since we instead of warning now just return
From: Andrea Righi <[EMAIL PROTECTED]>
BUG: at include/linux/slub_def.h:77 kmalloc_index()
[] get_slab+0x1d0/0x260
[] __kmalloc+0x16/0x70
[] sysenter_setup+0x6f/0x330
[] mtrr_bp_init+0xcd/0x270
[] unknown_bootoption+0x0/0x250
[] unknown_bootoption+0x0/0x250
[] check_bugs+0x8/0x160
[]
From: Andrea Righi [EMAIL PROTECTED]
BUG: at include/linux/slub_def.h:77 kmalloc_index()
[c0168eb0] get_slab+0x1d0/0x260
[c0169056] __kmalloc+0x16/0x70
[c042b0ff] sysenter_setup+0x6f/0x330
[c010baed] mtrr_bp_init+0xcd/0x270
[c041a480] unknown_bootoption+0x0/0x250
[c041a480]
On Wed, 20 Jun 2007, Andi Kleen wrote:
From: Andrea Righi [EMAIL PROTECTED]
BUG: at include/linux/slub_def.h:77 kmalloc_index()
This was never a bug, and should have been named a warning. It's also gone
in the current source-tree, since we instead of warning now just return
BUG: at include/linux/slub_def.h:77 kmalloc_index()
[] get_slab+0x1d0/0x260
[] __kmalloc+0x16/0x70
[] sysenter_setup+0x6f/0x330
[] mtrr_bp_init+0xcd/0x270
[] unknown_bootoption+0x0/0x250
[] unknown_bootoption+0x0/0x250
[] check_bugs+0x8/0x160
[] proc_sys_init+0xc/0x30
[]
BUG: at include/linux/slub_def.h:77 kmalloc_index()
[c0168eb0] get_slab+0x1d0/0x260
[c0169056] __kmalloc+0x16/0x70
[c042b0ff] sysenter_setup+0x6f/0x330
[c010baed] mtrr_bp_init+0xcd/0x270
[c041a480] unknown_bootoption+0x0/0x250
[c041a480] unknown_bootoption+0x0/0x250
[c0423f78]
37 matches
Mail list logo
