From owner-freebsd-current Sat Apr 13 21:29:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA21952 for current-outgoing; Sat, 13 Apr 1996 21:29:32 -0700 (PDT) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA21945 for ; Sat, 13 Apr 1996 21:29:29 -0700 (PDT) Received: from freebsd.ki.net (root@freebsd.ki.net [205.150.102.51]) by ki.net (8.7.4/8.7.4) with ESMTP id AAA08780; Sun, 14 Apr 1996 00:29:25 -0400 (EDT) Received: from localhost (scrappy@localhost) by freebsd.ki.net (8.7.5/8.7.5) with SMTP id AAA00525; Sun, 14 Apr 1996 00:29:22 -0400 (EDT) X-Authentication-Warning: freebsd.ki.net: scrappy owned process doing -bs Date: Sun, 14 Apr 1996 00:29:21 -0400 (EDT) From: "Marc G. Fournier" To: David Greenman cc: current@freebsd.org Subject: Re: Can someone explain why... In-Reply-To: <199604140418.VAA03036@Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Apr 1996, David Greenman wrote: > >...I get these occasionally while attempting to compile a kernel: > > > >freebsd# make > >cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Winline -g -nostdinc -I. -I../.. -I../../sys -I../../../include -DI486_CPU -DCOMPAT_43 -DDEVFS -DNFS -DFFS -DINET -DDODUMP -DK ERN > >EL ../../kern/subr_xxx.c > >cc: Internal compiler error: program cc1 got fatal signal 10 > >*** Error code 1 > > Seemingly random signal 10 and 11s almost always indicates a hardware > problem. It's usually a problem with memory or the secondary cache, but has > also been known to be caused by flakey disk controllers, motherboards, and > CPUs. I don't think this is disk controller related because you are also > having weird kernel panics in areas where I know no bugs exist. Several years > ago we had some VM system problems which would sometimes cause similar > behavior, but the causes of these problems are well understood and have been > fixed for years. > The only way to troubleshoot this kind of problem is to first look at your > motherboard settings for correctness and then start replacing components until > the problem goes away. I would try changing the memory first. > Okay, I could probably accept this (and most likely will in the end), but why would disabling -O allow it to compile, and then if I remove the object file, re-enable -O cause it to fail exactly the same way? Basically, if I tried to compile it without -O, everything ran as expected, whereas if I tried to use -O, it failed at exactly the same point each time (as if it was tripping over a piece of code that it just couldn't optimize). The funny thing was, if I popped it up to -O2, it also allowed it to compile as expected. Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org