From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RiXQ8-00069V-Vi for garchives@archives.gentoo.org; Wed, 04 Jan 2012 20:26:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 973AB21C218; Wed, 4 Jan 2012 20:26:35 +0000 (UTC) Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by pigeon.gentoo.org (Postfix) with ESMTP id DEEFE21C20A for ; Wed, 4 Jan 2012 20:24:42 +0000 (UTC) Received: by vbih1 with SMTP id h1so6929118vbi.40 for ; Wed, 04 Jan 2012 12:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=rj0nYKui9iaLYmjBet6nDNG7vqC7C+R3AXZ5X4eQv+Y=; b=tSc3tMyAGIkJq39ynJ8/ZcF+MfmJqMVd/6KD+/ipvZbGm0a4dJm/Zc0mSy2mAONq0z 9NGtG+v+XWNrfMhh1Oqt+1znnBA1Yh8zJe+z+uahPcqnXbjnzESctKcMN8MefGj+hFHk YW0P+WBaJhuldyaorz61e5XQpc7syJ2R5pRX8= Received: by 10.52.92.144 with SMTP id cm16mr28052671vdb.90.1325708682374; Wed, 04 Jan 2012 12:24:42 -0800 (PST) Received: from [192.168.9.92] (adsl-76-236-174-54.dsl.klmzmi.sbcglobal.net. [76.236.174.54]) by mx.google.com with ESMTPS id u12sm39220463vde.4.2012.01.04.12.24.40 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 12:24:41 -0800 (PST) Message-ID: <4F04B587.1030201@gmail.com> Date: Wed, 04 Jan 2012 15:24:39 -0500 From: Michael Mol User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20111221 Firefox/9.0.1 SeaMonkey/2.6.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] [OT] Hardware Problems causing kernel panics during large compiles References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: b9a8b1b3-bb08-40be-9a48-9dfa4e8c6b30 X-Archives-Hash: 01bf707381dc68545d0db728f1c7cef4 Jason Weisberger wrote: > Here's the rig: > > AMD Phenom II X3 720 (unlocked to 4 cores and OC'd to 3 Ghz, however > taking it back to stock doesn't affect the problem) > 4 Gigs DDR3-1600 at 7-7-7-16 > ASUS ASUS M4A78T-E AM3 Mobo > MSI N9800GT GeForce 9800 GT 512MB > > other less important things would be two 320GB SATA drives, an IDE dvd > writer, internal card reader, blah blah > > There are two things I can get this system to consistently lock up > while doing: a large compilation such as Chromium, open office, or > GCC, or playing Age of Conan in my separate Windows 7 partition. For > normal everyday tasks, I can't lock the thing up. The system even > plays WoW on maximum settings, Skyrim on max, Counter-Strike Source on > max, 1080p youtube or local videos / movies. > > Watching the processor temp stays relatively low, the GPU temp stays > normal, north bridge temp is good. > > The kernel panics I get are usually recoverable, I can just F7 back > into my desktop and the compile may or may not still be going. If it > is, it's usually dead by the third or fourth panic. > > Memtest86+ ran for 24 hours and found no issues with memory on 18 passes. > > So, pretty much where I'm at is either processor or RAM. Unless > anybody here has a better idea. And how could I test whether it was > the processor or RAM without any current replacement parts? What > tests usually show one over the other? Chromium, at least, is going to force you to start swapping if you've only got 4GB of RAM in the machine, so I'd check smartctl and see if the drive you swap partition on is having any trouble. I'd also suggest removing the NVidia card, going without X for a little while[1], and see if you can reproduce the issue[2]. I'd guess that it's the unlocked core that's the source of your woes, though. Not all X3s are so labeled just for market segmentation. [1] Only because your onboard video is ATI, and flipping between ATI and NVidia configurations for something like this would strike me as too much a hassle. [2] Only because limiting the number of active components helps when troubleshooting hardware issues. I once found a sporadic kernel panic was related to a failing NIC. Another time I found it was related to an old Hauppauge PVR150 that worked fine with my old motherboard, but was incompatible with my new motherboard.