Date: Wed, 3 Apr 2002 18:06:18 -0800 (PST) From: "Jason C. Wells" <jcwells@highperformance.net> To: Alex Edelman <aedelman@undef.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: (hardware?) trouble with make buildworld on 4.5 Message-ID: <Pine.BSF.4.21.0204031743140.3076-100000@server2.highperformance.net> In-Reply-To: <Pine.BSF.4.21.0204021930310.39905-100000@maguro.undef.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. I am not sure about VIA chips. > 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<FPU,DE,TSC,MSR,MTRR,PGE,MMX> > > ...Here is mine, note the unrecognized CPU: > > CPU: IDT Unknown (864.47-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x678 Stepping = 8 > Features=0x803035<FPU,DE,TSC,MSR,MTRR,PGE,MMX> > > Here are the last 50 lines of two separate make buildworld attempts. The few lines leading up to the 'Stop' line usually tell the needed information. > Here are the last 50 lines of two separate make buildworld attempts. > Both of which were done last night, after deleting all of /usr/src and > /usr/obj, and grabbing fresh from cvsup7.freebsd.org. Thanks in > advance for any guidance you can provide. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0204031743140.3076-100000>