From owner-freebsd-ppc@FreeBSD.ORG Wed Oct 8 19:23:35 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76C4510656A1; Wed, 8 Oct 2008 19:23:35 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9E98FC26; Wed, 8 Oct 2008 19:23:33 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id m98JNU4P038881; Wed, 8 Oct 2008 21:23:31 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <48ED08B2.2080700@fgznet.ch> Date: Wed, 08 Oct 2008 21:23:30 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Peter Grehan References: <20081007140359.EJV63125@dommail.onthenet.com.au> <48EBB0BA.70403@fgznet.ch> In-Reply-To: <48EBB0BA.70403@fgznet.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-ppc@freebsd.org Subject: Re: physical memory limit? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 19:23:35 -0000 Hi Peter, Andreas Tobler wrote: > Peter Grehan wrote: > >>> I remember back in 05 we had a similar issue when I tried >>> 'buildworld' on a G4 alu book. Then you suggested to me >>> to reduce hw.physmem to 512MB. >> >> Indeed, and I'm certain those problems were fixed in r1.115 >> of mmu_oea.c where the secondary PTEG hash was corrected. > > Ok, then I trust you :) Hm, I just read the commit log: --- Remove bogus increment of re-hashed PTEG index. This snuck in with r1.12 of pmap.c, and is potentially the cause of hangs reported on machines with a small amount of memory. On machines with sufficient RAM, and without a lot of processes running, this situation would probably never occur. --- Irritating issue is the part with 'hangs reported on machines with a small amount of memory'. I do not have small amount of ram, neither did I have hangs. I had 11 at that time. Now I have 11 again, but maybe due to other issues. Well on OS-X the machine does not complain. Even memtest doen't complain during the one hour period I let it run. Also, it might be that this needs a looong run of memtest to uncover something. Anyway. >>> I'll reduce/replace the memory and see how it behaves. >> >> OK, let us know how it goes. > > First step passed, I reduced to one 512MB DIMM and a full buildworld > with parallel qt build passed. > I'll try overnight with the other DIMM to exclude single DIMM failures. > But still, I have some more possibilities then, slot1/2 is defect, DIMM > 1 does not like co'op with DIMM 2, ECC vs. non ECC (one is marked with > ECC support, the other isn't). > Will take some hours to find out. Continued and found that both DIMM's seem to work in the first bank. Running a buildworld with a DIMM in the second bank failed for both, ECC/non ECC. So it seems it might be a problem with my HW. :( I even bought a new, non ECC DIMM and I seem to have the same pattern. Right now I try with 768MB (512MB/256MB ECC). Let you know about findings. Regards, Andreas