> > 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 im
* 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 not
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
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 pa
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, and
> (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 PR
* 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
> MT
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 priori
> 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 to
> 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 "unsubscri
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
* 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
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
> equall
> >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 areas t
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 wi
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 becau
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 wro
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?
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 n
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 start
27 matches
Mail list logo
