linux-kernel - Re: [PATCH] x86_32: trim memory by updating e820 v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Apr 2008 16:11:33 +0200
From:	Mika Fischer <mika.fischer@...pnet.de>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Gabriel C <nix.or.die@...glemail.com>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jesse.barnes@...el.com>, balajirrao@...il.com,
	Andi Kleen <andi@...stfloor.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v3

Hi Ingo,

I'm having the same problem.

Ingo Molnar schrieb:
> excellent. So just to make sure: this box never had proper graphics 
> under Linux (under no previous kernel), due to the way the BIOS has set 
> up the MTRR's, right?

Well, not quite. X still works fine, but since the video memory is
overlapped by two of the existing MTRRs, X cannot add a write-combining
range for the video memory. That makes X rather slow especially if you
use DRI for Compiz etc.

And this always happens with 4GB RAM, but not with 2GB RAM.

So yes, with this patch for the first time X works at normal speed with
4GB of RAM out of the box.

> so fixing up the MTRRs during bootup, no matter how dangerous in theory, 
> is pretty much the best option to get your system to work fine under 
> Linux, with that specific Xorg version?

Yes. That's what I'm doing at the moment with a shell script. :)

> i think we should still try to make this a non-default option because 
> modern Xorg should not have any need to touch MTRRs. Perhaps a .config 
> dependent on CONFIG_DANGEROUS ;-)

AFAICT X always tries to set up a write-combining range for the video
memory. And this will always fail if there are erroneous write-back or
even uncachable ranges overlapping the video memory...

But I don't know if this has changed in newer versions of Xorg (I'm
using 7.3).

In any case if I have a range in /proc/mtrr that is declared uncachable
and overlaps my video memory (which is the case without this patch),
is there even anything Xorg can do to make the video-memory use
write-combining?

Regards,
 Mika
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/