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