From owner-freebsd-questions Sat Dec 7 13:50:35 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0054237B401 for ; Sat, 7 Dec 2002 13:50:32 -0800 (PST) Received: from rutger.owt.com (rutger.owt.com [204.118.6.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EA9C43EB2 for ; Sat, 7 Dec 2002 13:50:31 -0800 (PST) (envelope-from kstewart@owt.com) Received: from owt-207-41-94-233.owt.com (owt-207-41-94-233.owt.com [207.41.94.233]) by rutger.owt.com (8.9.3/8.9.3) with ESMTP id NAA05464; Sat, 7 Dec 2002 13:50:26 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Kent Stewart To: John Mills , John Mills Subject: Re: buildworld fail Date: Sat, 7 Dec 2002 13:50:26 -0800 User-Agent: KMail/1.4.3 Cc: freebsd-questions References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200212071350.26164.kstewart@owt.com> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday 07 December 2002 05:40 am, John Mills wrote: > Kent, all - > > On Fri, 6 Dec 2002, Kent Stewart wrote: > > Just remember that a signal 11 in a compile is usually your > > hardware telling you something is wrong. If it dies at the same > > spot, it can be options or whatever. If you use strange options, > > you have to try them first but still remember a signal 11is > > normally related to memory or heating problems. > > Yes, but when several users with different systems in different > parts of the world report the same message in the same spot, I > rather suspect a configuration or tool issue. For example, tripling > the RAM didn't change it. I agree, if it is exactly the same spot. I have several machines that=20 are not having problems. I have a AMD 2000+ that I will do a=20 buildworld on if someone is having trouble. It was upgraded to=20 RELENG_4 2 days ago. All that means is that it tends to points to=20 your machine more than RELENG_4. I trust RELENG_4 to the point that=20 it has my cvs-mirror on it. It i also fast enough that I won't miss=20 the 20 minutes of cpu time required to do a buildworld. I also think that if you have a system built on a bad set of options,=20 you can have real problems upgrading to get rid of a buggy compiler=20 and userland. If I am given a choice of a system that runs 10% slower=20 and is absolutely stable, I will run that way rather than add options=20 to get the 10%. I think the time is being spent on gcc-3 as far as=20 cpu options are concerned. I dropped back to defaults when I reached=20 that conclusion. I have one system that I added an 80 GB HD. Adding it involved=20 rearranging my HDs in the case. I cross mounted 2 of them and the=20 system wouldn't boot. I moved them where they were supposed to be and=20 still had problems doing builds. It was if I broke some links. In=20 order to get a stable system, I had to NFS mount /usr/src and=20 /usr/obj and do my installkernel and installworld from it. > > I may well have a bad set of configuration options for these newer > releases. I am very new to FreeBSD. I followed the Handbook > configuration instructions to reflect my hardware and didn't > knowingly set compiler options at all. Your note was the first to > remark on compiler options in connection with this error message so > it certainly warrants my attention. > > I build RELENG_4_5 seamlessly with the same configuration file (in > a RELENG_4_5 installation, however), so an environmental or > generational issue is likely here. Everytime you upgrade a level, i.e., 4.5 to 4.6, I think you should=20 redo your kernel config file. You never know what has been obsoleted=20 and added. > > I _have_ also hit heating problems and swap overruns, but these > showed different 'footprints'. The partition size issue is my real > stimulus to reconfigure the setup before I am more invested and > dependent on it: "A house built on sand ..." etc. Yes, that footprint is readily apparent once you have hit it. I think=20 people forget that when you have heating problems, a single bad build=20 means more than 5 or 6 good ones.=20 There were so many signal 11's in the past that they wrote a FAQ on=20 it. It is at=20 http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#SI= GNAL11 and is a good place to bookmark. Much less trouble than finding it=20 when you need it :). I have /usr/src and /usr/obj in their own 1.5 GB partitions on their=20 own HDs. Each HD has its own ATA-100 controller. Most of these=20 machines have 256 MB of memory and don't swap. My gateway only has=20 128 MB but I have never looked at swap while I was doing a=20 buildworld. I also have setiathome running in the background while=20 everything is going on. The systems are always at 100% cpu. When you=20 run out of swap, the system used to just panic. I don't think that=20 has changed. I started out with small /, /var, and /tmp. My later versions have /=20 with 250 MB and /var and /tmp each have 1.5 GB. The large /var lets=20 me log everything from my cvsups (ports, docs, src), builds, and=20 installs. Part of the cvsup update process converts the cvsup.log=20 into an html file that lets my web browser link directly into the=20 cvs-repository. When I have used up 1/2 of /var, I clean out the old=20 stuff. > > Thanks for your comments. I need to dig out my error messages and > compare the compilation options with the other poster's. Good luck on finding the problem. Kent > > Regards. > - John Mills > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message --=20 Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message