Hi all... My aspire one is giving some strange MTRR settings with rc7-git5 (and prevous kernels, but that is what I run now...): one:~> cat /proc/mtrr reg00: base=0xfffe0000 (4095MB), size= 128KB: write-protect, count=1 reg01: base=0xfffc0000 (4095MB), size= 128KB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1 reg03: base=0x10000000 ( 256MB), size= 256MB: write-back, count=1 reg04: base=0x1f800000 ( 504MB), size= 8MB: uncachable, count=1 reg05: base=0x1f600000 ( 502MB), size= 2MB: uncachable, count=1 reg06: base=0x1f500000 ( 501MB), size= 1MB: uncachable, count=1 reg07: base=0x00000000 ( 0MB), size= 128KB: uncachable, count=1 Therefor, intel x11 driver can not set its own MTRRs, no space left. For example, could not this two reg02: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1 reg03: base=0x10000000 ( 256MB), size= 256MB: write-back, count=1 in one reg02: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1 ?? And some people (google :)) say that this: reg04: base=0x1f800000 ( 504MB), size= 8MB: uncachable, count=1 is a failed attempt to set up video memory. (http://bbs.archlinux.org/viewtopic.php?pid=412972) Add what are these ? reg05: base=0x1f600000 ( 502MB), size= 2MB: uncachable, count=1 reg06: base=0x1f500000 ( 501MB), size= 1MB: uncachable, count=1 And, btw, could MTRR display be ordered by base address ? This would make things much clear to understand...: one:~> cat /proc/mtrr | cut -d' ' -f2- | sort base=0x00000000 ( 0MB), size= 128KB: uncachable, count=1 base=0x00000000 ( 0MB), size= 256MB: write-back, count=1 base=0x10000000 ( 256MB), size= 256MB: write-back, count=1 base=0x1f500000 ( 501MB), size= 1MB: uncachable, count=1 base=0x1f600000 ( 502MB), size= 2MB: uncachable, count=1 base=0x1f800000 ( 504MB), size= 8MB: uncachable, count=1 base=0xfffc0000 (4095MB), size= 128KB: uncachable, count=1 base=0xfffe0000 (4095MB), size= 128KB: write-protect, ...
last entry is really sick... YH --
I have applied the patches you have posted in other threads, and this
give a very strange result. The mtrr cleanup did nothing, and I had to put
some printk's all around.
The thing is that the cleanup stops here:
printk(KERN_INFO "GO 6 %d\n",num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABL
printk(KERN_INFO "GO 6 %d\n",num_var_ranges - num[MTRR_NUM_TYPES]);
/* check if we only had WB and UC */
if (num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABLE] !=
num_var_ranges - num[MTRR_NUM_TYPES])
return 0;
Result is:
GO 6 7
GO 6 8
If I comment the test, it can not found a suitable setup.
Full dmesg below.
Linux version 2.6.26-jam15 (root@one.home) (gcc version 4.3.2 (GCC) ) #4 SMP PREEMPT Sat Oct 4 10:57:32 CEST 2008
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001f376000 (usable)
BIOS-e820: 000000001f376000 - 000000001f3bf000 (reserved)
BIOS-e820: 000000001f3bf000 - 000000001f46d000 (usable)
BIOS-e820: 000000001f46d000 - 000000001f4bf000 (ACPI NVS)
BIOS-e820: 000000001f4bf000 - 000000001f4f0000 (usable)
BIOS-e820: 000000001f4f0000 - 000000001f4ff000 (ACPI data)
BIOS-e820: 000000001f4ff000 - 000000001f500000 (usable)
BIOS-e820: 000000001f500000 - 0000000020000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
last_pfn = 0x1f500 max_arch_pfn = 0x100000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
GO 1 1 1
GO 2 0
GO 3
GO 4 8
GO 5 5
GO 6 7
GO 6 8
total RAM coverred: 500M
*BAD*gran_size: 64K ...will have one patch to assume the [0, 1M) to be coverred by var mtrrs. YH --
please check other three patches. [PATCH 1/3] x86: mtrr_cleanup: print out correct type [PATCH 2/3] x86: mtrr_cleanup: first 1M should be coverred in var mtrrs [PATCH 3/3] x86: mtrr_cleanup: treat WRPROT as UNCACHEABLE you may need to boot with "mtrr_gran_size=64k mtrr_chunk_size=64k" YH --
This makes me think about a question. In the dual xeon box, the 'cleanup' ends with this setup: werewolf:~> 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= 128MB: write-back, count=1 reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1 reg05: base=0x7c000000 (1984MB), size= 64MB: write-back, count=1 reg06: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1 Ths options with 0 me loose were: gran_size: 64K chunk_size: 32M num_reg: 8 lose cover RAM: 0G gran_size: 64K chunk_size: 64M num_reg: 7 lose cover RAM: 0G gran_size: 64K chunk_size: 128M num_reg: 6 lose cover RAM: 0G gran_size: 64K chunk_size: 256M num_reg: 5 lose cover RAM: 0G gran_size: 64K chunk_size: 512M num_reg: 4 lose cover RAM: 0G gran_size: 64K chunk_size: 1G num_reg: 3 lose cover RAM: 0G gran_size: 64K chunk_size: 2G num_reg: 2 lose cover RAM: 0G ... gran_size: 128K chunk_size: 32M num_reg: 8 lose cover RAM: 0G gran_size: 128K chunk_size: 64M num_reg: 7 lose cover RAM: 0G gran_size: 128K chunk_size: 128M num_reg: 6 lose cover RAM: 0G gran_size: 128K chunk_size: 256M num_reg: 5 lose cover RAM: 0G gran_size: 128K chunk_size: 512M num_reg: 4 lose cover RAM: 0G gran_size: 128K chunk_size: 1G num_reg: 3 lose cover RAM: 0G gran_size: 128K chunk_size: 2G num_reg: 2 lose cover RAM: 0G ... gran_size: 256K chunk_size: 32M num_reg: 8 lose cover RAM: 0G gran_size: 256K chunk_size: 64M num_reg: 7 lose cover RAM: 0G gran_size: 256K chunk_size: 128M num_reg: 6 lose cover RAM: 0G gran_size: 256K chunk_size: 256M num_reg: 5 lose cover RAM: 0G gran_size: 256K chunk_size: 512M ...
please do check with tip/master. http://people.redhat.com/mingo/tip.git/readme.txt please boot with mtrr_cleanup_debug to find out right mtrr_gran_size and mtrr_chunk_size... YH --
Kudos!!!
Finally I got messed with tip, and it all works.
For the Aspire One:
one:/proc> cat mtrr
reg00: base=0x000000000 ( 0MB), size= 512MB, count=1: write-back
reg01: base=0x01f500000 ( 501MB), size= 1MB, count=1: uncachable
reg02: base=0x01f600000 ( 502MB), size= 2MB, count=1: uncachable
reg03: base=0x01f800000 ( 504MB), size= 8MB, count=1: uncachable
reg04: base=0x020000000 ( 512MB), size= 256MB, count=1: write-combining
(last one is set by x11 intel driver).
And for the dual Xeon:
werewolf:~> cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x07ff00000 ( 2047MB), size= 1MB, count=1: uncachable
So everything is fine.
Thanks !!
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2009.0 (Cooker) for i586
Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP
--
