Re: Strange mtrrs in Aspire One

Previous thread: Please pull arch perfmon update by Andi Kleen on Monday, September 29, 2008 - 4:52 pm. (7 messages)

Next thread: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M by Yinghai Lu on Monday, September 29, 2008 - 6:54 pm. (29 messages)
From: J.A.
Date: Monday, September 29, 2008 - 4:57 pm

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, ...
From: Yinghai Lu
Date: Monday, September 29, 2008 - 6:05 pm

last entry is really sick...

YH
--

From: J.A.
Date: Saturday, October 4, 2008 - 6:22 am

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 ...
From: Yinghai Lu
Date: Saturday, October 4, 2008 - 10:55 am

will have one patch to assume the [0, 1M) to be coverred by var mtrrs.

YH
--

From: Yinghai Lu
Date: Saturday, October 4, 2008 - 2:54 pm

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
--

From: J.A.
Date: Saturday, October 4, 2008 - 4:02 pm

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    ...
From: Yinghai Lu
Date: Saturday, October 4, 2008 - 4:10 pm

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
--

From: J.A.
Date: Sunday, October 5, 2008 - 5:39 pm

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
--

Previous thread: Please pull arch perfmon update by Andi Kleen on Monday, September 29, 2008 - 4:52 pm. (7 messages)

Next thread: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M by Yinghai Lu on Monday, September 29, 2008 - 6:54 pm. (29 messages)