hi,
mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not seem to work.
bios is the newest version, mainboard vendor says it's not their fault.
mainboard is tyan i5000pw.
please tell me how i can help and cc me on answers, i am not subscribed.
here is some data:
seaburg ~ # grep -E "(^\(WW\)|^\(EE\)|^\(NI\)|^\(??\))" /var/log/Xorg.0.log
(WW) VESA(0): Failed to set up write-combining range (0xd8000000,0x2000000)
seaburg ~ # dmesg|grep mtrr
Command line: root=/dev/sda1 video=uvesafb:1280x1024-24@97,mtrr:3,ywrap
mtrr_gran_size=64m mtrr_chunk_size=1024m
Kernel command line: root=/dev/sda1
video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_gran_size=64m
mtrr_chunk_size=1024m
mtrr: type mismatch for d8000000,800000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,400000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,200000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,100000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,80000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,40000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,20000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,10000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,8000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,4000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,2000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,1000 old: write-back new: write-combining
mtrr: type mismatch for d8000000,2000000 old: write-back new:
write-combining
seaburg ~ # cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
seaburg ~ # grep MemTotal /proc/meminfo
MemTotal: 4041308 kB
seaburg ~ # lspci -v | grep -A10 VGA
20:05.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics
Innovation) Volari Z7 (prog-if 00 [VGA controller])
Subsystem: XGI Technology Inc. (eXtreme Graphics Innovation)
Volari Z7
Flags: 66MHz, medium devsel
BIST result: 00
Memory at d8000000 (32-bit, prefetchable) [size=64M]
Memory at dc300000 (32-bit, non-prefetchable) [size=256K]
I/O ports at 3000 [size=128]
Capabilities: [40] Power Management version 2
seaburg ~ # zcat /proc/config.gz | grep MTRR
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
seaburg ~ # uname -a
Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
seaburg ~ #
[Adding CCs.]
On Wednesday, 6 of August 2008, Alexander Huemer wrote:
> hi,
>
> mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not seem to work.
> bios is the newest version, mainboard vendor says it's not their fault.
> mainboard is tyan i5000pw.
> please tell me how i can help and cc me on answers, i am not subscribed.
>
> here is some data:
>
> seaburg ~ # grep -E "(^\(WW\)|^\(EE\)|^\(NI\)|^\(??\))" /var/log/Xorg.0.log
> (WW) VESA(0): Failed to set up write-combining range (0xd8000000,0x2000000)
> seaburg ~ # dmesg|grep mtrr
> Command line: root=/dev/sda1 video=uvesafb:1280x1024-24@97,mtrr:3,ywrap
> mtrr_gran_size=64m mtrr_chunk_size=1024m
> Kernel command line: root=/dev/sda1
> video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_gran_size=64m
> mtrr_chunk_size=1024m
> mtrr: type mismatch for d8000000,800000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,400000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,200000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,100000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,80000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,40000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,20000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,10000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,8000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,4000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,2000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,1000 old: write-back new: write-combining
> mtrr: type mismatch for d8000000,2000000 old: write-back new:
> write-combining
> seaburg ~ # cat /proc/mtrr
> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
> seaburg ~ # grep MemTotal /proc/meminfo
> MemTotal: 4041308 kB
> seaburg ~ # lspci -v | grep -A10 VGA
> 20:05.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics
> Innovation) Volari Z7 (prog-if 00 [VGA controller])
> Subsystem: XGI Technology Inc. (eXtreme Graphics Innovation)
> Volari Z7
> Flags: 66MHz, medium devsel
> BIST result: 00
> Memory at d8000000 (32-bit, prefetchable) [size=64M]
> Memory at dc300000 (32-bit, non-prefetchable) [size=256K]
> I/O ports at 3000 [size=128]
> Capabilities: [40] Power Management version 2
>
> seaburg ~ # zcat /proc/config.gz | grep MTRR
> CONFIG_MTRR=y
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
> seaburg ~ # uname -a
> Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
> x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
> seaburg ~ #
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Adding Yinghai.
>-----Original Message-----
>From: Rafael J. Wysocki [mailto:[email protected]]
>Sent: Thursday, August 07, 2008 1:14 PM
>To: Alexander Huemer
>Cc: [email protected]; Andi Kleen; Pallipadi, Venkatesh
>Subject: Re: 2.6.27-rc1 mtrr fixes do not work
>
>[Adding CCs.]
>
>On Wednesday, 6 of August 2008, Alexander Huemer wrote:
>> hi,
>>
>> mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not
>seem to work.
>> bios is the newest version, mainboard vendor says it's not
>their fault.
>> mainboard is tyan i5000pw.
>> please tell me how i can help and cc me on answers, i am not
>subscribed.
>>
>> here is some data:
>>
>> seaburg ~ # grep -E "(^\(WW\)|^\(EE\)|^\(NI\)|^\(??\))"
>/var/log/Xorg.0.log
>> (WW) VESA(0): Failed to set up write-combining range
>(0xd8000000,0x2000000)
>> seaburg ~ # dmesg|grep mtrr
>> Command line: root=/dev/sda1
>video=uvesafb:1280x1024-24@97,mtrr:3,ywrap
>> mtrr_gran_size=64m mtrr_chunk_size=1024m
>> Kernel command line: root=/dev/sda1
>> video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_gran_size=64m
>> mtrr_chunk_size=1024m
>> mtrr: type mismatch for d8000000,800000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,400000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,200000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,100000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,80000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,40000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,20000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,10000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,8000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,4000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,2000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,1000 old: write-back new:
>write-combining
>> mtrr: type mismatch for d8000000,2000000 old: write-back new:
>> write-combining
>> seaburg ~ # cat /proc/mtrr
>> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
>> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
>> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
>> seaburg ~ # grep MemTotal /proc/meminfo
>> MemTotal: 4041308 kB
>> seaburg ~ # lspci -v | grep -A10 VGA
>> 20:05.0 VGA compatible controller: XGI Technology Inc.
>(eXtreme Graphics
>> Innovation) Volari Z7 (prog-if 00 [VGA controller])
>> Subsystem: XGI Technology Inc. (eXtreme Graphics Innovation)
>> Volari Z7
>> Flags: 66MHz, medium devsel
>> BIST result: 00
>> Memory at d8000000 (32-bit, prefetchable) [size=64M]
>> Memory at dc300000 (32-bit, non-prefetchable) [size=256K]
>> I/O ports at 3000 [size=128]
>> Capabilities: [40] Power Management version 2
>>
>> seaburg ~ # zcat /proc/config.gz | grep MTRR
>> CONFIG_MTRR=y
>> CONFIG_MTRR_SANITIZER=y
>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>> seaburg ~ # uname -a
>> Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
>> x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
>> seaburg ~ #
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>
>
>
On Thu, Aug 7, 2008 at 1:15 PM, Pallipadi, Venkatesh
<[email protected]> wrote:
>
> Adding Yinghai.
>
>>-----Original Message-----
>>From: Rafael J. Wysocki [mailto:[email protected]]
>>Sent: Thursday, August 07, 2008 1:14 PM
>>To: Alexander Huemer
>>Cc: [email protected]; Andi Kleen; Pallipadi, Venkatesh
>>Subject: Re: 2.6.27-rc1 mtrr fixes do not work
>>
>>[Adding CCs.]
>>
>>On Wednesday, 6 of August 2008, Alexander Huemer wrote:
>>> hi,
>>>
>>> mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not
>>seem to work.
>>> bios is the newest version, mainboard vendor says it's not
>>their fault.
>>> mainboard is tyan i5000pw.
>>> please tell me how i can help and cc me on answers, i am not
>>subscribed.
>>>
>>> seaburg ~ # cat /proc/mtrr
>>> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
>>> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
>>> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
>>>
>>> seaburg ~ # zcat /proc/config.gz | grep MTRR
>>> CONFIG_MTRR=y
>>> CONFIG_MTRR_SANITIZER=y
>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>> seaburg ~ # uname -a
>>> Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
>>> x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
>>> seaburg ~ #
alexander,
please send out
dmesg -s 262144 > dmesg.txt
or
dmesg -s 524288 > dmesg.txt
you may need to set
CONFIG_LOG_BUF_SHIFT=19
YH
On Thu, Aug 7, 2008 at 1:23 PM, Yinghai Lu <[email protected]> wrote:
> On Thu, Aug 7, 2008 at 1:15 PM, Pallipadi, Venkatesh
> <[email protected]> wrote:
>>
>> Adding Yinghai.
>>
>>>-----Original Message-----
>>>From: Rafael J. Wysocki [mailto:[email protected]]
>>>Sent: Thursday, August 07, 2008 1:14 PM
>>>To: Alexander Huemer
>>>Cc: [email protected]; Andi Kleen; Pallipadi, Venkatesh
>>>Subject: Re: 2.6.27-rc1 mtrr fixes do not work
>>>
>>>[Adding CCs.]
>>>
>>>On Wednesday, 6 of August 2008, Alexander Huemer wrote:
>>>> hi,
>>>>
>>>> mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not
>>>seem to work.
>>>> bios is the newest version, mainboard vendor says it's not
>>>their fault.
>>>> mainboard is tyan i5000pw.
>>>> please tell me how i can help and cc me on answers, i am not
>>>subscribed.
>>>>
>>>> seaburg ~ # cat /proc/mtrr
>>>> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
>>>> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
>>>> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
>
>>>>
>>>> seaburg ~ # zcat /proc/config.gz | grep MTRR
>>>> CONFIG_MTRR=y
>>>> CONFIG_MTRR_SANITIZER=y
>>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>>> seaburg ~ # uname -a
>>>> Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
>>>> x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
>>>> seaburg ~ #
>
> alexander,
>
> please send out
> dmesg -s 262144 > dmesg.txt
> or
> dmesg -s 524288 > dmesg.txt
>
> you may need to set
> CONFIG_LOG_BUF_SHIFT=19
without mtrr_gran_size=64m mtrr_chunk_size=1024m on command line
guess mtrr_chunk_size=512m could work
YH
Yinghai Lu wrote:
> On Thu, Aug 7, 2008 at 1:23 PM, Yinghai Lu <[email protected]> wrote:
>
>> On Thu, Aug 7, 2008 at 1:15 PM, Pallipadi, Venkatesh
>> <[email protected]> wrote:
>>
>>> Adding Yinghai.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rafael J. Wysocki [mailto:[email protected]]
>>>> Sent: Thursday, August 07, 2008 1:14 PM
>>>> To: Alexander Huemer
>>>> Cc: [email protected]; Andi Kleen; Pallipadi, Venkatesh
>>>> Subject: Re: 2.6.27-rc1 mtrr fixes do not work
>>>>
>>>> [Adding CCs.]
>>>>
>>>> On Wednesday, 6 of August 2008, Alexander Huemer wrote:
>>>>
>>>>> hi,
>>>>>
>>>>> mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not
>>>>>
>>>> seem to work.
>>>>
>>>>> bios is the newest version, mainboard vendor says it's not
>>>>>
>>>> their fault.
>>>>
>>>>> mainboard is tyan i5000pw.
>>>>> please tell me how i can help and cc me on answers, i am not
>>>>>
>>>> subscribed.
>>>>
>>>>> seaburg ~ # cat /proc/mtrr
>>>>> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
>>>>> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
>>>>> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
>>>>>
>>>>> seaburg ~ # zcat /proc/config.gz | grep MTRR
>>>>> CONFIG_MTRR=y
>>>>> CONFIG_MTRR_SANITIZER=y
>>>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>>>> seaburg ~ # uname -a
>>>>> Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
>>>>> x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
>>>>> seaburg ~ #
>>>>>
>> alexander,
>>
>> please send out
>> dmesg -s 262144 > dmesg.txt
>> or
>> dmesg -s 524288 > dmesg.txt
>>
>> you may need to set
>> CONFIG_LOG_BUF_SHIFT=19
>>
>
> without mtrr_gran_size=64m mtrr_chunk_size=1024m on command line
>
> guess mtrr_chunk_size=512m could work
>
> YH
>
yinghai,
thanks for the response.
i booted with
mtrr_gransize_64m mtrr_chunk_size_512m
mtrr_chunk_size_512m
here are the 2 dmesg outputs:
http://xx.vu/~ahuemer/dmesg_1.txt
http://xx.vu/~ahuemer/dmesg_2.txt
On Thu, Aug 7, 2008 at 3:14 PM, Alexander Huemer
<[email protected]> wrote:
> Yinghai Lu wrote:
>>
>> On Thu, Aug 7, 2008 at 1:23 PM, Yinghai Lu <[email protected]> wrote:
>>
>>>
>>> On Thu, Aug 7, 2008 at 1:15 PM, Pallipadi, Venkatesh
>>> <[email protected]> wrote:
>>>
>>>>
>>>> Adding Yinghai.
>>>>
>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Rafael J. Wysocki [mailto:[email protected]]
>>>>> Sent: Thursday, August 07, 2008 1:14 PM
>>>>> To: Alexander Huemer
>>>>> Cc: [email protected]; Andi Kleen; Pallipadi, Venkatesh
>>>>> Subject: Re: 2.6.27-rc1 mtrr fixes do not work
>>>>>
>>>>> [Adding CCs.]
>>>>>
>>>>> On Wednesday, 6 of August 2008, Alexander Huemer wrote:
>>>>>
>>>>>>
>>>>>> hi,
>>>>>>
>>>>>> mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not
>>>>>>
>>>>>
>>>>> seem to work.
>>>>>
>>>>>>
>>>>>> bios is the newest version, mainboard vendor says it's not
>>>>>>
>>>>>
>>>>> their fault.
>>>>>
>>>>>>
>>>>>> mainboard is tyan i5000pw.
>>>>>> please tell me how i can help and cc me on answers, i am not
>>>>>>
>>>>>
>>>>> subscribed.
>>>>>
>>>>>>
>>>>>> seaburg ~ # cat /proc/mtrr
>>>>>> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
>>>>>> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
>>>>>> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
>>>>>> seaburg ~ # zcat /proc/config.gz | grep MTRR
>>>>>> CONFIG_MTRR=y
>>>>>> CONFIG_MTRR_SANITIZER=y
>>>>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>>>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>>>>> seaburg ~ # uname -a
>>>>>> Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
>>>>>> x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
>>>>>> seaburg ~ #
>>>>>>
>>>
>>> alexander,
>>>
>>> please send out
>>> dmesg -s 262144 > dmesg.txt
>>> or
>>> dmesg -s 524288 > dmesg.txt
>>>
>>> you may need to set
>>> CONFIG_LOG_BUF_SHIFT=19
>>>
>>
>> without mtrr_gran_size=64m mtrr_chunk_size=1024m on command line
>>
>> guess mtrr_chunk_size=512m could work
>>
>> YH
>>
>
> yinghai,
>
> thanks for the response.
> i booted with
> mtrr_gransize_64m mtrr_chunk_size_512m
> mtrr_chunk_size_512m
> here are the 2 dmesg outputs:
> http://xx.vu/~ahuemer/dmesg_1.txt
> http://xx.vu/~ahuemer/dmesg_2.txt
>
can you put "debug" in command line too?
YH
On Thu, Aug 7, 2008 at 4:16 PM, Yinghai Lu <[email protected]> wrote:
> On Thu, Aug 7, 2008 at 3:14 PM, Alexander Huemer
> <[email protected]> wrote:
>> Yinghai Lu wrote:
>>>
>>> On Thu, Aug 7, 2008 at 1:23 PM, Yinghai Lu <[email protected]> wrote:
>>>
>>>>
>>>> On Thu, Aug 7, 2008 at 1:15 PM, Pallipadi, Venkatesh
>>>> <[email protected]> wrote:
>>>>
>>>>>
>>>>> Adding Yinghai.
>>>>>
>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Rafael J. Wysocki [mailto:[email protected]]
>>>>>> Sent: Thursday, August 07, 2008 1:14 PM
>>>>>> To: Alexander Huemer
>>>>>> Cc: [email protected]; Andi Kleen; Pallipadi, Venkatesh
>>>>>> Subject: Re: 2.6.27-rc1 mtrr fixes do not work
>>>>>>
>>>>>> [Adding CCs.]
>>>>>>
>>>>>> On Wednesday, 6 of August 2008, Alexander Huemer wrote:
>>>>>>
>>>>>>>
>>>>>>> hi,
>>>>>>>
>>>>>>> mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not
>>>>>>>
>>>>>>
>>>>>> seem to work.
>>>>>>
>>>>>>>
>>>>>>> bios is the newest version, mainboard vendor says it's not
>>>>>>>
>>>>>>
>>>>>> their fault.
>>>>>>
>>>>>>>
>>>>>>> mainboard is tyan i5000pw.
>>>>>>> please tell me how i can help and cc me on answers, i am not
>>>>>>>
>>>>>>
>>>>>> subscribed.
>>>>>>
>>>>>>>
>>>>>>> seaburg ~ # cat /proc/mtrr
>>>>>>> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
>>>>>>> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
>>>>>>> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
>>>>>>> seaburg ~ # zcat /proc/config.gz | grep MTRR
>>>>>>> CONFIG_MTRR=y
>>>>>>> CONFIG_MTRR_SANITIZER=y
>>>>>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>>>>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>>>>>> seaburg ~ # uname -a
>>>>>>> Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
>>>>>>> x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
>>>>>>> seaburg ~ #
>>>>>>>
>>>>
>>>> alexander,
>>>>
>>>> please send out
>>>> dmesg -s 262144 > dmesg.txt
>>>> or
>>>> dmesg -s 524288 > dmesg.txt
>>>>
>>>> you may need to set
>>>> CONFIG_LOG_BUF_SHIFT=19
>>>>
>>>
>>> without mtrr_gran_size=64m mtrr_chunk_size=1024m on command line
>>>
>>> guess mtrr_chunk_size=512m could work
>>>
>>> YH
>>>
>>
>> yinghai,
>>
>> thanks for the response.
>> i booted with
>> mtrr_gransize_64m mtrr_chunk_size_512m
>> mtrr_chunk_size_512m
>> here are the 2 dmesg outputs:
>> http://xx.vu/~ahuemer/dmesg_1.txt
>> http://xx.vu/~ahuemer/dmesg_2.txt
>>
>
> can you put "debug" in command line too?
without mtrr_chunk_size etc in command line...please
YH
Yinghai Lu wrote:
> On Thu, Aug 7, 2008 at 4:16 PM, Yinghai Lu <[email protected]> wrote:
>
>> On Thu, Aug 7, 2008 at 3:14 PM, Alexander Huemer
>> <[email protected]> wrote:
>>
>>> Yinghai Lu wrote:
>>>
>>>> On Thu, Aug 7, 2008 at 1:23 PM, Yinghai Lu <[email protected]> wrote:
>>>>
>>>>
>>>>> On Thu, Aug 7, 2008 at 1:15 PM, Pallipadi, Venkatesh
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>>> Adding Yinghai.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Rafael J. Wysocki [mailto:[email protected]]
>>>>>>> Sent: Thursday, August 07, 2008 1:14 PM
>>>>>>> To: Alexander Huemer
>>>>>>> Cc: [email protected]; Andi Kleen; Pallipadi, Venkatesh
>>>>>>> Subject: Re: 2.6.27-rc1 mtrr fixes do not work
>>>>>>>
>>>>>>> [Adding CCs.]
>>>>>>>
>>>>>>> On Wednesday, 6 of August 2008, Alexander Huemer wrote:
>>>>>>>
>>>>>>>
>>>>>>>> hi,
>>>>>>>>
>>>>>>>> mtrr is wrong on my machine. the fixes of 2.6.27-rc1 do not
>>>>>>>>
>>>>>>>>
>>>>>>> seem to work.
>>>>>>>
>>>>>>>
>>>>>>>> bios is the newest version, mainboard vendor says it's not
>>>>>>>>
>>>>>>>>
>>>>>>> their fault.
>>>>>>>
>>>>>>>
>>>>>>>> mainboard is tyan i5000pw.
>>>>>>>> please tell me how i can help and cc me on answers, i am not
>>>>>>>>
>>>>>>>>
>>>>>>> subscribed.
>>>>>>>
>>>>>>>
>>>>>>>> seaburg ~ # cat /proc/mtrr
>>>>>>>> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
>>>>>>>> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
>>>>>>>> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
>>>>>>>> seaburg ~ # zcat /proc/config.gz | grep MTRR
>>>>>>>> CONFIG_MTRR=y
>>>>>>>> CONFIG_MTRR_SANITIZER=y
>>>>>>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>>>>>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>>>>>>> seaburg ~ # uname -a
>>>>>>>> Linux seaburg 2.6.27-rc1-blackbit #3 SMP Wed Aug 6 00:34:51 CEST 2008
>>>>>>>> x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
>>>>>>>> seaburg ~ #
>>>>>>>>
>>>>>>>>
>>>>> alexander,
>>>>>
>>>>> please send out
>>>>> dmesg -s 262144 > dmesg.txt
>>>>> or
>>>>> dmesg -s 524288 > dmesg.txt
>>>>>
>>>>> you may need to set
>>>>> CONFIG_LOG_BUF_SHIFT=19
>>>>>
>>>>>
>>>> without mtrr_gran_size=64m mtrr_chunk_size=1024m on command line
>>>>
>>>> guess mtrr_chunk_size=512m could work
>>>>
>>>> YH
>>>>
>>>>
>>> yinghai,
>>>
>>> thanks for the response.
>>> i booted with
>>> mtrr_gransize_64m mtrr_chunk_size_512m
>>> mtrr_chunk_size_512m
>>> here are the 2 dmesg outputs:
>>> http://xx.vu/~ahuemer/dmesg_1.txt
>>> http://xx.vu/~ahuemer/dmesg_2.txt
>>>
>>>
>> can you put "debug" in command line too?
>>
>
> without mtrr_chunk_size etc in command line...please
>
> YH
>
http://xx.vu/~ahuemer/dmesg_3.txt
On Thu, Aug 7, 2008 at 4:30 PM, Alexander Huemer
<[email protected]> wrote:
> Yinghai Lu wrote:
>>> can you put "debug" in command line too?
>>>
>>
>> without mtrr_chunk_size etc in command line...please
>>
>
> http://xx.vu/~ahuemer/dmesg_3.txt
>
do you have
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
in your .config?
YH
Yinghai Lu wrote:
> On Thu, Aug 7, 2008 at 4:30 PM, Alexander Huemer
> <[email protected]> wrote:
>
>> Yinghai Lu wrote:
>>
>
>
>>>> can you put "debug" in command line too?
>>>>
>>>>
>>> without mtrr_chunk_size etc in command line...please
>>>
>>>
>> http://xx.vu/~ahuemer/dmesg_3.txt
>>
>>
>
> do you have
> CONFIG_MTRR=y
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>
> in your .config?
>
> YH
>
definitely yes, in my initial post i grepped that out of my kernel config.
Yinghai Lu wrote:
> On Thu, Aug 7, 2008 at 4:30 PM, Alexander Huemer
> <[email protected]> wrote:
>
>> Yinghai Lu wrote:
>>
>
>
>>>> can you put "debug" in command line too?
>>>>
>>>>
>>> without mtrr_chunk_size etc in command line...please
>>>
>>>
>> http://xx.vu/~ahuemer/dmesg_3.txt
>>
>>
>
> do you have
> CONFIG_MTRR=y
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>
> in your .config?
>
> YH
>
2.6.27_rc3 does not solve the problem either.
what can i do to help?
--
alex
On Thu, Aug 14, 2008 at 7:09 AM, Alexander Huemer
<[email protected]> wrote:
> Yinghai Lu wrote:
>>
>> On Thu, Aug 7, 2008 at 4:30 PM, Alexander Huemer
>> <[email protected]> wrote:
>>
>>>
>>> Yinghai Lu wrote:
>>>
>>
>>
>>>>>
>>>>> can you put "debug" in command line too?
>>>>>
>>>>>
>>>>
>>>> without mtrr_chunk_size etc in command line...please
>>>>
>>>>
>>>
>>> http://xx.vu/~ahuemer/dmesg_3.txt
>>>
>>>
>>
>> do you have
>> CONFIG_MTRR=y
>> CONFIG_MTRR_SANITIZER=y
>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>
>> in your .config?
>>
>> YH
>>
>
> 2.6.27_rc3 does not solve the problem either.
> what can i do to help?
please send out you config
YH
Yinghai Lu wrote:
> On Thu, Aug 14, 2008 at 7:09 AM, Alexander Huemer
> <[email protected]> wrote:
>
>> Yinghai Lu wrote:
>>
>>> On Thu, Aug 7, 2008 at 4:30 PM, Alexander Huemer
>>> <[email protected]> wrote:
>>>
>>>
>>>> Yinghai Lu wrote:
>>>>
>>>>
>>>
>>>>>> can you put "debug" in command line too?
>>>>>>
>>>>>>
>>>>>>
>>>>> without mtrr_chunk_size etc in command line...please
>>>>>
>>>>>
>>>>>
>>>> http://xx.vu/~ahuemer/dmesg_3.txt
>>>>
>>>>
>>>>
>>> do you have
>>> CONFIG_MTRR=y
>>> CONFIG_MTRR_SANITIZER=y
>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>>
>>> in your .config?
>>>
>>> YH
>>>
>>>
>> 2.6.27_rc3 does not solve the problem either.
>> what can i do to help?
>>
>
> please send out you config
>
> YH
>
yinghai,
i just tried out 2.6.27-rc4, unfortunately without success.
here are my settings again,
if you need more info, just tell me.
as you can see, the mtrr size values are complete nonsense.
the framebuffer should be at d8000000.
i am unsure if this is the fault of the kernel or the bios.
or should the MTRR_SANITIZER resolv all broken bios issues?
# uname -a
Linux seaburg 2.6.27-rc4-blackbit #1 SMP Thu Aug 21 15:53:38 CEST
2008 x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
# grep -E "(^\(WW\)|^\(EE\)|^\(NI\)|^\(??\))" /var/log/Xorg.0.log
(WW) VESA(0): Failed to set up write-combining range
(0xd8000000,0x2000000)
# dmesg|grep mtrr
Command line: root=/dev/sda1
video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_chunk_size=512m
Kernel command line: root=/dev/sda1
video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_chunk_size=512m
mtrr: type mismatch for d8000000,800000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,400000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,200000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,100000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,80000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,40000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,20000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,10000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,8000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,4000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,2000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,1000 old: write-back new:
write-combining
mtrr: type mismatch for d8000000,2000000 old: write-back new:
write-combining
# grep MemTotal /proc/meminfo
MemTotal: 4041088 kB
# grep MTRR /usr/src/linux/.config
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
# dmesg|grep uvesafb
Command line: root=/dev/sda1
video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_chunk_size=512m
Kernel command line: root=/dev/sda1
video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_chunk_size=512m
uvesafb: XGI Technology, Inc., Volari Z9s, 1.09.10, OEM: XGI, VBE v3.0
uvesafb: VBIOS/hardware supports DDC2 transfers
uvesafb: monitor limits: vf = 97 Hz, hf = 129 kHz, clk = 364 MHz
uvesafb: scrolling: redraw
uvesafb: framebuffer at 0xd8000000, mapped to 0xffffc20002100000,
using 10240k, total 32768k
# cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
#
--
regards
alex
On Thu, Aug 21, 2008 at 7:52 AM, Alexander Huemer
<[email protected]> wrote:
> Yinghai Lu wrote:
>>
>> On Thu, Aug 14, 2008 at 7:09 AM, Alexander Huemer
>> <[email protected]> wrote:
>>
>>>
>>> Yinghai Lu wrote:
>>>
>>>>
>>>> On Thu, Aug 7, 2008 at 4:30 PM, Alexander Huemer
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>>>
>>>>> Yinghai Lu wrote:
>>>>>
>>>>>
>>>>
>>>>
>>>>>>>
>>>>>>> can you put "debug" in command line too?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> without mtrr_chunk_size etc in command line...please
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> http://xx.vu/~ahuemer/dmesg_3.txt
>>>>>
>>>>>
>>>>>
>>>>
>>>> do you have
>>>> CONFIG_MTRR=y
>>>> CONFIG_MTRR_SANITIZER=y
>>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>>>
>>>> in your .config?
>>>>
>>>> YH
>>>>
>>>>
>>>
>>> 2.6.27_rc3 does not solve the problem either.
>>> what can i do to help?
>>>
>>
>> please send out you config
>>
>> YH
>>
>
> yinghai,
>
> i just tried out 2.6.27-rc4, unfortunately without success.
>
> here are my settings again,
> if you need more info, just tell me.
>
> as you can see, the mtrr size values are complete nonsense.
> the framebuffer should be at d8000000.
> i am unsure if this is the fault of the kernel or the bios.
> or should the MTRR_SANITIZER resolv all broken bios issues?
>
> # uname -a
> Linux seaburg 2.6.27-rc4-blackbit #1 SMP Thu Aug 21 15:53:38 CEST
> 2008 x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
> # grep -E "(^\(WW\)|^\(EE\)|^\(NI\)|^\(??\))" /var/log/Xorg.0.log
> (WW) VESA(0): Failed to set up write-combining range
> (0xd8000000,0x2000000)
> # dmesg|grep mtrr Command
> line: root=/dev/sda1
> video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_chunk_size=512m
> Kernel command line: root=/dev/sda1
> video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_chunk_size=512m
please boot without mtrr_chunk_size=512m
and put debug in your command line
> # cat /proc/mtrr
> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
another case of crazy size in /proc/mtrr
it is E5420, maybe mtrr code has problem to handle that cpu?
YH
Yinghai Lu wrote:
> On Thu, Aug 21, 2008 at 7:52 AM, Alexander Huemer
> <[email protected]> wrote:
>
>> Yinghai Lu wrote:
>>
>>> On Thu, Aug 14, 2008 at 7:09 AM, Alexander Huemer
>>> <[email protected]> wrote:
>>>
>>>
>>>> Yinghai Lu wrote:
>>>>
>>>>
>>>>> On Thu, Aug 7, 2008 at 4:30 PM, Alexander Huemer
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Yinghai Lu wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>>>> can you put "debug" in command line too?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> without mtrr_chunk_size etc in command line...please
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> http://xx.vu/~ahuemer/dmesg_3.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> do you have
>>>>> CONFIG_MTRR=y
>>>>> CONFIG_MTRR_SANITIZER=y
>>>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
>>>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>>>>>
>>>>> in your .config?
>>>>>
>>>>> YH
>>>>>
>>>>>
>>>>>
>>>> 2.6.27_rc3 does not solve the problem either.
>>>> what can i do to help?
>>>>
>>>>
>>> please send out you config
>>>
>>> YH
>>>
>>>
>> yinghai,
>>
>> i just tried out 2.6.27-rc4, unfortunately without success.
>>
>> here are my settings again,
>> if you need more info, just tell me.
>>
>> as you can see, the mtrr size values are complete nonsense.
>> the framebuffer should be at d8000000.
>> i am unsure if this is the fault of the kernel or the bios.
>> or should the MTRR_SANITIZER resolv all broken bios issues?
>>
>> # uname -a
>> Linux seaburg 2.6.27-rc4-blackbit #1 SMP Thu Aug 21 15:53:38 CEST
>> 2008 x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
>> # grep -E "(^\(WW\)|^\(EE\)|^\(NI\)|^\(??\))" /var/log/Xorg.0.log
>> (WW) VESA(0): Failed to set up write-combining range
>> (0xd8000000,0x2000000)
>> # dmesg|grep mtrr Command
>> line: root=/dev/sda1
>> video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_chunk_size=512m
>> Kernel command line: root=/dev/sda1
>> video=uvesafb:1280x1024-24@97,mtrr:3,ywrap mtrr_chunk_size=512m
>>
>
> please boot without mtrr_chunk_size=512m
> and put debug in your command line
>
>
>
>> # cat /proc/mtrr
>> reg00: base=0x00000000 ( 0MB), size=198656MB: write-back, count=1
>> reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
>> reg02: base=0x100000000 (4096MB), size=197632MB: write-back, count=1
>>
>
> another case of crazy size in /proc/mtrr
>
> it is E5420, maybe mtrr code has problem to handle that cpu?
>
> YH
>
yinghai,
i booted as you suggested. i cannot see any difference.
here is the dmesg output: http://xx.vu/~ahuemer/dmesg_4.txt
what else can i do?
--
thanks
alex
I also see mtrr problems. I use 2.6.27-rc4, with this in my .config:
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
(Have no idea what the last one is about, the docs didn't say.)
Everything is fine during boot, I see this in dmesg:
Found optimal setting for mtrr clean up
gran_size: 1M chunk_size: 64M num_reg: 7 lose RAM: 0M
range0: 0000000000000000 - 000000007c000000
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
Setting variable MTRR 3, base: 1792MB, range: 128MB, type WB
Setting variable MTRR 4, base: 1920MB, range: 64MB, type WB
range: 000000007c000000 - 0000000080000000
Setting variable MTRR 5, base: 1984MB, range: 64MB, type WB
hole: 000000007ff00000 - 0000000080000000
Setting variable MTRR 6, 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
X gets problems however, from my Xorg.0.log:(II) VESA(0): initializing int10
(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: 0xfb000000, size: 0xe00000
(II) VESA(0): Splitting WC range: base: 0xfb800000, size: 0x600000
(==) VESA(0): Write-combining range (0xfbc00000,0x200000)
(WW) VESA(0): Failed to set up write-combining range (0xfb800000,0x600000)
(WW) VESA(0): Failed to set up write-combining range (0xfb000000,0xe00000)
(II) VESA(0): virtual address = 0x7f17bd6dd000,
physical address = 0xfb000000, size = 14680064
And dmesg says:
mtrr: no more MTRRs available
mtrr: no more MTRRs available
So I get one write-combining range where X wants three.
$ 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
reg07: base=0xfbc00000 (4028MB), size= 2MB: write-combining, count=1
2MB does obviously not cover the entire framebuffer. :-(
Helge Hafting
On Fri, Aug 22, 2008 at 3:11 AM, Helge Hafting
<[email protected]> wrote:
> I also see mtrr problems. I use 2.6.27-rc4, with this in my .config:
> CONFIG_MTRR=y
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
> (Have no idea what the last one is about, the docs didn't say.)
>
> Everything is fine during boot, I see this in dmesg:
> Found optimal setting for mtrr clean up
> gran_size: 1M chunk_size: 64M num_reg: 7 lose RAM: 0M
> range0: 0000000000000000 - 000000007c000000
> 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
> Setting variable MTRR 3, base: 1792MB, range: 128MB, type WB
> Setting variable MTRR 4, base: 1920MB, range: 64MB, type WB
> range: 000000007c000000 - 0000000080000000
> Setting variable MTRR 5, base: 1984MB, range: 64MB, type WB
> hole: 000000007ff00000 - 0000000080000000
> Setting variable MTRR 6, 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
>
> X gets problems however, from my Xorg.0.log:(II) VESA(0): initializing int10
> (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: 0xfb000000, size: 0xe00000
> (II) VESA(0): Splitting WC range: base: 0xfb800000, size: 0x600000
> (==) VESA(0): Write-combining range (0xfbc00000,0x200000)
> (WW) VESA(0): Failed to set up write-combining range (0xfb800000,0x600000)
> (WW) VESA(0): Failed to set up write-combining range (0xfb000000,0xe00000)
> (II) VESA(0): virtual address = 0x7f17bd6dd000,
> physical address = 0xfb000000, size = 14680064
>
> And dmesg says:
> mtrr: no more MTRRs available
> mtrr: no more MTRRs available
>
> So I get one write-combining range where X wants three.
> $ 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
> reg07: base=0xfbc00000 (4028MB), size= 2MB: write-combining, count=1
>
> 2MB does obviously not cover the entire framebuffer. :-(
>
please boot with "mtrr_spare_reg_nr=3 debug"
YH
Yinghai Lu wrote:
> On Fri, Aug 22, 2008 at 3:11 AM, Helge Hafting
>
[old bug report removed]
> please boot with "mtrr_spare_reg_nr=3 debug"
>
I did that, and got:
dmesg:
Command line: root=/dev/sda2 ro mtrr_spare_reg=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 - 000000007fe80400 (usable)
BIOS-e820: 000000007fe80400 - 0000000080000000 (reserved)
BIOS-e820: 00000000f4000000 - 00000000f8000000 (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 = 0x7fe80 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: 64M num_reg: 7 lose RAM: 0M
range0: 0000000000000000 - 000000007c000000
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
Setting variable MTRR 3, base: 1792MB, range: 128MB, type WB
Setting variable MTRR 4, base: 1920MB, range: 64MB, type WB
range: 000000007c000000 - 0000000080000000
Setting variable MTRR 5, base: 1984MB, range: 64MB, type WB
hole: 000000007ff00000 - 0000000080000000
Setting variable MTRR 6, 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 - 007fe80000 page 4k
kernel direct mapping tables up to 7fe80000 @ 8000-c000
last_map_addr: 7fe80000 end: 7fe80000
DMI 2.4 present.
Xorg.0.log:
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/lib/xorg/modules//libint10.so
(II) VESA(0): initializing int10
(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: 0xfb000000, size: 0xe00000
(II) VESA(0): Splitting WC range: base: 0xfb800000, size: 0x600000
(==) VESA(0): Write-combining range (0xfbc00000,0x200000)
(WW) VESA(0): Failed to set up write-combining range (0xfb800000,0x600000)
(WW) VESA(0): Failed to set up write-combining range (0xfb000000,0xe00000)
(II) VESA(0): virtual address = 0x7f3ccaf43000,
physical address = 0xfb000000, size = 14680064
Just like last time, this lack of mtrr is reflected in dmesg:
mtrr: no more MTRRs available
mtrr: no more MTRRs available
$ 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
reg07: base=0xfbc00000 (4028MB), size= 2MB: write-combining, count=1
The problem is still there, I hope the output is useful.
I can test experimental patches if necessary.
Helge Hafting
On Mon, Aug 25, 2008 at 4:10 AM, Helge Hafting
<[email protected]> wrote:
> Yinghai Lu wrote:
>>
>> On Fri, Aug 22, 2008 at 3:11 AM, Helge Hafting
>>
>
> [old bug report removed]
>>
>> please boot with "mtrr_spare_reg_nr=3 debug"
>>
>
> I did that, and got:
> dmesg:
> Command line: root=/dev/sda2 ro mtrr_spare_reg=3 debug
please use "mtrr_spare_reg_nr=3 debug"
you missed _nr.
YH
Yinghai Lu wrote:
> On Mon, Aug 25, 2008 at 4:10 AM, Helge Hafting
> <[email protected]> wrote:
>
>> Yinghai Lu wrote:
>>
>>> On Fri, Aug 22, 2008 at 3:11 AM, Helge Hafting
>>>
>>>
>> [old bug report removed]
>>
>>> please boot with "mtrr_spare_reg_nr=3 debug"
>>>
>>>
>> I did that, and got:
>> dmesg:
>> Command line: root=/dev/sda2 ro mtrr_spare_reg=3 debug
>>
>
> please use "mtrr_spare_reg_nr=3 debug"
>
> you missed _nr.
>
> YH
>
yinghai,
should i try that boot option too?
can i try anything else?
i hope you remember my emails.
--
kind regards
alex
On Mon, Aug 25, 2008 at 1:19 PM, Alexander Huemer
<[email protected]> wrote:
> Yinghai Lu wrote:
> should i try that boot option too?
> can i try anything else?
> i hope you remember my emails.
your case is different. it seems the whole mtrr_cleanup is not
triggered anyway...
you may try tip/master, and send out you .confg
YH
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
On Tue, Aug 26, 2008 at 2:32 AM, Helge Hafting
<[email protected]> wrote:
> 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:
>
..
> $ 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. :-)
good.
>
> I hope this helps so the extra bootup parameters can be avoided in the
> release kernel.
that is a little bit hard.
YH
Yinghai Lu wrote:
> On Tue, Aug 26, 2008 at 2:32 AM, Helge Hafting
> <[email protected]> wrote:
>> I hope this helps so the extra bootup parameters can be avoided in the
>> release kernel.
>
> that is a little bit hard.
Well, perhaps not 2.6.27, but I hope I won't need
"mtrr_spare_reg_nr=3" forever. Or is my machine a strange
corner case as far as mtrr's are concerned?
Helge Hafting
On Wed, Aug 27, 2008 at 02:53:25PM +0200, Helge Hafting wrote:
> Yinghai Lu wrote:
> >On Tue, Aug 26, 2008 at 2:32 AM, Helge Hafting
> ><[email protected]> wrote:
>
> >>I hope this helps so the extra bootup parameters can be avoided in the
> >>release kernel.
> >
> >that is a little bit hard.
>
> Well, perhaps not 2.6.27, but I hope I won't need
> "mtrr_spare_reg_nr=3" forever. Or is my machine a strange
> corner case as far as mtrr's are concerned?
It's just a side effect of having far too much BIOS code
in the kernel. These basic MTRRs should be set up by the BIOS and when
the kernel starts to think it knows better it ultimatively ends up
being far more platform dependent than it should be.
-Andi