Date: Sat, 7 Dec 2002 13:50:26 -0800 From: Kent Stewart <kstewart@owt.com> To: John Mills <john.m.mills@alum.mit.edu>, John Mills <jmmills@telocity.com> Cc: freebsd-questions <freebsd-questions@FreeBSD.ORG> Subject: Re: buildworld fail Message-ID: <200212071350.26164.kstewart@owt.com> In-Reply-To: <Pine.LNX.4.21.0212070822450.2236-100000@otter.mills-atl.com> References: <Pine.LNX.4.21.0212070822450.2236-100000@otter.mills-atl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 are not having problems. I have a AMD 2000+ that I will do a buildworld on if someone is having trouble. It was upgraded to RELENG_4 2 days ago. All that means is that it tends to points to your machine more than RELENG_4. I trust RELENG_4 to the point that it has my cvs-mirror on it. It i also fast enough that I won't miss 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, you can have real problems upgrading to get rid of a buggy compiler and userland. If I am given a choice of a system that runs 10% slower and is absolutely stable, I will run that way rather than add options to get the 10%. I think the time is being spent on gcc-3 as far as cpu options are concerned. I dropped back to defaults when I reached that conclusion. I have one system that I added an 80 GB HD. Adding it involved rearranging my HDs in the case. I cross mounted 2 of them and the system wouldn't boot. I moved them where they were supposed to be and still had problems doing builds. It was if I broke some links. In order to get a stable system, I had to NFS mount /usr/src and /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 redo your kernel config file. You never know what has been obsoleted 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 people forget that when you have heating problems, a single bad build means more than 5 or 6 good ones. There were so many signal 11's in the past that they wrote a FAQ on it. It is at http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#SIGNAL11 and is a good place to bookmark. Much less trouble than finding it when you need it :). I have /usr/src and /usr/obj in their own 1.5 GB partitions on their own HDs. Each HD has its own ATA-100 controller. Most of these machines have 256 MB of memory and don't swap. My gateway only has 128 MB but I have never looked at swap while I was doing a buildworld. I also have setiathome running in the background while everything is going on. The systems are always at 100% cpu. When you run out of swap, the system used to just panic. I don't think that has changed. I started out with small /, /var, and /tmp. My later versions have / with 250 MB and /var and /tmp each have 1.5 GB. The large /var lets me log everything from my cvsups (ports, docs, src), builds, and installs. Part of the cvsup update process converts the cvsup.log into an html file that lets my web browser link directly into the cvs-repository. When I have used up 1/2 of /var, I clean out the old 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 -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212071350.26164.kstewart>