> > I think it should be enabled on AMD too though. If the reordering breaks
> > it then blacklisting won't help anyways.
Actually it is already enabled on AMD. You check for is_cpu(INTEL)
but that just checks the generic MTRR architecture and all AMD CPUs
since K7 use that one too.
That is ok
* Dave Jones <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 05:50:41PM -0500, [EMAIL PROTECTED] wrote:
>
> > (Personally, I keep a copy of Arjan's "restrict devmem" patch from Fedora
> > around, so I guess that says which camp I belong in, and the fact it's a
> Fedora
> > patch and
On Friday, January 18, 2008 10:12 am Andi Kleen wrote:
> I looked back then when I had bisected it down and I admit I didn't spot
> the problem from source review. I think it came from the reordering so
> blacklisting AMD alone wouldn't have helped. Might have been some
> subtle race (e.g. long
On Thu, Jan 10, 2008 at 05:50:41PM -0500, [EMAIL PROTECTED] wrote:
> (Personally, I keep a copy of Arjan's "restrict devmem" patch from Fedora
> around, so I guess that says which camp I belong in, and the fact it's a
> Fedora
> patch and not mainstream says something too...)
The way that
On Fri, Jan 18, 2008 at 08:46:02AM -0800, Jesse Barnes wrote:
> On Friday, January 18, 2008 5:12 am Andi Kleen wrote:
> > > (AMD machines apparently don't need it
> >
> > That's not true -- we had AMD systems in the past with broken MTRRs for
> > large memory configurations too, Mostly it was pre
On Friday, January 18, 2008 5:12 am Andi Kleen wrote:
> > (AMD machines apparently don't need it
>
> That's not true -- we had AMD systems in the past with broken MTRRs for
> large memory configurations too, Mostly it was pre revE though.
It should be easy enough to enable it for AMD as well,
> (AMD machines apparently don't need it
That's not true -- we had AMD systems in the past with broken MTRRs for
large memory configurations too, Mostly it was pre revE though.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > ok. So it seems we dont even need all that many special cases, a
> > "dont write MTRRs" and "use PATs everywhere" rule would just do the
> > right thing all across?
>
> Yes. The main thing required is on the lines of Jesse's patch. If the
>
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
ok. So it seems we dont even need all that many special cases, a
dont write MTRRs and use PATs everywhere rule would just do the
right thing all across?
Yes. The main thing required is on the lines of Jesse's patch. If the
MTRR's def type
On Friday, January 18, 2008 5:12 am Andi Kleen wrote:
(AMD machines apparently don't need it
That's not true -- we had AMD systems in the past with broken MTRRs for
large memory configurations too, Mostly it was pre revE though.
It should be easy enough to enable it for AMD as well, and it
I think it should be enabled on AMD too though. If the reordering breaks
it then blacklisting won't help anyways.
Actually it is already enabled on AMD. You check for is_cpu(INTEL)
but that just checks the generic MTRR architecture and all AMD CPUs
since K7 use that one too.
That is ok imho.
On Fri, Jan 18, 2008 at 08:46:02AM -0800, Jesse Barnes wrote:
On Friday, January 18, 2008 5:12 am Andi Kleen wrote:
(AMD machines apparently don't need it
That's not true -- we had AMD systems in the past with broken MTRRs for
large memory configurations too, Mostly it was pre revE
(AMD machines apparently don't need it
That's not true -- we had AMD systems in the past with broken MTRRs for
large memory configurations too, Mostly it was pre revE though.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Thu, Jan 10, 2008 at 05:50:41PM -0500, [EMAIL PROTECTED] wrote:
(Personally, I keep a copy of Arjan's restrict devmem patch from Fedora
around, so I guess that says which camp I belong in, and the fact it's a
Fedora
patch and not mainstream says something too...)
The way that patch
On Friday, January 18, 2008 10:12 am Andi Kleen wrote:
I looked back then when I had bisected it down and I admit I didn't spot
the problem from source review. I think it came from the reordering so
blacklisting AMD alone wouldn't have helped. Might have been some
subtle race (e.g. long ago we
On Tue, Jan 15, 2008 at 11:17:58PM +0100, Ingo Molnar wrote:
>
> * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > Time to resurrect Jesse's old patches
> > i386-trim-memory-not-covered-by-wb-mtrrs.patch(which was in -mm
> > sometime back)
>
> just to make sure i understood the attribute
> just to make sure i understood the attribute priorities right: we cannot
> just mark it WB in the PAT and expect it to be write-back - the UC of
> the MTRR will control?
There are different kinds of UC: UC+ and UC-. One controls the other doesn't.
-Andi
--
To unsubscribe from this list: send
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 14, 2008 at 05:43:24PM +0100, Ingo Molnar wrote:
> >
> > * Pallipadi, Venkatesh <[EMAIL PROTECTED]> wrote:
> >
> > > Also, relying on MTRR, is like giving more importance to BIOS writer
> > > than required :-). I think the best way
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
On Mon, Jan 14, 2008 at 05:43:24PM +0100, Ingo Molnar wrote:
* Pallipadi, Venkatesh [EMAIL PROTECTED] wrote:
Also, relying on MTRR, is like giving more importance to BIOS writer
than required :-). I think the best way to deal with MTRR
just to make sure i understood the attribute priorities right: we cannot
just mark it WB in the PAT and expect it to be write-back - the UC of
the MTRR will control?
There are different kinds of UC: UC+ and UC-. One controls the other doesn't.
-Andi
--
To unsubscribe from this list: send
On Tue, Jan 15, 2008 at 11:17:58PM +0100, Ingo Molnar wrote:
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
Time to resurrect Jesse's old patches
i386-trim-memory-not-covered-by-wb-mtrrs.patch(which was in -mm
sometime back)
just to make sure i understood the attribute priorities right:
> Time to resurrect Jesse's old patches
> i386-trim-memory-not-covered-by-wb-mtrrs.patch(which was in -mm sometime back)
They broke booting on my AMD QuadCore system here. Never quite figured
out what the problem was unfortunately.
-Andi
--
To unsubscribe from this list: send the line
On Mon, Jan 14, 2008 at 05:43:24PM +0100, Ingo Molnar wrote:
>
> * Pallipadi, Venkatesh <[EMAIL PROTECTED]> wrote:
>
> > Also, relying on MTRR, is like giving more importance to BIOS writer
> > than required :-). I think the best way to deal with MTRR is just to
> > not touch it. Leave it as
* Pallipadi, Venkatesh <[EMAIL PROTECTED]> wrote:
> Also, relying on MTRR, is like giving more importance to BIOS writer
> than required :-). I think the best way to deal with MTRR is just to
> not touch it. Leave it as it is and do not try to assume that they are
> correct, as frequently
* Pallipadi, Venkatesh [EMAIL PROTECTED] wrote:
Also, relying on MTRR, is like giving more importance to BIOS writer
than required :-). I think the best way to deal with MTRR is just to
not touch it. Leave it as it is and do not try to assume that they are
correct, as frequently they will
On Mon, Jan 14, 2008 at 05:43:24PM +0100, Ingo Molnar wrote:
* Pallipadi, Venkatesh [EMAIL PROTECTED] wrote:
Also, relying on MTRR, is like giving more importance to BIOS writer
than required :-). I think the best way to deal with MTRR is just to
not touch it. Leave it as it is and do
Time to resurrect Jesse's old patches
i386-trim-memory-not-covered-by-wb-mtrrs.patch(which was in -mm sometime back)
They broke booting on my AMD QuadCore system here. Never quite figured
out what the problem was unfortunately.
-Andi
--
To unsubscribe from this list: send the line unsubscribe
On Thu, 10 Jan 2008 14:15:25 PST, Linus Torvalds said:
> Well, I think that /dev/mem should simply give them the right info. That's
> what people use /dev/mem for - doing things like reading BIOS images etc.
>
> So returning *either* a zero page *or* stopping at the first hole is both
>
> >Cc: Andi Kleen; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B
> >Subject: Re: [patch 02/11] PAT x86:
IL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; Barnes, Jesse; [EMAIL PROTECTED];
>linux-kernel@vger.kernel.org; Siddha, Suresh B
>Subject: RE: [patch 02/11] PAT x86: Map only usable memory in
>x86_64 identity map and kernel text
>
>
>
>On
EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B
>Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
>x86_64 identity map and kernel text
>
>> I think it is unsafe to access any reserved are
On Thu, 10 Jan 2008, Pallipadi, Venkatesh wrote:
>
> Yes. I had those pages not mapped at all earlier. The reason I switched
> to zero page is to continue support cases like:
> BIOS-e820: - 0009cc00 (usable)
> BIOS-e820: 0009cc00 - 000a (reserved)
IL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; Barnes, Jesse;
>[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B
>Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
>x86_64 identity map and kernel text
>
>
&
> I think it is unsafe to access any reserved areas through "WB" not just
> mmio regions. In the above case 0xe000-0xf000 is one such
> region.
That is 2MB aligned.
>
> Also, relying on MTRR, is like giving more importance to BIOS writer
Let's call it double checking.
Besides MTRRs
On Thu, 10 Jan 2008, [EMAIL PROTECTED] wrote:
>
> x86_64: Map only usable memory in identity map. All reserved memory maps to a
> zero page.
I don't mind this horribly per se, but why a zero page?
Accessing that page without mapping it explicitly would be a bug with
your change - if only
ED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED];
>linux-kernel@vger.kernel.org; Siddha, Suresh B
>Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
>x86_64 identity map and kernel text
>
>On Thu, Jan 10, 2008 at 11:17:07AM -0800, Pallipadi, Venkatesh
On Thu, Jan 10, 2008 at 11:17:07AM -0800, Pallipadi, Venkatesh wrote:
> >I don't think that is needed or makes sense for reserved/ACPI * etc.
> >Only e820 holes should be truly unmapped because only those should
> >contain mmio.
>
> Do you mean just the regions that are not listed in e820 at
ECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED];
>linux-kernel@vger.kernel.org; Siddha, Suresh B
>Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
>x86_64 identity map and kernel text
>
>[EMAIL PROTECTED] writes:
>
>> x8
[EMAIL PROTECTED] writes:
> x86_64: Map only usable memory in identity map.
I don't think that is needed or makes sense for reserved/ACPI * etc.
Only e820 holes should be truly unmapped because only those should
contain mmio.
> All reserved memory maps to a
> zero page.
Why zero page? Why
x86_64: Map only usable memory in identity map. All reserved memory maps to a
zero page. This is done later during the boot process, by pruning the
page table setup earlier to remove mappings for the reserved region. Prune
done after mem_init, so we can allocate pages as needed and before APs
x86_64: Map only usable memory in identity map. All reserved memory maps to a
zero page. This is done later during the boot process, by pruning the
page table setup earlier to remove mappings for the reserved region. Prune
done after mem_init, so we can allocate pages as needed and before APs
[EMAIL PROTECTED] writes:
x86_64: Map only usable memory in identity map.
I don't think that is needed or makes sense for reserved/ACPI * etc.
Only e820 holes should be truly unmapped because only those should
contain mmio.
All reserved memory maps to a
zero page.
Why zero page? Why not
PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; Siddha, Suresh B
Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
x86_64 identity map and kernel text
[EMAIL PROTECTED] writes:
x86_64: Map only usable memory in identity map.
I don't think
On Thu, Jan 10, 2008 at 11:17:07AM -0800, Pallipadi, Venkatesh wrote:
I don't think that is needed or makes sense for reserved/ACPI * etc.
Only e820 holes should be truly unmapped because only those should
contain mmio.
Do you mean just the regions that are not listed in e820 at all? We
];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; Siddha, Suresh B
Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
x86_64 identity map and kernel text
On Thu, Jan 10, 2008 at 11:17:07AM -0800, Pallipadi, Venkatesh wrote:
I don't think that is needed or makes sense
On Thu, 10 Jan 2008, [EMAIL PROTECTED] wrote:
x86_64: Map only usable memory in identity map. All reserved memory maps to a
zero page.
I don't mind this horribly per se, but why a zero page?
Accessing that page without mapping it explicitly would be a bug with
your change - if only because
I think it is unsafe to access any reserved areas through WB not just
mmio regions. In the above case 0xe000-0xf000 is one such
region.
That is 2MB aligned.
Also, relying on MTRR, is like giving more importance to BIOS writer
Let's call it double checking.
Besides MTRRs will not
PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Barnes, Jesse;
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B
Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
x86_64 identity map and kernel text
On Thu, 10 Jan 2008, [EMAIL PROTECTED] wrote:
x86_64
On Thu, 10 Jan 2008, Pallipadi, Venkatesh wrote:
Yes. I had those pages not mapped at all earlier. The reason I switched
to zero page is to continue support cases like:
BIOS-e820: - 0009cc00 (usable)
BIOS-e820: 0009cc00 - 000a (reserved)
PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B
Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
x86_64 identity map and kernel text
I think it is unsafe to access any reserved areas through
WB not just
mmio regions. In the above case
PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Barnes, Jesse; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; Siddha, Suresh B
Subject: RE: [patch 02/11] PAT x86: Map only usable memory in
x86_64 identity map and kernel text
On Thu, 10 Jan 2008, Pallipadi, Venkatesh wrote:
Yes. I had those
PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B
Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
x86_64 identity map and kernel text
I think it is unsafe
On Thu, 10 Jan 2008 14:15:25 PST, Linus Torvalds said:
Well, I think that /dev/mem should simply give them the right info. That's
what people use /dev/mem for - doing things like reading BIOS images etc.
So returning *either* a zero page *or* stopping at the first hole is both
equally
53 matches
Mail list logo
