Date: Thu, 4 Apr 2002 09:42:07 -0800 (PST) From: Alex Edelman <aedelman@undef.com> To: "Jason C. Wells" <jcwells@highperformance.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: (hardware?) trouble with make buildworld on 4.5 Message-ID: <Pine.BSF.4.21.0204040930440.46966-100000@maguro.undef.com> In-Reply-To: <Pine.BSF.4.21.0204031743140.3076-100000@server2.highperformance.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) 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<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> > > > 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.0204040930440.46966-100000>