From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 9 18:57:15 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7430716A4CE for ; Wed, 9 Mar 2005 18:57:15 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3794843D5C for ; Wed, 9 Mar 2005 18:57:15 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from [172.17.64.85] (sv-fw.looksmart.com [64.241.242.18]) by carver.gumbysoft.com (Postfix) with ESMTP id 1E05A72DCB; Wed, 9 Mar 2005 10:57:15 -0800 (PST) In-Reply-To: References: <3e4aa11492a6bd41859f0490f2e94202@gumbysoft.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Doug White Date: Wed, 9 Mar 2005 10:57:17 -0800 To: Aaron Daubman X-Mailer: Apple Mail (2.619.2) cc: freebsd-amd64@freebsd.org Subject: Re: Consistant buildworld Segmentation fault at '===> gnu/usr.bin/cc/cpp' after latest RELENG_5 cvsup X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 18:57:15 -0000 On Mar 9, 2005, at 10:50 AM, Aaron Daubman wrote: > Hi Doug, > >>> ===> gnu/usr.bin/cc/cpp >>> Segmentation fault (core dumped) >>> *** Error code 139 >> [...] >> >> The typical reason for segfaults is bad hardware. A v20z is a pretty >> decent server class machine, though, so unless its suffering from an >> undetected condition it should scream bloody murder if something goes >> bad. This is assuming it has ECC memory and you aren't ignoring that >> big yellow "maintenance" light that comes on when something bad >> happens, like a fan going down. >> >> Can you get into the LOM and check the environmentals? > > Everything is showing up as "Nominal" status. > One note that might make a difference: > The system is a Dual Opteron - not single. I was going by dmesg > output (and since GENERIC is non-SMP...), not on what I had actually > ordered (or LOM status showed ;-). Ok, good to check that. > Also, isn't segfault usually only indicative of hardware failure when > it does not reliably occur at the exact same spot? Not necessarily. It could be a pattern-related failure. If it was a software bug I'd expect more reports of problems. V20z's are pretty common. > I should mention that this box was running some fairly intensive > network management software under Windows 2003 server for a month or > so solid as well - which would make me lean away from hardware > faults... Unfortunately that proves nothing. It casts doubt on a hardware fault but cannot exclude it entirely, due to differing OS access patterns. > Any suggestions as to what to change HT settings to - or if that's a > worthwhile avenue to go down? Opterons don't support HyperThreading, so there will be no option to turn it off. You might try installing 5.3-RELEASE and trying to build up from there. That might replace whatever the broken file is that cvsup can't detect. You may need to temporarily move the system down to 4GB of RAM to work around a bug in the release. Also check the system date & time ... if they are off even by a few days you can get weird failures when building. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org