From owner-freebsd-questions@freebsd.org Wed May 4 08:20:17 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13CC5B2D1AF for ; Wed, 4 May 2016 08:20:17 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB0881939 for ; Wed, 4 May 2016 08:20:16 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de (port-92-195-216-66.dynamic.qsc.de [92.195.216.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx02.qsc.de (Postfix) with ESMTPS id 7DCEB2451C; Wed, 4 May 2016 10:20:13 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id u448KCWL002177; Wed, 4 May 2016 10:20:12 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Wed, 4 May 2016 10:20:12 +0200 From: Polytropon To: Manish Jain Cc: freebsd-questions@freebsd.org, galtsev@kicp.uchicago.edu Subject: Re: Is 10.3 i386 jinxed ? Message-Id: <20160504102012.4d57d3ca.freebsd@edvax.de> In-Reply-To: References: <20160430084415.03be443d.freebsd@edvax.de> <5724604D.3020804@hotmail.com> <20160430203426.a9d5841b.freebsd@edvax.de> <5725CF38.4090007@hotmail.com> <572752E2.2040708@hotmail.com> <20160503181839.2aacad7e.freebsd@edvax.de> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 08:20:17 -0000 On Wed, 4 May 2016 12:41:06 +0530, Manish Jain wrote: > On 05/04/16 10:35, Warren Block wrote: > > On Wed, 4 May 2016, Manish Jain wrote: > > > >> What is printed underneath is NE56R14l-B9502G32Mnks > >> > >> I can't be sure whether the l is actually l or I or 1 > > > > Looks like this one: > > http://in.gateway.com/gw/en/IN/content/model/NX.Y1USI.005 > > > > Which does not have a separate GPU, and means that the bad memory > > would be in one of the removable DIMMs. > > > > > > > Something to cheer about, at last. But then why does not memtest86+ pick > up any errors in 65 passes ? As I mentioned earlier, this is a "false-negative" result. The portions of the RAM dedicated for the GPU are "cut away" quite eary, so memtest can only test what's left for "normal RAM". And those portions don't seem to have the error. The "GPU RAM" portions cannot be tested with memtest because it cannot access them: To the memtest access routine, the situation is as follows: Let's say there are 4 GB RAM, 1 GB dedicated for GPU, so for memtest there's 3 GB RAM to check. _Where_ this is located - well, that depends on how the system BIOS/EFI decides on where to place the GPU RAM segment ("internal addressing"). Let's assume you have two chips of 2 GB each, this _could_ be the layout: +--------------------+ Bank 0: |VVVFVVVVVV | 2 GB +----------^---------+ RAM address 00000000 here +--------------------+ Bank 1: | | 2 GB +--------------------+ Then memtest will check from 00000000 to the end of the 3 GB RAM, and the fault (F) is within the GPU RAM (V). It won't be tested. Maybe you could just swap the modules an re-run the test. However, it's hard to say _where_ the GPU RAM will end up, maybe at the beginning of bank 1? Maybe a "random choice"? Or maybe it isn't even one contiguous memory space? -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...