Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Apr 2002 12:59:18 -0800
From:      Kent Stewart <kstewart@owt.com>
To:        Alex Edelman <aedelman@undef.com>
Cc:        "Jason C. Wells" <jcwells@highperformance.net>, freebsd-stable@FreeBSD.ORG
Subject:   Re: (hardware?) trouble with make buildworld on 4.5
Message-ID:  <3CACBEA6.2030401@owt.com>
References:  <Pine.BSF.4.21.0204040930440.46966-100000@maguro.undef.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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<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
> 
> .
> 
> 


-- 
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CACBEA6.2030401>