From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 17:08:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8960E106566B; Mon, 14 Nov 2011 17:08:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE678FC12; Mon, 14 Nov 2011 17:08:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08432; Mon, 14 Nov 2011 19:08:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EC14AF1.60907@FreeBSD.org> Date: Mon, 14 Nov 2011 19:08:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alan Cox References: <4EBE4ECC.4060007@FreeBSD.org> <4EC0DD1D.9050704@FreeBSD.org> <4EC1497B.20409@rice.edu> In-Reply-To: <4EC1497B.20409@rice.edu> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alan Cox , FreeBSD current Subject: Re: problem with 1GB pages? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:08:15 -0000 on 14/11/2011 19:01 Alan Cox said the following: > On 11/14/2011 03:19, Andriy Gapon wrote: >> Please disregard my report. >> I've tracked the problem to one of the new modules being faulty. But memtest86* >> tools still don't detect any issues with it. Apparently FreeBSD is a much more >> thorough memory tester than the specialized tools :-) >> Apologies for the noise. > > Interesting, nonetheless. I would have never guessed that disabling 1 GB pages > would mask a problem due to faulty memory. Apologies for withholding the information - the problems actually reappeared even with 1GB pages disable, but for some reason or purely by chance it just took longer than usual. It's then that I started torture tests (libreoffice builds) on individual modules. >> on 12/11/2011 12:47 Andriy Gapon said the following: >>> Introduction. >>> I have an AMD-based system with a Fam10h CPU (with 1GB pages support), the >>> system chipset contains an integrated graphics device (that uses a region of the >>> main memory as a graphics memory). The chipset supports memory hoisting to >>> compensate for the PCI memory window and the graphics aperture both of which are >>> located below 4GB. >>> The latest OS version installed on this system is 9-CURRENT from the middle of >>> September (r225560), architecture is amd64. >>> Until recently the system had 4GB of RAM installed and I had no problems with it >>> whatsoever. >>> >>> Recently though I have added another 4GB of RAM to the system. Before booting >>> to FreeBSD I tested the memory with multiple passes of memtest86 and >>> memetest86+, no errors were detected by those. >>> However with FreeBSD I immediately started getting "flaky memory" symptoms like >>> multiple internal compiler errors during compilation of non-trivially sized >>> projects (world, libreoffice). >>> I re-run memory tests which again revealed nothing and then started playing with >>> various VM subsystem and memory related knobs in FreeBSD. I recalled that a >>> long while ago there were some problems with 1GB pages and so their use used to >>> be disabled. On a hunch I disabled 1GB pages again: >>> @@ -471,7 +471,7 @@ create_pagetables(vm_paddr_t *firstaddr) >>> ndmpdp = 4; >>> DMPDPphys = allocpages(firstaddr, NDMPML4E); >>> ndm1g = 0; >>> - if ((amd_feature& AMDID_PAGE1GB) != 0) >>> + if (0&& (amd_feature& AMDID_PAGE1GB) != 0) >>> ndm1g = ptoa(Maxmem)>> PDPSHIFT; >>> if (ndm1g< ndmpdp) >>> DMPDphys = allocpages(firstaddr, ndmpdp - ndm1g); >>> >>> And the flakiness went away. >>> >>> Not sure what kind of useful information I should provide with this report. >>> Here's couple of things that I think could be of use. >>> >>> - memcontrol list output >>> http://people.freebsd.org/~avg/8gb%2b512mb.memcontrol.list.txt >>> >>> - BIOS memory map >>> SMAP type=01 base=0000000000000000 end=000000000009f800 len=000000000009f800 >>> SMAP type=02 base=00000000000f0000 end=0000000000100000 len=0000000000010000 >>> SMAP type=02 base=00000000fec00000 end=0000000100000000 len=0000000001400000 >>> SMAP type=02 base=00000000e0000000 end=00000000f0000000 len=0000000010000000 >>> SMAP type=02 base=000000000009f800 end=00000000000a0000 len=0000000000000800 >>> SMAP type=02 base=00000000afdf0000 end=00000000afe00000 len=0000000000010000 >>> SMAP type=01 base=0000000000100000 end=00000000afde0000 len=00000000afce0000 >>> SMAP type=03 base=00000000afde3000 end=00000000afdf0000 len=000000000000d000 >>> SMAP type=04 base=00000000afde0000 end=00000000afde3000 len=0000000000003000 >>> SMAP type=01 base=0000000100000000 end=0000000230000000 len=0000000130000000 >>> >>> - dmesg snippet >>> CPU: AMD Athlon(tm) II X2 250 Processor (3013.78-MHz K8-class CPU) >>> Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 Stepping = 2 >>> >>> Features=0x178bfbff >>> >>> Features2=0x802009 >>> AMD Features=0xee500800 >>> AMD >>> Features2=0x37ff >>> >>> TSC: P-state invariant >>> real memory = 8589934592 (8192 MB) >>> avail memory = 7617662976 (7264 MB) >>> >>> - Top Of Memory MSR >>> MSR 0xc001001a: 0x00000000 0xd0000000 >>> >>> - Top Of Memory 2 MSR >>> MSR 0xc001001d: 0x00000002 0x30000000 >>> >>> - System configuration MSR >>> MSR 0xc0010010: 0x00000000 0x00760600 >>> >>> Please let me know if you have any ideas or requests for additional information >>> or testing. >>> Thank you. >> > -- Andriy Gapon