Re: (hardware?) trouble with make buildworld on 4.5

2002-04-03 Thread Jason C. Wells

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
> 
> ...Here is mine, note the unrecognized CPU:
> 
> CPU: IDT Unknown (864.47-MHz 686-class CPU)
>   Origin = "CentaurHauls"  Id = 0x678  Stepping = 8
>   Features=0x803035
> 
> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message



(hardware?) trouble with make buildworld on 4.5

2002-04-02 Thread Alex Edelman


Hi there,

I've been running FreeBSD (mostly 4.2) on multiple systems for over a year
and I absolutely love it.  Recently I installed 4.5 (from the retail CD
set) on a new machine and I'm having difficulty upgrading to stable.  My
make buildworld dies in seemingly random places.

The hardware was newly assembled by me.  I suspect that I did something
wrong with the hardware; I mean, what are the odds that RELENG_4 is busted
only for me?  However I lack the skills to trace the root cause of the
problem given the following compile failures.  Education would be greatly
appreciated.

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.

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

In the sys source code, I didn't see the Ezra core mentioned in identcpu.c
in the switch statement for CenterHauls CPUs.  Should that concern me?  
Could it be that I broke the motherboard instead?

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.

alex

--
Alex Edelman
[EMAIL PROTECTED]

---

cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_flash.c -o lib_flash.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_freeall.c -o 
lib_freeall.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_getch.c -o lib_getch.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_getstr.c -o lib_getstr.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/lib_has_cap.c -o 
lib_has_cap.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_hline.c -o lib_hline.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_immedok.c -o 
lib_immedok.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_inchstr.c -o 
lib_inchstr.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_initscr.c -o 
lib_initscr.o
cc -O -pipe  -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c 
/usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_insc