LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* PAT and MTRRs
@ 2008-10-26 23:46 Diego M. Vadell
2008-10-27 0:12 ` Arjan van de Ven
2008-10-27 5:17 ` Yinghai Lu
0 siblings, 2 replies; 10+ messages in thread
From: Diego M. Vadell @ 2008-10-26 23:46 UTC (permalink / raw)
To: Linux Kernel
Hello,
I have 6 identical PCs (HPC cluster) with MTRR problems. In older kernels,
I had to use "mem=3300M", or else, I would get a very slowly boot (as when
you run out of MTRRs).
So I thought that PAT would make this lack of MTRRs problem go away, and
upgraded to 2.6.26.6 and 2.6.27.2, but it didn't: I still get (from dmesg)
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 704MB of RAM.
Most probably, I understood wrong. I read lwn.net's article [1] about PAT
several times, Documentation/x86/pat.txt , tried to use mtrr_chunk_size= and
mtrr_gran_size= in various combinations (as discussed in this LKML thread
[2]), but I still don't get it.
So, what did I miss? Am I wrong thinking that PAT is a better MTRR (wrt
setting the cache type of the RAM)?
Thanks in advance,
-- Diego.
[1] http://lwn.net/Articles/282250/
"The PAT bits are more flexible and, since they live in the page table
entries, they are difficult to run out of. They are also completely under the
control of the operating system instead of the BIOS."
[2] http://lkml.org/lkml/2008/4/29/181
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-26 23:46 PAT and MTRRs Diego M. Vadell
@ 2008-10-27 0:12 ` Arjan van de Ven
2008-10-27 0:21 ` H. Peter Anvin
2008-10-27 5:17 ` Yinghai Lu
1 sibling, 1 reply; 10+ messages in thread
From: Arjan van de Ven @ 2008-10-27 0:12 UTC (permalink / raw)
To: Diego M. Vadell; +Cc: Linux Kernel
On Sun, 26 Oct 2008 22:46:21 -0100
"Diego M. Vadell" <dvadell@linuxclusters.com.ar> wrote:
> Hello,
>
> I have 6 identical PCs (HPC cluster) with MTRR problems. In older
> kernels, I had to use "mem=3300M", or else, I would get a very slowly
> boot (as when you run out of MTRRs).
>
> So I thought that PAT would make this lack of MTRRs problem go
> away, and upgraded to 2.6.26.6 and 2.6.27.2, but it didn't: I still
> get (from dmesg)
>
> x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 704MB
> of RAM.
>
> Most probably, I understood wrong. I read lwn.net's article [1]
> about PAT several times, Documentation/x86/pat.txt , tried to use
> mtrr_chunk_size= and mtrr_gran_size= in various combinations (as
> discussed in this LKML thread [2]), but I still don't get it.
>
> So, what did I miss? Am I wrong thinking that PAT is a better MTRR
> (wrt setting the cache type of the RAM)?
>
PAT can't make memory cachable that the MTRR's have as uncachable.
What PAT *can* do is, within an MTRR, do fine grained mapping...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-27 0:12 ` Arjan van de Ven
@ 2008-10-27 0:21 ` H. Peter Anvin
2008-10-27 0:34 ` Arjan van de Ven
0 siblings, 1 reply; 10+ messages in thread
From: H. Peter Anvin @ 2008-10-27 0:21 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Diego M. Vadell, Linux Kernel
Arjan van de Ven wrote:
>
> PAT can't make memory cachable that the MTRR's have as uncachable.
> What PAT *can* do is, within an MTRR, do fine grained mapping...
>
Now, if it wasn't for the braindamage called ACPI and SMM, we could have
cleared the MTRR settings and just used PAT...
-hpa
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-27 0:21 ` H. Peter Anvin
@ 2008-10-27 0:34 ` Arjan van de Ven
2008-10-27 0:38 ` H. Peter Anvin
0 siblings, 1 reply; 10+ messages in thread
From: Arjan van de Ven @ 2008-10-27 0:34 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Diego M. Vadell, Linux Kernel
On Sun, 26 Oct 2008 17:21:41 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:
> Arjan van de Ven wrote:
> >
> > PAT can't make memory cachable that the MTRR's have as uncachable.
> > What PAT *can* do is, within an MTRR, do fine grained mapping...
> >
>
> Now, if it wasn't for the braindamage called ACPI and SMM, we could
> have cleared the MTRR settings and just used PAT...
>
yeah.. one thing we need to investigate is if we can set the default
"no mtrr coverage" value to cached
(and also.. to check we don't set that to uncached if the bios had it
set to cached..)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for ape savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-27 0:34 ` Arjan van de Ven
@ 2008-10-27 0:38 ` H. Peter Anvin
0 siblings, 0 replies; 10+ messages in thread
From: H. Peter Anvin @ 2008-10-27 0:38 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Diego M. Vadell, Linux Kernel
Arjan van de Ven wrote:
>>>
>> Now, if it wasn't for the braindamage called ACPI and SMM, we could
>> have cleared the MTRR settings and just used PAT...
>
> yeah.. one thing we need to investigate is if we can set the default
> "no mtrr coverage" value to cached
> (and also.. to check we don't set that to uncached if the bios had it
> set to cached..)
>
Well, in the end it comes down to the same thing: SMM expects the memory
map to reside in MTRRs. We can "sanitize" the memory map, but we can't
throw it out the window like what we really should be able to.
-hpa
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-26 23:46 PAT and MTRRs Diego M. Vadell
2008-10-27 0:12 ` Arjan van de Ven
@ 2008-10-27 5:17 ` Yinghai Lu
2008-10-31 22:42 ` Diego M. Vadell
1 sibling, 1 reply; 10+ messages in thread
From: Yinghai Lu @ 2008-10-27 5:17 UTC (permalink / raw)
To: Diego M. Vadell; +Cc: Linux Kernel
On Sun, Oct 26, 2008 at 4:46 PM, Diego M. Vadell
<dvadell@linuxclusters.com.ar> wrote:
> Hello,
>
> I have 6 identical PCs (HPC cluster) with MTRR problems. In older kernels,
> I had to use "mem=3300M", or else, I would get a very slowly boot (as when
> you run out of MTRRs).
can you try 2.6.28-rc2 ot tip/master and boot with mtrr_cleanup_debug ?
YH
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-27 5:17 ` Yinghai Lu
@ 2008-10-31 22:42 ` Diego M. Vadell
2008-10-31 23:19 ` Yinghai Lu
2008-10-31 23:35 ` Yinghai Lu
0 siblings, 2 replies; 10+ messages in thread
From: Diego M. Vadell @ 2008-10-31 22:42 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Diego M. Vadell, Linux Kernel
> can you try 2.6.28-rc2 ot tip/master and boot with mtrr_cleanup_debug ?
>
> YH
Hello,
Thank you very much and sorry for the delay. This is a remote site and I
have to travel to get here.
I upgradedt to 2.6.28-rc2 but the problem persists. Here is the
(hopefully) relevant part of dmesg:
BIOS EBDA/lowmem at: 0009fc00/0009fc00
Linux version 2.6.28-rc2 (root@compute-0-5.local) (gcc version 3.4.6
20060404 (Red Hat 3.4.6-8))
#1 SMP Fri Oct 31 18:01:52 ART 2008
Command line: ro root=LABEL=/ mtrr_cleanup_debug
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
Centaur CentaurHauls
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cf561000 (usable)
BIOS-e820: 00000000cf561000 - 00000000cf56e000 (reserved)
BIOS-e820: 00000000cf56e000 - 00000000cf612000 (usable)
BIOS-e820: 00000000cf612000 - 00000000cf6e9000 (ACPI NVS)
BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
BIOS-e820: 00000000cf6ed000 - 00000000cf6f2000 (ACPI data)
BIOS-e820: 00000000cf6f2000 - 00000000cf6f3000 (usable)
BIOS-e820: 00000000cf6f3000 - 00000000cf6ff000 (ACPI data)
BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
BIOS-e820: 00000000cf700000 - 00000000d0000000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
DMI 2.4 present.
last_pfn = 0x12c000 max_arch_pfn = 0x3ffffffff
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
After WB checking
MTRR MAP PFN: 0000000000000000 - 00000000000d0000
After UC checking
MTRR MAP PFN: 0000000000000000 - 00000000000cf700
After sorting
MTRR MAP PFN: 0000000000000000 - 00000000000cf700
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 704MB of RAM.
------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1662
mtrr_trim_uncached_memory+0x331/0x358()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.28-rc2 #1
Call Trace:
[<ffffffff80232c63>] warn_on_slowpath+0x51/0x6d
[<ffffffff80233b5f>] printk+0x8d/0x95
[<ffffffff80306735>] generic_swap+0x0/0x19
[<ffffffff8060a92e>] cmp_range+0x0/0x6
[<ffffffff8060b4f0>] mtrr_trim_uncached_memory+0x331/0x358
[<ffffffff803efcf7>] dmi_table+0x6f/0x96
[<ffffffff80621aa3>] dmi_decode+0x0/0x4ab
[<ffffffff806072a8>] setup_arch+0x3f9/0x63c
[<ffffffff8060083c>] start_kernel+0x6a/0x307
[<ffffffff806003a1>] x86_64_start_kernel+0xef/0xf3
---[ end trace 4eaa2a86a8e2da22 ]---
update e820 for mtrr
modified physical RAM map:
modified: 0000000000000000 - 000000000008f000 (usable)
modified: 000000000008f000 - 00000000000a0000 (reserved)
modified: 00000000000e0000 - 0000000000100000 (reserved)
modified: 0000000000100000 - 00000000cf561000 (usable)
modified: 00000000cf561000 - 00000000cf56e000 (reserved)
modified: 00000000cf56e000 - 00000000cf612000 (usable)
modified: 00000000cf612000 - 00000000cf6e9000 (ACPI NVS)
modified: 00000000cf6e9000 - 00000000cf6ed000 (usable)
modified: 00000000cf6ed000 - 00000000cf6f2000 (ACPI data)
modified: 00000000cf6f2000 - 00000000cf6f3000 (usable)
modified: 00000000cf6f3000 - 00000000cf6ff000 (ACPI data)
modified: 00000000cf6ff000 - 00000000cf700000 (usable)
modified: 00000000cf700000 - 00000000d0000000 (reserved)
modified: 00000000fff00000 - 000000012c000000 (reserved)
last_pfn = 0xcf700 max_arch_pfn = 0x3ffffffff
init_memory_mapping
0000000000 - 00cf600000 page 2M
00cf600000 - 00cf700000 page 4k
kernel direct mapping tables up to cf700000 @ 8000-e000
last_map_addr: cf700000 end: cf700000
RAMDISK: 37ef3000 - 37fef849
ACPI: RSDP 000FE020, 0014 (r0 INTEL )
ACPI: RSDT CF6FD038, 004C (r1 INTEL DG965WH 697 1000013)
ACPI: FACP CF6FC000, 0074 (r1 INTEL DG965WH 697 MSFT 1000013)
ACPI: DSDT CF6F7000, 40ED (r1 INTEL DG965WH 697 MSFT 1000013)
ACPI: FACS CF6A0000, 0040
ACPI: APIC CF6F6000, 0078 (r1 INTEL DG965WH 697 MSFT 1000013)
ACPI: WDDT CF6F5000, 0040 (r1 INTEL DG965WH 697 MSFT 1000013)
ACPI: MCFG CF6F4000, 003C (r1 INTEL DG965WH 697 MSFT 1000013)
ACPI: ASF! CF6F3000, 00A6 (r32 INTEL DG965WH 697 MSFT 1000013)
ACPI: SSDT CF6F1000, 01BC (r1 INTEL CpuPm 697 MSFT 1000013)
ACPI: SSDT CF6F0000, 0175 (r1 INTEL Cpu0Ist 697 MSFT 1000013)
ACPI: SSDT CF6EF000, 0175 (r1 INTEL Cpu1Ist 697 MSFT 1000013)
ACPI: SSDT CF6EE000, 0175 (r1 INTEL Cpu2Ist 697 MSFT 1000013)
ACPI: SSDT CF6ED000, 0175 (r1 INTEL Cpu3Ist 697 MSFT 1000013)
ACPI: Local APIC address 0xfee00000
(6 early reservations) ==> bootmem [0000000000 - 00cf700000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
#1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
#2 [0000200000 - 00006ddca8] TEXT DATA BSS ==> [0000200000 - 00006ddca8]
#3 [0037ef3000 - 0037fef849] RAMDISK ==> [0037ef3000 - 0037fef849]
#4 [000009fc00 - 0000100000] BIOS reserved ==> [000009fc00 - 0000100000]
#5 [0000008000 - 000000c000] PGTABLE ==> [0000008000 - 000000c000]
found SMP MP-table at [ffff8800000fe200] 000fe200
[ffffe20000000000-ffffe200033fffff] PMD ->
[ffff880001200000-ffff8800045fffff] on node 0
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[6] active PFN ranges
0: 0x00000000 -> 0x0000008f
0: 0x00000100 -> 0x000cf561
0: 0x000cf56e -> 0x000cf612
0: 0x000cf6e9 -> 0x000cf6ed
0: 0x000cf6f2 -> 0x000cf6f3
0: 0x000cf6ff -> 0x000cf700
On node 0 totalpages: 849306
DMA zone: 64 pages used for memmap
DMA zone: 1350 pages reserved
DMA zone: 2569 pages, LIFO batch:0
DMA32 zone: 13212 pages used for memmap
DMA32 zone: 832111 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 4 CPUs, 0 hotplug CPUs
Allocating PCI resources starting at d4000000 (gap: d0000000:2ff00000)
PERCPU: Allocating 49152 bytes of per cpu data
NR_CPUS: 8, nr_cpu_ids: 4, nr_node_ids 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 834680
Kernel command line: ro root=LABEL=/ mtrr_cleanup_debug
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Fast TSC calibration using PIT
Detected 2397.700 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
No AGP bridge found
Memory: 3330720k/3398656k available (2536k kernel code, 65836k reserved,
1406k data, 376k init)
SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Calibrating delay loop (skipped), value calculated using timer frequency..
4795.40 BogoMIPS (lpj=9590800)
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM2)
using mwait in idle threads.
Freeing SMP alternatives: 22k freed
ACPI: Core revision 20080926
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b
Booting processor 1 APIC 0x2 ip 0x6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 4795.51 BogoMIPS
(lpj=9591031)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 2
CPU1: Thermal monitoring enabled (TM2)
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Booting processor 2 APIC 0x1 ip 0x6000
Initializing CPU#2
Calibrating delay using timer specific routine.. 4795.50 BogoMIPS
(lpj=9591000)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU2: Thermal monitoring enabled (TM2)
x86 PAT enabled: cpu 2, old 0x7040600070406, new 0x7010600070106
CPU2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b
checking TSC synchronization [CPU#0 -> CPU#2]: passed.
Booting processor 3 APIC 0x3 ip 0x6000
Initializing CPU#3
Calibrating delay using timer specific routine.. 4795.50 BogoMIPS
(lpj=9591018)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 3
CPU3: Thermal monitoring enabled (TM2)
x86 PAT enabled: cpu 3, old 0x7040600070406, new 0x7010600070106
CPU3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b
checking TSC synchronization [CPU#0 -> CPU#3]: passed.
Brought up 4 CPUs
Total of 4 processors activated (19181.92 BogoMIPS).
I can send you the complete dmesg if you want.
Thanks again,
-- Diego
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-31 22:42 ` Diego M. Vadell
@ 2008-10-31 23:19 ` Yinghai Lu
2008-10-31 23:35 ` Yinghai Lu
1 sibling, 0 replies; 10+ messages in thread
From: Yinghai Lu @ 2008-10-31 23:19 UTC (permalink / raw)
To: Diego M. Vadell; +Cc: Linux Kernel
Diego M. Vadell wrote:
>> can you try 2.6.28-rc2 ot tip/master and boot with mtrr_cleanup_debug ?
>>
>> YH
>
> Hello,
> Thank you very much and sorry for the delay. This is a remote site and I
> have to travel to get here.
>
> I upgradedt to 2.6.28-rc2 but the problem persists. Here is the
> (hopefully) relevant part of dmesg:
>
> BIOS EBDA/lowmem at: 0009fc00/0009fc00
> Linux version 2.6.28-rc2 (root@compute-0-5.local) (gcc version 3.4.6
> 20060404 (Red Hat 3.4.6-8))
> #1 SMP Fri Oct 31 18:01:52 ART 2008
> Command line: ro root=LABEL=/ mtrr_cleanup_debug
> KERNEL supported cpus:
> Intel GenuineIntel
> AMD AuthenticAMD
> Centaur CentaurHauls
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
> BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000cf561000 (usable)
> BIOS-e820: 00000000cf561000 - 00000000cf56e000 (reserved)
> BIOS-e820: 00000000cf56e000 - 00000000cf612000 (usable)
> BIOS-e820: 00000000cf612000 - 00000000cf6e9000 (ACPI NVS)
> BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
> BIOS-e820: 00000000cf6ed000 - 00000000cf6f2000 (ACPI data)
> BIOS-e820: 00000000cf6f2000 - 00000000cf6f3000 (usable)
> BIOS-e820: 00000000cf6f3000 - 00000000cf6ff000 (ACPI data)
> BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
> BIOS-e820: 00000000cf700000 - 00000000d0000000 (reserved)
> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
> DMI 2.4 present.
> last_pfn = 0x12c000 max_arch_pfn = 0x3ffffffff
> x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> After WB checking
> MTRR MAP PFN: 0000000000000000 - 00000000000d0000
> After UC checking
> MTRR MAP PFN: 0000000000000000 - 00000000000cf700
> After sorting
> MTRR MAP PFN: 0000000000000000 - 00000000000cf700
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 704MB of RAM.
> ------------[ cut here ]------------
> WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1662
> mtrr_trim_uncached_memory+0x331/0x358()
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 2.6.28-rc2 #1
> Call Trace:
> [<ffffffff80232c63>] warn_on_slowpath+0x51/0x6d
> [<ffffffff80233b5f>] printk+0x8d/0x95
> [<ffffffff80306735>] generic_swap+0x0/0x19
> [<ffffffff8060a92e>] cmp_range+0x0/0x6
> [<ffffffff8060b4f0>] mtrr_trim_uncached_memory+0x331/0x358
> [<ffffffff803efcf7>] dmi_table+0x6f/0x96
> [<ffffffff80621aa3>] dmi_decode+0x0/0x4ab
> [<ffffffff806072a8>] setup_arch+0x3f9/0x63c
> [<ffffffff8060083c>] start_kernel+0x6a/0x307
> [<ffffffff806003a1>] x86_64_start_kernel+0xef/0xf3
> ---[ end trace 4eaa2a86a8e2da22 ]---
> update e820 for mtrr
> modified physical RAM map:
> modified: 0000000000000000 - 000000000008f000 (usable)
> modified: 000000000008f000 - 00000000000a0000 (reserved)
> modified: 00000000000e0000 - 0000000000100000 (reserved)
> modified: 0000000000100000 - 00000000cf561000 (usable)
> modified: 00000000cf561000 - 00000000cf56e000 (reserved)
> modified: 00000000cf56e000 - 00000000cf612000 (usable)
> modified: 00000000cf612000 - 00000000cf6e9000 (ACPI NVS)
> modified: 00000000cf6e9000 - 00000000cf6ed000 (usable)
> modified: 00000000cf6ed000 - 00000000cf6f2000 (ACPI data)
> modified: 00000000cf6f2000 - 00000000cf6f3000 (usable)
> modified: 00000000cf6f3000 - 00000000cf6ff000 (ACPI data)
> modified: 00000000cf6ff000 - 00000000cf700000 (usable)
> modified: 00000000cf700000 - 00000000d0000000 (reserved)
> modified: 00000000fff00000 - 000000012c000000 (reserved)
> last_pfn = 0xcf700 max_arch_pfn = 0x3ffffffff
do you have
# grep MTRR .config
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
in your config files..
it seems mtrr_cleanup is not triggered...
also please put debug in your boot command line. like
ro root=LABEL=/ mtrr_cleanup_debug debug
YH
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-31 22:42 ` Diego M. Vadell
2008-10-31 23:19 ` Yinghai Lu
@ 2008-10-31 23:35 ` Yinghai Lu
2008-11-11 14:30 ` Diego M. Vadell
1 sibling, 1 reply; 10+ messages in thread
From: Yinghai Lu @ 2008-10-31 23:35 UTC (permalink / raw)
To: Diego M. Vadell; +Cc: Linux Kernel
Diego M. Vadell wrote:
>> can you try 2.6.28-rc2 ot tip/master and boot with mtrr_cleanup_debug ?
>>
>> YH
>
> Hello,
> Thank you very much and sorry for the delay. This is a remote site and I
> have to travel to get here.
>
> I upgradedt to 2.6.28-rc2 but the problem persists. Here is the
> (hopefully) relevant part of dmesg:
>
> BIOS EBDA/lowmem at: 0009fc00/0009fc00
> Linux version 2.6.28-rc2 (root@compute-0-5.local) (gcc version 3.4.6
> 20060404 (Red Hat 3.4.6-8))
> #1 SMP Fri Oct 31 18:01:52 ART 2008
> Command line: ro root=LABEL=/ mtrr_cleanup_debug
> KERNEL supported cpus:
> Intel GenuineIntel
> AMD AuthenticAMD
> Centaur CentaurHauls
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
> BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000cf561000 (usable)
> BIOS-e820: 00000000cf561000 - 00000000cf56e000 (reserved)
> BIOS-e820: 00000000cf56e000 - 00000000cf612000 (usable)
> BIOS-e820: 00000000cf612000 - 00000000cf6e9000 (ACPI NVS)
> BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
> BIOS-e820: 00000000cf6ed000 - 00000000cf6f2000 (ACPI data)
> BIOS-e820: 00000000cf6f2000 - 00000000cf6f3000 (usable)
> BIOS-e820: 00000000cf6f3000 - 00000000cf6ff000 (ACPI data)
> BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
> BIOS-e820: 00000000cf700000 - 00000000d0000000 (reserved)
> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
> DMI 2.4 present.
> last_pfn = 0x12c000 max_arch_pfn = 0x3ffffffff
> x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> After WB checking
> MTRR MAP PFN: 0000000000000000 - 00000000000d0000
> After UC checking
> MTRR MAP PFN: 0000000000000000 - 00000000000cf700
> After sorting
> MTRR MAP PFN: 0000000000000000 - 00000000000cf700
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 704MB of RAM.
> ------------[ cut here ]------------
> WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1662
> mtrr_trim_uncached_memory+0x331/0x358()
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 2.6.28-rc2 #1
> Call Trace:
> [<ffffffff80232c63>] warn_on_slowpath+0x51/0x6d
> [<ffffffff80233b5f>] printk+0x8d/0x95
> [<ffffffff80306735>] generic_swap+0x0/0x19
> [<ffffffff8060a92e>] cmp_range+0x0/0x6
> [<ffffffff8060b4f0>] mtrr_trim_uncached_memory+0x331/0x358
> [<ffffffff803efcf7>] dmi_table+0x6f/0x96
> [<ffffffff80621aa3>] dmi_decode+0x0/0x4ab
> [<ffffffff806072a8>] setup_arch+0x3f9/0x63c
> [<ffffffff8060083c>] start_kernel+0x6a/0x307
> [<ffffffff806003a1>] x86_64_start_kernel+0xef/0xf3
> ---[ end trace 4eaa2a86a8e2da22 ]---
> update e820 for mtrr
> modified physical RAM map:
> modified: 0000000000000000 - 000000000008f000 (usable)
> modified: 000000000008f000 - 00000000000a0000 (reserved)
> modified: 00000000000e0000 - 0000000000100000 (reserved)
> modified: 0000000000100000 - 00000000cf561000 (usable)
> modified: 00000000cf561000 - 00000000cf56e000 (reserved)
> modified: 00000000cf56e000 - 00000000cf612000 (usable)
> modified: 00000000cf612000 - 00000000cf6e9000 (ACPI NVS)
> modified: 00000000cf6e9000 - 00000000cf6ed000 (usable)
> modified: 00000000cf6ed000 - 00000000cf6f2000 (ACPI data)
> modified: 00000000cf6f2000 - 00000000cf6f3000 (usable)
> modified: 00000000cf6f3000 - 00000000cf6ff000 (ACPI data)
> modified: 00000000cf6ff000 - 00000000cf700000 (usable)
> modified: 00000000cf700000 - 00000000d0000000 (reserved)
> modified: 00000000fff00000 - 000000012c000000 (reserved)
> last_pfn = 0xcf700 max_arch_pfn = 0x3ffffffff
your bios doesn't cover 4g above RAM..
please do
1. boot linux with "disable_mtrr_trim"
2. after booting input:
echo "base=0x100000000 size=0x20000000 type=write-back" >/proc/mtrr
echo "base=0x120000000 size=0x8000000 type=write-back" >/proc/mtrr
echo "base=0x128000000 size=0x4000000 type=write-back" >/proc/mtrr
later you could put those three lines in one scripts and call it from inittab
# grep mtrrfixup /etc/inittab
mtrrfixup:345:once:/root/mtrrfixup.sh
YH
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PAT and MTRRs
2008-10-31 23:35 ` Yinghai Lu
@ 2008-11-11 14:30 ` Diego M. Vadell
0 siblings, 0 replies; 10+ messages in thread
From: Diego M. Vadell @ 2008-11-11 14:30 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Linux Kernel
> your bios doesn't cover 4g above RAM..
>
> please do
> 1. boot linux with "disable_mtrr_trim"
> 2. after booting input:
> echo "base=0x100000000 size=0x20000000 type=write-back" >/proc/mtrr
> echo "base=0x120000000 size=0x8000000 type=write-back" >/proc/mtrr
> echo "base=0x128000000 size=0x4000000 type=write-back" >/proc/mtrr
>
> later you could put those three lines in one scripts and call it from
> inittab # grep mtrrfixup /etc/inittab
> mtrrfixup:345:once:/root/mtrrfixup.sh
>
> YH
> --
Hi,
It worked! It takes 10 minutes to boot, but it gets speedy somewhere in the
booting process. I checked the memory speed with "stream" and its working.
Just for the record, I had to change the line in /etc/inittab
to "mtrr:345:once:/root/mtrrfixup.sh" or else, init would complain about the
first field being more than 4 characters.
Thank you very much
-- Diego
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-11-11 14:30 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-26 23:46 PAT and MTRRs Diego M. Vadell
2008-10-27 0:12 ` Arjan van de Ven
2008-10-27 0:21 ` H. Peter Anvin
2008-10-27 0:34 ` Arjan van de Ven
2008-10-27 0:38 ` H. Peter Anvin
2008-10-27 5:17 ` Yinghai Lu
2008-10-31 22:42 ` Diego M. Vadell
2008-10-31 23:19 ` Yinghai Lu
2008-10-31 23:35 ` Yinghai Lu
2008-11-11 14:30 ` Diego M. Vadell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).