From owner-freebsd-stable Thu Apr 4 13: 0: 0 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rutger.owt.com (rutger.owt.com [204.118.6.16]) by hub.freebsd.org (Postfix) with ESMTP id 4773337B41A for ; Thu, 4 Apr 2002 12:59:50 -0800 (PST) Received: from owt.com (owt-207-41-94-232.owt.com [207.41.94.232]) by rutger.owt.com (8.9.3/8.9.3) with ESMTP id MAA08325; Thu, 4 Apr 2002 12:59:18 -0800 Message-ID: <3CACBEA6.2030401@owt.com> Date: Thu, 04 Apr 2002 12:59:18 -0800 From: Kent Stewart User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us, es-mx MIME-Version: 1.0 To: Alex Edelman Cc: "Jason C. Wells" , freebsd-stable@FreeBSD.ORG Subject: Re: (hardware?) trouble with make buildworld on 4.5 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alex Edelman wrote: > Thanks for the feedback so far. I can add more data: I have already tried > swapping out the RAM with some from a different box, and it didn't seem to > make a difference. I also tried swapping out the hard drive. So if it is > hardware, I think the only things left are motherboard and CPU. Do any of > the kernel gurus on this list think it is a problem that my CPU is coming > up as "unknown" at bootup time? Original dmesg snippets below. Could it > explain the compile errors during make buildworld? > > Jason, your theory about my supping at an inopportune moment is > interesting. I have actually supped at least 10 times over the last week, > back before I suspected hardware troubles. Each time I got a compile > error in a different point of make buildworld. What are the odds that I > am unlucky and each time have supped at a wrong moment? My friend who > upgraded to 4.5-STABLE a few nights ago didn't have these problems, and he > was using the same supserver (cvsup7.freebsd.org.) Cvsup keeps track of what it has downloaded. If you had memory with a sticky bit or some other download problem, you would have a /usr/src that was corrupted. Blow the directories that do not work away and recvsup them. Memory usually produces something like a signal 11 error. Kent > > Still looking for answers. Thanks again, everybody. > > alex > > -- > Alex Edelman > aedelman@undef.com > > On Wed, 3 Apr 2002, Jason C. Wells wrote: > > >>On Tue, 2 Apr 2002, Alex Edelman wrote: >> >> >>>My current theory on the failure places blame on the CPU; I think, it is >>>either busted (I broke it) or it is not supported by FreeBSD. The >>>hardware is a Shuttle SV24 (those cute mini-systems everybody raves about) >>>and the CPU is a Via C3 866 (Ezra core or later.) I have a friend who has >>>the same system and a slightly older/slower Via C3 (Samuel core). He >>>upgraded to 4.5-STABLE last night without any problems. >>> > [snip] > >>>Here is the relevant snippet from his dmesg output: >>> >>>CPU: VIA C3 Samuel 2 (751.71-MHz 686-class CPU) >>> Origin = "CentaurHauls" Id = 0x671 Stepping = 1 >>> Features=0x803035 >>> >>>...Here is mine, note the unrecognized CPU: >>> >>>CPU: IDT Unknown (864.47-MHz 686-class CPU) >>> Origin = "CentaurHauls" Id = 0x678 Stepping = 8 >>> Features=0x803035 >>> > >>Deleting /usr/src is not useful. Cvsup will correct a not up to date >>source tree. Deleting /usr/obj is accomplishes by a 'make clean' as part >>of a normal 'make buildworld'. >> >>'make world' includes the make targets of 'make buildworld' and 'make >>installworld'. >> >>Let's look. >> >>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c >>-o >>lib_refresh.o >>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c: In >>function `wnoutrefresh': >>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:73: >>syntax error before character 0323 >> >>Syntax errors here. ^^^ >> >>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: >>`limit_x' undeclared (first use in this function) >>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: >>(Each undeclared identifier is reported only once >>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: >>for each function it appears in.) >>*** Error code 1 >> >>>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: `limit_x' undeclared (first use in this function) >>>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: (Each undeclared identifier is reported only once >>>/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: for each function it appears in.) >>>*** Error code 1 >>> >>>Stop in /usr/src/lib/libncurses. >>>*** Error code 1 >>> >>And also... >> >> >>>cc -O -pipe -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c /usr/src/lib/msun/src/k_standard.c -o k_standard.o >>>/usr/src/lib/msun/src/k_standard.c: In function `__kernel_standard': >>>/usr/src/lib/msun/src/k_standard.c:322: syntax error before character 0240 >>>*** Error code 1 >>> >>>Stop in /usr/src/lib/msun. >>>*** Error code 1 >>> >>This says "syntax error" too. ^^^ >> >>I don't know why you are getting syntax errors. My guess is you supped at >>an inopportune moment. I would sup again and 'make buildworld'. >> >>Like I said, I don't know about VIA chips and how well they are supported. >>One commonly sees errors like 'kernel panic, signal 11' when there is a >>faulty hardware problem. >> >>If you have a custom kernel, make sure it has support for the 686 class >>CPU. This is shown in your dmesg output. >> >>My answers is based on an empirical guess. I think a new sup might >>work. It has almost always worked for me when I get a syntax error of >>some sort. >> >>Also, when your build fails on a certain file in a certain directory, you >>can change to that directory and often do a 'make clean' 'make' in that >>specific directory. If I get a buildworld failure, I will re-sup and do >>the above to see if my problem cleared up before I spend all that time >>waiting for 'make world' to work its way into the problematic directory. >> >>Also, if I can't figure it out, my post to -stable would have a subject >>like "make world dies in ./libexec/telnetd". This way if a commiter just >>MFCed a change to telnetd, she can spot your error message quickly and >>investigate. >> >>These are just a couple tips to round out your self proclaimed lack of >>experience. HTH! >> >>Jason C. Wells >> >> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" 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-stable" in the body of the message