Date: Thu, 4 Sep 2008 04:02:15 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: David Malone <dwmalone@maths.tcd.ie> Cc: Bernd Walter <ticso@cicely7.cicely.de>, freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: MTRR fixup? Message-ID: <20080904020215.GB15328@cicely7.cicely.de> In-Reply-To: <20080904015507.GA15328@cicely7.cicely.de> References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <20080903234642.GA14659@cicely7.cicely.de> <20080904015507.GA15328@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 04, 2008 at 03:55:07AM +0200, Bernd Walter wrote: > On Thu, Sep 04, 2008 at 01:46:42AM +0200, Bernd Walter wrote: > > On Wed, Sep 03, 2008 at 09:47:59PM +0100, David Malone wrote: > > > On Wed, Sep 03, 2008 at 05:49:44AM +0200, Bernd Walter wrote: > > > > Some boards (including my Intel DG33BU) seem to have problems setting > > > > up the mtrr to cache all RAM. > > > > My system runs fast with 2G and ist about 6 times slower in buildworld > > > > with 6G RAM. > > > > I will try a BIOS update once Intels tells me why their update ISO > > > > just turn the system off instead of updating the BIOS - sigh. > > > > But it seems that Linux is doing some kind of fixup for MTRR: > > > > http://lkml.org/lkml/2008/1/18/170 > > > > Can we do something similar? > > > > > > You may be able to fix this by just using the memcontrol command - > > > it already lets you program the MTRRs. > > > > Oh damn - a new fancy tool to play with ;-) > > > > Interesting - the values look good: > > [...] > > 0x0/0x80000000 ticso write-back active > > 0x80000000/0x40000000 ticso write-back active > > 0xc0000000/0x10000000 ticso write-back active > > 0xcf800000/0x800000 BIOS uncacheable set-by-firmware active > > 0xcf400000/0x400000 BIOS uncacheable set-by-firmware active > > 0x100000000/0x80000000 ticso write-back active > > 0x180000000/0x20000000 ticso write-back active > > 0x0/0x1000000000 - uncacheable > > Ok - there it is - something is missing: > ram0 > I/O memory addresses: > 0x0-0x9c3ff > 0x100000-0xcf212fff > 0xcf215000-0xcf2fafff > 0xcf3e5000-0xcf3e8fff > 0xcf3f2000-0xcf3f2fff > 0xcf3ff000-0xcf3fffff > 0x100000000-0x1abffffff > > ram goes up to 0x1abffffff mtrr just goes up to 0x1a0000000 - 1, so the > last 192MB are uncached. > But memcontrol complains when trying to add the range: > [55]cicely14# memcontrol set -b 0x1a0000000 -l 0xc000000 -o ticso write-back > memcontrol: can't set range: Invalid argument Ok - I more or less got it. I have to set 2^n ranges. The first one goes: [56]cicely14# memcontrol set -b 0x1a0000000 -l 0x8000000 -o ticso write-back The second not: [57]cicely14# memcontrol set -b 0x1a8000000 -l 0x4000000 -o ticso write-back memcontrol: can't set range: No space left on device Exit 1 But this is exactly my problem, because if I only set the second one the board instantly speeds up. Something important of the system must be in the last 64MB. Nevertheless I can't use memcontrol to setup everything as cacheable. I could set hw.phymem to get the kernel below the last 64MB or maybe even the last 192MB. If someone has an idea on how to set both ranges... But anyway: Thank you all - this was very usefull, since I can now get almost all memory without massive performance penalty. -- B.Walter <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080904020215.GB15328>