From: Helge Hafting <helge.hafting@aitel.hist.no>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Alexander Huemer <alexander.huemer@sbg.ac.at>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: 2.6.27 mtrr fixes do not work when X starts
Date: Tue, 26 Aug 2008 11:32:31 +0200 [thread overview]
Message-ID: <48B3CDAF.604@aitel.hist.no> (raw)
In-Reply-To: <86802c440808251308i609a1c8ay6a7300bf4d0e0758@mail.gmail.com>
Yinghai Lu wrote:
> please use "mtrr_spare_reg_nr=3 debug"
>
> you missed _nr.
>
Sorry. I got it right this time, and mtrr setup succeeded:
dmesg:
Command line: root=/dev/sda2 ro mtrr_spare_reg_nr=3 debug
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
Centaur CentaurHauls
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
BIOS-e820: 0000000000100000 - 000000007fe5a800 (usable)
BIOS-e820: 000000007fe5a800 - 0000000080000000 (reserved)
BIOS-e820: 00000000f8000000 - 00000000fc000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fed18000 - 00000000fed1c000 (reserved)
BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)
BIOS-e820: 00000000feda0000 - 00000000feda6000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
last_pfn = 0x7fe5a max_arch_pfn = 0x3ffffffff
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
total RAM coverred: 2047M
gran_size: 1M chunk_size: 1M num_reg: 8 lose RAM: 7M
gran_size: 1M chunk_size: 2M num_reg: 8 lose RAM: 7M
gran_size: 1M chunk_size: 4M num_reg: 8 lose RAM: 7M
gran_size: 1M chunk_size: 8M num_reg: 8 lose RAM: 7M
*BAD* gran_size: 1M chunk_size: 16M num_reg: 8 lose
RAM: -1M
gran_size: 1M chunk_size: 32M num_reg: 8 lose RAM: 0M
gran_size: 1M chunk_size: 64M num_reg: 7 lose RAM: 0M
gran_size: 1M chunk_size: 128M num_reg: 6 lose RAM: 0M
gran_size: 1M chunk_size: 256M num_reg: 5 lose RAM: 0M
gran_size: 1M chunk_size: 512M num_reg: 4 lose RAM: 0M
gran_size: 1M chunk_size: 1024M num_reg: 3 lose RAM: 0M
gran_size: 1M chunk_size: 2048M num_reg: 2 lose RAM: 0M
gran_size: 1M chunk_size: 4096M num_reg: 8 lose RAM: 7M
gran_size: 2M chunk_size: 2M num_reg: 8 lose RAM: 7M
gran_size: 2M chunk_size: 4M num_reg: 8 lose RAM: 7M
gran_size: 2M chunk_size: 8M num_reg: 8 lose RAM: 7M
*BAD* gran_size: 2M chunk_size: 16M num_reg: 8 lose
RAM: -1M
gran_size: 2M chunk_size: 32M num_reg: 8 lose RAM: 1M
gran_size: 2M chunk_size: 64M num_reg: 7 lose RAM: 1M
gran_size: 2M chunk_size: 128M num_reg: 6 lose RAM: 1M
gran_size: 2M chunk_size: 256M num_reg: 5 lose RAM: 1M
gran_size: 2M chunk_size: 512M num_reg: 4 lose RAM: 1M
gran_size: 2M chunk_size: 1024M num_reg: 3 lose RAM: 1M
gran_size: 2M chunk_size: 2048M num_reg: 2 lose RAM: 1M
gran_size: 2M chunk_size: 4096M num_reg: 8 lose RAM: 7M
gran_size: 4M chunk_size: 4M num_reg: 8 lose RAM: 7M
gran_size: 4M chunk_size: 8M num_reg: 8 lose RAM: 7M
*BAD* gran_size: 4M chunk_size: 16M num_reg: 8 lose RAM: -1M
gran_size: 4M chunk_size: 32M num_reg: 8 lose RAM: 3M
gran_size: 4M chunk_size: 64M num_reg: 7 lose RAM: 3M
gran_size: 4M chunk_size: 128M num_reg: 6 lose RAM: 3M
gran_size: 4M chunk_size: 256M num_reg: 5 lose RAM: 3M
gran_size: 4M chunk_size: 512M num_reg: 4 lose RAM: 3M
gran_size: 4M chunk_size: 1024M num_reg: 3 lose RAM: 3M
gran_size: 4M chunk_size: 2048M num_reg: 2 lose RAM: 3M
gran_size: 4M chunk_size: 4096M num_reg: 8 lose RAM: 7M
gran_size: 8M chunk_size: 8M num_reg: 8 lose RAM: 7M
gran_size: 8M chunk_size: 16M num_reg: 8 lose RAM: 7M
gran_size: 8M chunk_size: 32M num_reg: 8 lose RAM: 7M
gran_size: 8M chunk_size: 64M num_reg: 7 lose RAM: 7M
gran_size: 8M chunk_size: 128M num_reg: 6 lose RAM: 7M
gran_size: 8M chunk_size: 256M num_reg: 5 lose RAM: 7M
gran_size: 8M chunk_size: 512M num_reg: 4 lose RAM: 7M
gran_size: 8M chunk_size: 1024M num_reg: 3 lose RAM: 7M
gran_size: 8M chunk_size: 2048M num_reg: 2 lose RAM: 7M
gran_size: 8M chunk_size: 4096M num_reg: 8 lose RAM: 7M
gran_size: 16M chunk_size: 16M num_reg: 7 lose RAM: 15M
gran_size: 16M chunk_size: 32M num_reg: 7 lose RAM: 15M
gran_size: 16M chunk_size: 64M num_reg: 7 lose RAM: 15M
gran_size: 16M chunk_size: 128M num_reg: 6 lose RAM: 15M
gran_size: 16M chunk_size: 256M num_reg: 5 lose RAM: 15M
gran_size: 16M chunk_size: 512M num_reg: 4 lose RAM: 15M
gran_size: 16M chunk_size: 1024M num_reg: 3 lose RAM: 15M
gran_size: 16M chunk_size: 2048M num_reg: 2 lose RAM: 15M
gran_size: 16M chunk_size: 4096M num_reg: 7 lose RAM: 15M
gran_size: 32M chunk_size: 32M num_reg: 6 lose RAM: 31M
gran_size: 32M chunk_size: 64M num_reg: 6 lose RAM: 31M
gran_size: 32M chunk_size: 128M num_reg: 6 lose RAM: 31M
gran_size: 32M chunk_size: 256M num_reg: 5 lose RAM: 31M
gran_size: 32M chunk_size: 512M num_reg: 4 lose RAM: 31M
gran_size: 32M chunk_size: 1024M num_reg: 3 lose RAM: 31M
gran_size: 32M chunk_size: 2048M num_reg: 2 lose RAM: 31M
gran_size: 32M chunk_size: 4096M num_reg: 6 lose RAM: 31M
gran_size: 64M chunk_size: 64M num_reg: 5 lose RAM: 63M
gran_size: 64M chunk_size: 128M num_reg: 5 lose RAM: 63M
gran_size: 64M chunk_size: 256M num_reg: 5 lose RAM: 63M
gran_size: 64M chunk_size: 512M num_reg: 4 lose RAM: 63M
gran_size: 64M chunk_size: 1024M num_reg: 3 lose RAM: 63M
gran_size: 64M chunk_size: 2048M num_reg: 2 lose RAM: 63M
gran_size: 64M chunk_size: 4096M num_reg: 5 lose RAM: 63M
gran_size: 128M chunk_size: 128M num_reg: 4 lose RAM: 127M
gran_size: 128M chunk_size: 256M num_reg: 4 lose RAM: 127M
gran_size: 128M chunk_size: 512M num_reg: 4 lose RAM: 127M
gran_size: 128M chunk_size: 1024M num_reg: 3 lose RAM: 127M
gran_size: 128M chunk_size: 2048M num_reg: 2 lose RAM: 127M
gran_size: 128M chunk_size: 4096M num_reg: 4 lose RAM: 127M
gran_size: 256M chunk_size: 256M num_reg: 3 lose RAM: 255M
gran_size: 256M chunk_size: 512M num_reg: 3 lose RAM: 255M
gran_size: 256M chunk_size: 1024M num_reg: 3 lose RAM: 255M
gran_size: 256M chunk_size: 2048M num_reg: 2 lose RAM: 255M
gran_size: 256M chunk_size: 4096M num_reg: 3 lose RAM: 255M
gran_size: 512M chunk_size: 512M num_reg: 2 lose RAM: 511M
gran_size: 512M chunk_size: 1024M num_reg: 2 lose RAM: 511M
gran_size: 512M chunk_size: 2048M num_reg: 2 lose RAM: 511M
gran_size: 512M chunk_size: 4096M num_reg: 2 lose RAM: 511M
gran_size: 1024M chunk_size: 1024M num_reg: 1 lose RAM: 1023M
gran_size: 1024M chunk_size: 2048M num_reg: 1 lose RAM: 1023M
gran_size: 1024M chunk_size: 4096M num_reg: 1 lose RAM: 1023M
gran_size: 2048M chunk_size: 2048M num_reg: 0 lose RAM: 2047M
gran_size: 2048M chunk_size: 4096M num_reg: 0 lose RAM: 2047M
Found optimal setting for mtrr clean up
gran_size: 1M chunk_size: 256M num_reg: 5 lose RAM: 0M
range0: 0000000000000000 - 0000000070000000
Setting variable MTRR 0, base: 0MB, range: 1024MB, type WB
Setting variable MTRR 1, base: 1024MB, range: 512MB, type WB
Setting variable MTRR 2, base: 1536MB, range: 256MB, type WB
range: 0000000070000000 - 0000000080000000
Setting variable MTRR 3, base: 1792MB, range: 256MB, type WB
hole: 000000007ff00000 - 0000000080000000
Setting variable MTRR 4, base: 2047MB, range: 1MB, type UC
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
After WB checking
MTRR MAP PFN: 0000000000000000 - 0000000000080000
After UC checking
MTRR MAP PFN: 0000000000000000 - 000000000007ff00
After sorting
MTRR MAP PFN: 0000000000000000 - 000000000007ff00
init_memory_mapping
0000000000 - 007fe00000 page 2M
007fe00000 - 007fe5a000 page 4k
kernel direct mapping tables up to 7fe5a000 @ 8000-c000
last_map_addr: 7fe5a000 end: 7fe5a000
DMI 2.4 present.
Xorg.0.log:
(II) VESA(0): Primary V_BIOS segment is: 0xc000
(II) VESA(0): VESA BIOS detected
(II) VESA(0): VESA VBE Version 3.0
(II) VESA(0): VESA VBE Total Mem: 14336 kB
(II) VESA(0): VESA VBE OEM: NVIDIA
(II) VESA(0): VESA VBE OEM Software Rev: 96.134
(II) VESA(0): VESA VBE OEM Vendor: NVIDIA Corporation
(II) VESA(0): VESA VBE OEM Product: G86 Board - dawson0
(II) VESA(0): VESA VBE OEM Product Rev: Chip Rev
(II) VESA(0): Splitting WC range: base: 0xf3000000, size: 0xe00000
(II) VESA(0): Splitting WC range: base: 0xf3800000, size: 0x600000
(==) VESA(0): Write-combining range (0xf3c00000,0x200000)
(==) VESA(0): Write-combining range (0xf3800000,0x600000)
(==) VESA(0): Write-combining range (0xf3000000,0xe00000)
(II) VESA(0): virtual address = 0x7fe74b00e000,
physical address = 0xf3000000, size = 14680064
(==) VESA(0): Default visual is TrueColor
(==) VESA(0): Backing store disabled
$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
reg03: base=0x70000000 (1792MB), size= 256MB: write-back, count=1
reg04: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
reg05: base=0xf3c00000 (3900MB), size= 2MB: write-combining, count=1
reg06: base=0xf3800000 (3896MB), size= 4MB: write-combining, count=1
reg07: base=0xf3000000 (3888MB), size= 8MB: write-combining, count=1
This time X got its 3 regions, and no sluggishness when moving
opaque windows. :-)
I hope this helps so the extra bootup parameters can be avoided in the
release kernel.
Helge Hafting
next prev parent reply other threads:[~2008-08-26 9:32 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-06 14:05 2.6.27-rc1 mtrr fixes do not work Alexander Huemer
2008-08-07 20:14 ` Rafael J. Wysocki
2008-08-07 20:15 ` Pallipadi, Venkatesh
2008-08-07 20:23 ` Yinghai Lu
2008-08-07 20:26 ` Yinghai Lu
2008-08-07 22:14 ` Alexander Huemer
2008-08-07 23:16 ` Yinghai Lu
2008-08-07 23:17 ` Yinghai Lu
2008-08-07 23:30 ` Alexander Huemer
2008-08-07 23:58 ` Yinghai Lu
2008-08-08 0:28 ` Alexander Huemer
2008-08-14 14:09 ` Alexander Huemer
2008-08-14 17:31 ` Yinghai Lu
2008-08-21 14:52 ` 2.6.27 " Alexander Huemer
2008-08-21 15:27 ` Yinghai Lu
2008-08-21 18:44 ` Alexander Huemer
2008-08-22 10:11 ` 2.6.27 mtrr fixes do not work when X starts Helge Hafting
2008-08-22 17:24 ` Yinghai Lu
2008-08-25 11:10 ` Helge Hafting
2008-08-25 20:08 ` Yinghai Lu
2008-08-25 20:19 ` Alexander Huemer
2008-08-25 20:22 ` Yinghai Lu
[not found] ` <48B31508.6020305@sbg.ac.at>
[not found] ` <86802c440808251344h697a27d0i91486a836d258cb@mail.gmail.com>
[not found] ` <86802c440808251624u181a98eesd8a19ea6fd3d8d8c@mail.gmail.com>
[not found] ` <48B34056.5080100@sbg.ac.at>
[not found] ` <86802c440808251633s7bf8ecb2ua6ef187b5be563db@mail.gmail.com>
2008-08-29 15:09 ` 2.6.27 mtrr fixes do not work Alexander Huemer
2008-08-29 17:43 ` Yinghai Lu
2008-08-29 19:10 ` Alexander Huemer
2008-08-29 21:39 ` Yinghai Lu
2008-08-30 11:11 ` Helge Hafting
2008-08-26 9:32 ` Helge Hafting [this message]
2008-08-26 16:43 ` 2.6.27 mtrr fixes do not work when X starts Yinghai Lu
2008-08-27 12:53 ` Helge Hafting
2008-08-27 13:03 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48B3CDAF.604@aitel.hist.no \
--to=helge.hafting@aitel.hist.no \
--cc=alexander.huemer@sbg.ac.at \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=venkatesh.pallipadi@intel.com \
--cc=yhlu.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.