Re: [PATCH] cross-arch bootstrapping is broken by GCC 3.1
On Wed, May 15, 2002 at 09:31:11AM +0300, Ruslan Ermilov wrote: I insist we should officially support upgrading from X.any to X+1.0-R, minimally. You need to either get concensis from arch@ or core@ then. This actually doesn't affect only cross-arch case, the subject is wrong. It affects any arch with HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG e.g. alpha. Forget about 4.x for a moment and imagine you have a pre-atoll(3) 5.0-CURRENT alpha (atoll(3) was committed on 2001/11/28). If this is true, then I agree we have a problem. I'll look into it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is current 'safe' to play in again [post GCC changes/stability]
Fwiw, with tonight's -current I am seeing cc -O -pipe -march=pentiumpro -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DTERM_EMU -I/disk0/usr/src/sys/boot/i386/libi386/../../common -I/disk0/usr/src/sys/boot/i386/libi386/../btx/lib -I/disk0/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica -I/disk0/usr/src/sys/boot/i386/libi386/../../.. -I. -I/disk0/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -c /disk0/usr/src/sys/boot/i386/libi386/bioscd.c -o bioscd.o /disk0/usr/src/sys/boot/i386/libi386/bioscd.c: In function `bc_strategy': /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: `DEV_BSIZE' undeclared (first use in this function) /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: (Each undeclared identifier is reported only once /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: for each function it appears in.) *** Error code 1 Stop in /disk0/usr/src/sys/boot/i386/libi386. *** Error code 1 I think changing '#include machine/param.h' to '#include sys/param.h' should be enough. DEV_BSIZE moved to sys/param.h, but it looks like it wasn't make world tested. :-( John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make includes
On Tue, May 14, 2002 at 12:18:14PM -0700, David O'Brien wrote: On Tue, May 14, 2002 at 04:10:51PM +0300, Ruslan Ermilov wrote: Why change in the first place? What was wrong with 'make includes'? Why break POLA? They were broken. See commit log for share/mk/bsd.incs.mk,v 1.1 for a full story. I fail to see how they were broken from the rev 1.1 bsd.incs.mk log. Please read it more carefully. (Hint: not all includes have been installed). It looks like you just hyjacked the `includes' target. Why could you not have used `incbuild' and `incinstall'? Then includes is something like includes: incbuild incinstall Actually, from what I've read, I plan on renaming these targets to buildincludes and installincludes, and restoring the `includes' to mean build + install. I will do the same for all-man, maninstall (buildmanpages, installmanpages, manpages = build + install), etc. all would mean build* (build everything), and install = install* (similarly install everything). This would bring us the consistency in standard targets names, so that one doesn't need to remember that to all-man is build manpages, and includes - to build includes, and files (when we have bsd.files.mk) to build files. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38359/pgp0.pgp Description: PGP signature
Re: make includes
On Tue, May 14, 2002 at 06:43:01AM +, Hiten Pandya wrote: --- Ruslan Ermilov [EMAIL PROTECTED] wrote: People might want to use it like that: make world mv /usr/include /usr/include.old Sorry to butt in; but wouldn't it be more good if this step was done by the build scripts itself? (refering to: mv /usr/include /usr/include.old) make incsinstall Nope. Some of us have custom stuff in /usr/include, and we can't force everyone to fix it by moving it under /usr/local/include. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38360/pgp0.pgp Description: PGP signature
Re: make includes
On Tue, 14 May 2002, David O'Brien wrote: On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote: I really do not like this change, please return things such that the long-ingraned cd /usr/src ; make includes. I planned to fix this by changing make includes to print Unwarranted chumminess with implementation. What is your perfered way to get the results of (cd /usr/src ; make includes) ? I prefer not to do this. There are simpler methods to get broken headers, starting with rm -rf :). I prefer everyone to use (documented) user-level targets like world and install for installing includes, since it would be difficult to make the includes target safe for general use. I don't know what it really useful for. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] cross-arch bootstrapping is broken by GCC 3.1
On Tue, May 14, 2002 at 11:40:48PM -0700, David O'Brien wrote: On Wed, May 15, 2002 at 09:31:11AM +0300, Ruslan Ermilov wrote: I insist we should officially support upgrading from X.any to X+1.0-R, minimally. You need to either get concensis from arch@ or core@ then. I first plan to making this true for X=4, then bringing the issue on arch@ (as I think it is more appropriate in this context than core@.) This actually doesn't affect only cross-arch case, the subject is wrong. It affects any arch with HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG e.g. alpha. Forget about 4.x for a moment and imagine you have a pre-atoll(3) 5.0-CURRENT alpha (atoll(3) was committed on 2001/11/28). If this is true, then I agree we have a problem. I'll look into it. OK, just as an aside, I've been able to produce an Alpha 5.0-CURRENT release on my SMP 4.5-STABLE i386 box with this and the other (well, you know, the MD_EXEC_PREFIX thing) patch yesterday, plus some already committed fixes for release/Makefile. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38362/pgp0.pgp Description: PGP signature
Re: make includes
On Wed, May 15, 2002 at 05:05:02PM +1000, Bruce Evans wrote: I prefer not to do this. There are simpler methods to get broken headers, starting with rm -rf :). I prefer everyone to use (documented) user-level targets like world and install for installing includes, since it would be difficult to make the includes target safe for general use. I don't know what it really useful for. `make includes' has been *invaluable* to time many times. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make includes
On Wed, May 15, 2002 at 09:59:19AM +0300, Ruslan Ermilov wrote: Actually, from what I've read, I plan on renaming these targets to buildincludes and installincludes, and restoring the `includes' to mean build + install. Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make includes
On Wed, May 15, 2002 at 05:05:02PM +1000, Bruce Evans wrote:
On Tue, 14 May 2002, David O'Brien wrote:
On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote:
I really do not like this change, please return things such that the
long-ingraned cd /usr/src ; make includes.
I planned to fix this by changing make includes to print
Unwarranted chumminess with implementation.
What is your perfered way to get the results of
(cd /usr/src ; make includes) ?
I prefer not to do this. There are simpler methods to get broken
headers, starting with rm -rf :). I prefer everyone to use (documented)
user-level targets like world and install for installing includes,
since it would be difficult to make the includes target safe for general
use. I don't know what it really useful for.
It's now more useful (incsinstall) than before, for developers. Imagine
you've modified the include file foo.h and want to try if bar compiles
with it. As incsinstall now works on per-makefile level, you can just
install this particular include (or group of related includes), and then
just cd to bar's directory, and try to make it. It is also useful as a
standard target so we don't forget to install some includes (which might
be needed to build libraries), like we did before.
(Of course, if the header is local, one might use -I${.CURDIR}, as many
bsd.lib.mk makefiles currently do. We can now drop these or similar
lines (see libbz2/Makefile for example), but I think they are still
useful in at least developer mode.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg38365/pgp0.pgp
Description: PGP signature
Re: make includes
Hi, On Tue, May 14, 2002 at 06:05:27PM +0300, Ruslan Ermilov wrote: On Wed, May 15, 2002 at 12:18:04AM +1000, Bruce Evans wrote: That's rather hackish, and doesn't handle garbage other than includes. I usually find stale files by comparing my world with a world installed in a nonstandard DESTDIR. A mergemaster-like utility could automate this. Yes, I do this the same way actually. :-) For once I'd have to disagree with Bruce about the right way to do this. The right way is to have a packaging list, and to be able to pkg_upgrade from /usr/src, which would do an orderly removal of all of the files installed by an old world... Then we can start work on spliting the world into seperate packages. We could even automate the generation of the packaging list because we know everything in /usr/src is installed by an install target somewhere in bsd.*.mk. To answer the obvious questions: No, this is not possible at the moment. Yes, it is fairly easy to achieve. Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Verba Volant
The following email address, [EMAIL PROTECTED] has been removed from the Verba Volant Newsletter list. If you did not cancel your email address or you wish to continue receiving Verba Volant, please send an e-mail to [EMAIL PROTECTED] Thank you and best regards, Verba Volant To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
preemption across processors
Currently, a new runnable thread cannot preempt the thread on any
processor other than the thread that called mi_switch(). For
instance, we do something like the following in _mtx_unlock_sleep():
--- v --- _mtx_unlock_sleep() --- v ---
setrunqueue(th_waken_up);
if (curthread-preemptable th_waken_up-priority curthread-priority) {
setrunqueue(curthread);
mi_switch();
}
--- ^ --- _mtx_unlock_sleep() --- ^ ---
If the priority of curthread is higher than th_waken_up, we cannot run
it immediately even if there is another processor running a thread
with a priority lower than th_waken_up. th_waken_up should preempt
that processor, or we would end up with a priority inversion.
Maybe we have to dispatch a runnable thread to the processor running
a thread with the lowest priority. Solaris seems to take the
following steps to do that:
1. If a new thread has slept for longer than 3/100 seconds (this
should be tunable), linearly search the processor running a thread
with the lowest priority. Otherwise, choose the processor that ran
the new thread most recently.
2. Make an inter-processor interrupt to the processor chosen in 1.
3. The chosen processor puts its current thread back to the dispatch
queue and performs a context switch to run the new thread.
Above is only a rough sketch. We have to watch out for a race of
inter-processor interrupts and a processor entering a critical section.
If no one is working on preemption across processors, I would like to
see if I can do that.
Thanks.
--
Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: preemption across processors
On 15-May-2002 Seigo Tanimura wrote:
Currently, a new runnable thread cannot preempt the thread on any
processor other than the thread that called mi_switch(). For
instance, we do something like the following in _mtx_unlock_sleep():
--- v --- _mtx_unlock_sleep() --- v ---
setrunqueue(th_waken_up);
if (curthread-preemptable th_waken_up-priority curthread-priority) {
setrunqueue(curthread);
mi_switch();
}
--- ^ --- _mtx_unlock_sleep() --- ^ ---
If the priority of curthread is higher than th_waken_up, we cannot run
it immediately even if there is another processor running a thread
with a priority lower than th_waken_up. th_waken_up should preempt
that processor, or we would end up with a priority inversion.
Maybe we have to dispatch a runnable thread to the processor running
a thread with the lowest priority. Solaris seems to take the
following steps to do that:
1. If a new thread has slept for longer than 3/100 seconds (this
should be tunable), linearly search the processor running a thread
with the lowest priority. Otherwise, choose the processor that ran
the new thread most recently.
2. Make an inter-processor interrupt to the processor chosen in 1.
3. The chosen processor puts its current thread back to the dispatch
queue and performs a context switch to run the new thread.
Above is only a rough sketch. We have to watch out for a race of
inter-processor interrupts and a processor entering a critical section.
If no one is working on preemption across processors, I would like to
see if I can do that.
I actually think that the little gain this brings isn't worth the extra
effort involved personally. We don't have to get things perfect, getting
them reasonably close is good enough for some things. However, that is
only my opinion. If the code to support this is relatively clean and
simple with low-impact in the normal case then I would support it. However,
there are several tricky race conditions here so I'm not sure it can be
done simply.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
loader failure
Trying to boot with a newly-built loader (make world earlier today from fresh sources) results in: FreeBSD/alpha SRM disk boot, Revision 1.2 ([EMAIL PROTECTED], Wed May 15 08:01:43 CEST 2002) Memory: 262144 k Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x283780+0x63670 / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0xfc32e740... halted CPU 0 halt code = 2 kernel stack not valid halt PC = 2 boot failure no matter which kernel I try to boot. Booting my new kernel with the old loader (from the DP1 dist) works fine until it tries to start init(8): spec_getpages: preposterous offset 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c exec /stand/sysinstall: error 5 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall panic: no init panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 Booting DP1's GENERIC with the old loader and the new userland works fine. Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts as funny stuff) guess type=wildThe loader problem is possibly a compiler issue (since DP1 was built with gcc 2.95 while my world was built with 3.1). The init problem is probably a UFS2 f*up; the code has obviously not been tested on a 64-bit architecture (the UFS2 stuff broke the kernel build)./guess DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make includes
On 15-May-2002 Bruce Evans wrote: On Tue, 14 May 2002, David O'Brien wrote: On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote: I really do not like this change, please return things such that the long-ingraned cd /usr/src ; make includes. I planned to fix this by changing make includes to print Unwarranted chumminess with implementation. What is your perfered way to get the results of (cd /usr/src ; make includes) ? I prefer not to do this. There are simpler methods to get broken headers, starting with rm -rf :). I prefer everyone to use (documented) user-level targets like world and install for installing includes, since it would be difficult to make the includes target safe for general use. I don't know what it really useful for. It's useful for a new arch that doesn't have make world yet. When I would update world on my sparc before gcc was bmake'd it went something like this: sudo make includes sudo make libraries make obj make depend make sudo make install To build and install a new world. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: loader failure
On 15-May-2002 Dag-Erling Smorgrav wrote: Trying to boot with a newly-built loader (make world earlier today from fresh sources) results in: FreeBSD/alpha SRM disk boot, Revision 1.2 ([EMAIL PROTECTED], Wed May 15 08:01:43 CEST 2002) Memory: 262144 k Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x283780+0x63670 / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0xfc32e740... halted CPU 0 halt code = 2 kernel stack not valid halt PC = 2 boot failure no matter which kernel I try to boot. Booting my new kernel with the old loader (from the DP1 dist) works fine until it tries to start init(8): spec_getpages: preposterous offset 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c exec /stand/sysinstall: error 5 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall panic: no init panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 Booting DP1's GENERIC with the old loader and the new userland works fine. Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts as funny stuff) guess type=wildThe loader problem is possibly a compiler issue (since DP1 was built with gcc 2.95 while my world was built with 3.1). The init problem is probably a UFS2 f*up; the code has obviously not been tested on a 64-bit architecture (the UFS2 stuff broke the kernel build)./guess The kernel overflowed it's stack. In SRM, you can try to debug this by using 'e sp' to get the stack pointer then get a stack dump and save a copy of it in a log or something, reboot the machine, then use gdb's list command on the kernel.debug to figure out the source:line for all the kernel-text addresses in the stack dump to figure out the backtrace. From that you can figure out where the recursion is happening and fix it. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Signal 12 in buildworld from -stable to -current
Hi list, I get a persistent Signal 12 when upgrading from -stable to -current : stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.1 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 includes; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.1 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks incsinstall === share/info === include creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh;echo $COPYRIGHT osreldate.h; echo #ifdef _KERNEL osreldate.h;echo '#error /usr/include/osreldate.h cannot be used in the kernel, use sys/param.h' osreldate.h; echo #else osreldate.h;echo \#'undef __FreeBSD_version' osreldate.h;echo \#'define __FreeBSD_version' $RELDATE osreldate.h; echo #endif osreldate.h *** Signal 12 Stop in /usr/src/include. *** Error code 1 This is in the first step of /usr/src/UPDATING : To upgrade from 4.x-stable to current - make buildworld Removing /usr/obj doesn't help. I searched for this problem in the archives but found nothing. I'm sure I overlook something 'obvious' ;-) Any hints/pointers appreciated. Hans Lambermont -- http://lambermont.webhop.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Dag-Erling Smorgrav writes: Trying to boot with a newly-built loader (make world earlier today from fresh sources) results in: .. boot failure no matter which kernel I try to boot. Booting my new kernel with the old loader (from the DP1 dist) works fine until it tries to start init(8): .. guess type=wildThe loader problem is possibly a compiler issue (since DP1 was built with gcc 2.95 while my world was built with 3.1). The init problem is probably a UFS2 f*up; the code has obviously not been tested on a 64-bit architecture (the UFS2 stuff broke the kernel build)./guess My 2 cents - the kernel world (including loader) were fine as of Friday (both built with gcc3, modulo the atomic fixes for vm_object.c that jhb / alc / jeff came up with on Saturday). Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Signal 12 in buildworld from -stable to -current
On Wed, May 15, 2002 at 03:32:45PM +0200, Hans Lambermont wrote: Hi list, I get a persistent Signal 12 when upgrading from -stable to -current : Signal 12 indicates a non-existent system call. This means that your running world is incompatible with your kernel. Fix this first. (You should see the same error if you try to upgrade to -stable.) stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.1 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 includes; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.1 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks incsinstall === share/info === include creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh;echo $COPYRIGHT osreldate.h; echo #ifdef _KERNEL osreldate.h;echo '#error /usr/include/osreldate.h cannot be used in the kernel, use sys/param.h' osreldate.h; echo #else osreldate.h;echo \#'undef __FreeBSD_version' osreldate.h;echo \#'define __FreeBSD_version' $RELDATE osreldate.h; echo #endif osreldate.h *** Signal 12 Stop in /usr/src/include. *** Error code 1 This is in the first step of /usr/src/UPDATING : To upgrade from 4.x-stable to current - make buildworld Removing /usr/obj doesn't help. I searched for this problem in the archives but found nothing. I'm sure I overlook something 'obvious' ;-) Any hints/pointers appreciated. Hans Lambermont -- http://lambermont.webhop.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38375/pgp0.pgp Description: PGP signature
Re: loader failure
On Wed, May 15, 2002 at 02:22:04PM +0200, Dag-Erling Smorgrav wrote: Trying to boot with a newly-built loader (make world earlier today from fresh sources) results in: FreeBSD/alpha SRM disk boot, Revision 1.2 ([EMAIL PROTECTED], Wed May 15 08:01:43 CEST 2002) Memory: 262144 k Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x283780+0x63670 / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0xfc32e740... halted CPU 0 halt code = 2 kernel stack not valid halt PC = 2 boot failure no matter which kernel I try to boot. Booting my new kernel with the old loader (from the DP1 dist) works fine until it tries to start init(8): spec_getpages: preposterous offset 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c exec /stand/sysinstall: error 5 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall panic: no init panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 Booting DP1's GENERIC with the old loader and the new userland works fine. Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts as funny stuff) I'm running 11th May -current with ev4 on NoName and since yesterday with ev56 on PC164. No problems with /boot/loader. On the PC164 I had an dup alloc ufs panic yesterday :( The filesystem was checked with fsck -y directly after updating. Debugging options in kernel were disabled. guess type=wildThe loader problem is possibly a compiler issue (since DP1 was built with gcc 2.95 while my world was built with 3.1). The init problem is probably a UFS2 f*up; the code has obviously not been tested on a 64-bit architecture (the UFS2 stuff broke the kernel build)./guess Some UFS2 preparation parts were commited after I checked out my source, IIRC also a part influencing loader. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
What do you think about doing a little more polishing and rolling a new set of patches taking this /etc/rc.conf option into account? Your kernel env dhcp variables are really good. i was thinking of adding something like this to dhcp: option FBSD.rc-conf 132.65.16.100:/c/conf/rc.conf.foo; and bootp can then tftp/nfs the file and parse it, making the result available via kenv and there is no real problem to concatenate serveral conf files - just comming up with a nice/simple syntax :-) as a proof of concept, there is no major problem to tftp this, but only from one/initial host, to make it realy flexible there is one major obstacle, the stand alone io has to be modified/augmented/complicated to have more than one socket. so, 1- is there a market for this? 2- is this a bad idea? 3- any work done already? danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make includes
On Wed, May 15, 2002 at 09:26:29AM -0700, David O'Brien wrote:
Almost correct. For the record and future ports:
It's useful for a new arch that doesn't have make world yet. When I would
update world on my sparc before gcc was bmake'd it went something like this:
sudo make hierarchy
sudo make includes
sudo make libraries
make obj make depend make
sudo make install
To build and install a new world.
With this simple patch,
%%%
--- Makefile.inc1~ Wed May 15 19:35:00 2002
+++ Makefile.inc1 Wed May 15 19:38:02 2002
@@ -330,6 +330,12 @@
.endif
WMAKE_TGTS+= _includes _libraries _depend everything
+.for __target in ${WMAKE_TGTS}
+.if defined(NO${__target})
+WMAKE_TGTS:= ${WMAKE_TGTS:N${__target}}
+.endif
+.endfor
+
buildworld: ${WMAKE_TGTS}
.ORDER: ${WMAKE_TGTS}
%%%
one can easily ``make buildworld TARGET_ARCH=foo -DNO_cross-tools''.
See the ``make -f Makefile.inc1 -V WMAKE_TGTS -DNO_cross-tools''
output for details. (Yet one simple patch might be required to
exclude gnu/usr.bin/cc/cc_tools from the list of build-tools.)
Please let me know if you want me to commit this, or something
like that.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg38380/pgp0.pgp
Description: PGP signature
Turbulence in today's -CURRENT ride: loader hangs (vs. loads)
... and then I got a panic. Hmmm More particulars: The events being described occur on my SMP build machine (the laptop is still working on building today's -CURRENT as I type). I've been tracking -CURRENT daily on this machine for some time; each day, I build the day's -CURRENT while running the most recent -CURRENT I already built (nearly always, yesterday's -CURRENT). Also, this machiine uses only a serial console; it has no monitor or keyboard. Anyway, after the build install ( mergemaster) for today, I rebooted: syncing disks... 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 done Uptime: 3h12m34s Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Wed May 15 07:33:39 PDT 2002) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x217bc8 data=0x34d74+0x7078c / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x2b67c data=0x16e4+0x6e0 / which would be fairly normal, except that the spinner stopped spinning. Around that point, I got a little suspicous, and tried again -- this time, requesting a single-user boot. Same thing. So I tried again, and managed to interrupt the system before it loaded the loader: /boot/kernel/acpi.ko text=0x2b67c data=0x16e4+0x6e0 FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: 0:ad(0,a)/boot/loader.old Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Tue May 14 06:52:45 PDT 2002) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x217bc8 data=0x34d74+0x7078c syms=[0x4+0x35470+0x4+0x408ed] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -s /boot/kernel/acpi.ko text=0x2b67c data=0x16e4+0x6e0 syms=[0x4+0x4f10+0x4+0x6728] SMAP type=01 base= len= 0009fc00 SMAP type=01 base= 0009fc00 len= 0400 SMAP type=02 base= 000f len= 0001 SMAP type=02 base= fec0 len= 0140 SMAP type=01 base= 0010 len= 1fef SMAP type=03 base= 1fff3000 len= d000 SMAP type=04 base= 1fff len= 3000 Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Wed May 15 08:47:19 PDT 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST Preloaded elf kernel /boot/kernel/kernel at 0xc046f000. Preloaded elf module /boot/kernel/acpi.ko at 0xc046f0b4. Calibrating clock(s) ... TSC clock: 876475449 Hz, i8254 clock: 1193296 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III/Pentium III Xeon/Celeron (876.40-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536805376 (524224K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00499000 - 0x1ffe7fff, 531951616 bytes (129871 pages) avail memory = 517246976 (505124K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00faf20 bios32: Entry = 0xfb390 (c00fb390) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb3c0 pnpbios: Found PnP BIOS data at 0xc00fbde0 pnpbios: Entry = f:be10 Rev = 1.0 Other BIOS signatures found: null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x8060 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=30911106) Using $PIR table, 8 entries at 0xc00fde30 npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard acpi0: power button is handled as a fixed
moused(8): char signed-ness problem with gcc 3.1
I observed gcc 2.95.4 and gcc 3.1 interpret (or maybe optimize) the
following code differently (CFLAGS=-O):
int main(void)
{
unsigned char i = 127;
printf(%d\n, ((char)(i 1)) / 2);
return 0;
}
gcc 2.95.4 says it's -1, whereas gcc 3.1 says it's 127. On FreeBSD
char should be signed, so I suspect it's a (optimization) bug of gcc
3.1 which should be fixed. Or we'll have to do a mass audit of the
whole src tree to check and fix the similar expressions.
In any case, this behavior makes moused(8) return a stupid value of
127 when you roll the mouse wheel up under ps/2-sysmouse-intellimouse
protocol. Attached is a patch that makes the whole expression look
more logical and works around the above behavior at the same time.
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
Somewhere out of a memory.. of lighted streets on quiet nights..
Index: moused.c
===
RCS file: /home/ncvs/src/usr.sbin/moused/moused.c,v
retrieving revision 1.55
diff -u -r1.55 moused.c
--- moused.c28 Apr 2002 11:59:30 - 1.55
+++ moused.c15 May 2002 17:16:40 -
@@ -1972,7 +1972,7 @@
act-dx =(char)(pBuf[1]) + (char)(pBuf[3]);
act-dy = - ((char)(pBuf[2]) + (char)(pBuf[4]));
if (rodent.level == 1) {
- act-dz = ((char)(pBuf[5] 1) + (char)(pBuf[6] 1))/2;
+ act-dz = ((char)(pBuf[5] 1) + (char)(pBuf[6] 1)) 1;
act-button |= ((~pBuf[7] MOUSE_SYS_EXTBUTTONS) 3);
}
break;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
(fwd) Re: cvs commit: ports/sysutils Makefile ports/sysutils/rclean Makefile distinfo pkg-comment pkg-descr pkg-plist
[putting anti-flame on] -- N'aimer qu'un seul est barbarie, car c'est au détriment de tous les autres. Fût-ce l'amour de Dieu. - Nietzsche, Par delà le bien et le mal ---BeginMessage--- On Wed, 15 May 2002 13:16:52 -0400 The Anarcat [EMAIL PROTECTED] wrote: Why isn't this part of base? It needs agreement of -current. Why don't you ask there ? -- Computer science is no more about computers than astronomy is about telescopes - E. Dijkstra ---End Message--- msg38383/pgp0.pgp Description: PGP signature
Re: make includes
On Wed, 15 May 2002, David O'Brien wrote: Almost correct. For the record and future ports: [jhb wrote] It's useful for a new arch that doesn't have make world yet. When I would update world on my sparc before gcc was bmake'd it went something like this: sudo make hierarchy sudo make includes sudo make libraries What John wants is really these 2 steps. Includes and libraries form a usable subsset of the world, so it would be reasonable to have an end-user target for it. Hwowever, building that target robustly would involve a lot more than the above. All the tools for building the libraries would have to be built, and that wouldn't work in this case. make obj make depend make sudo make install To build and install a new world. Several other steps are missing. Mainly make obj before make libraries. make obj is now necessary before make includes. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: (fwd) Re: cvs commit: ports/sysutils Makefile ports/sysutils/rclean Makefile distinfo pkg-comment pkg-descr pkg-plist
The Anarcat wrote: [putting anti-flame on] To invite a normal discussion you should at least provide the following information: - What `rclean' is for? - Why do you think it could be useful in base system? Your assumption that the list readers know answers to those two questions (or would care enough to dig for the answers by themselves) is incorrect and entitles you not to flamewar but to ugh, what this is all about? reaction from their part and likely to the complete lack of any discussion at all as a result. -Maxim -- N'aimer qu'un seul est barbarie, car c'est au détriment de tous les autres. Fût-ce l'amour de Dieu. - Nietzsche, Par delà le bien et le mal -- Subject: Re: cvs commit: ports/sysutils Makefile ports/sysutils/rclean Makefile distinfo pkg-comment pkg-descr pkg-plist Date: Thu, 16 May 2002 03:15:29 +0900 From: SADA Kenji [EMAIL PROTECTED] Organization: Private To: The Anarcat [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] On Wed, 15 May 2002 13:16:52 -0400 The Anarcat [EMAIL PROTECTED] wrote: Why isn't this part of base? It needs agreement of -current. Why don't you ask there ? -- Computer science is no more about computers than astronomy is about telescopes - E. Dijkstra -- Part 1.2Type: application/pgp-signature To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
Akinori MUSHA wrote:
I observed gcc 2.95.4 and gcc 3.1 interpret (or maybe optimize) the
following code differently (CFLAGS=-O):
int main(void)
{
unsigned char i = 127;
printf(%d\n, ((char)(i 1)) / 2);
return 0;
}
Cool...
gcc 2.95.4 says it's -1,
Promotion of operand to int; conversion to lvalue type after
the operation.
whereas gcc 3.1 says it's 127.
Promotion of operand to lvalue type.
On FreeBSD
char should be signed, so I suspect it's a (optimization) bug of gcc
3.1 which should be fixed. Or we'll have to do a mass audit of the
whole src tree to check and fix the similar expressions.
Technically, I think, because of the parenthesis, that GCC 2.95 is
right, and GCC 3.1 is wrong. Given that the conversion to char
is done prior to the division, it should happen first.
From the assembly, it looks like 3.1 is treating /2 as 1,
and illegally canceling out the 1 with the 1 *before* the
conversion. Or maybe it's the conversion to int that happens on
the stack value for a %d argument to printf...
Maybe one of out C standards people can define when the conversion
is defined to occur, so we can get a real ruling.
Note that:
int main(void)
{
unsigned char i = 127;
printf(%d\n, (char)((i 1) / 2));
return 0;
}
...yields 127 on gcc 2.95, so it's definitely order of conversion
being totally screwed by gcc 3.1.
Basically, it's assuming commutability where it's not present.
In any case, this behavior makes moused(8) return a stupid value of
127 when you roll the mouse wheel up under ps/2-sysmouse-intellimouse
protocol. Attached is a patch that makes the whole expression look
more logical and works around the above behavior at the same time.
[ ... ]
- act-dz = ((char)(pBuf[5] 1) + (char)(pBuf[6] 1))/2;
+ act-dz = ((char)(pBuf[5] 1) + (char)(pBuf[6] 1)) 1;
This is *soo* counter intuitive that it's evil!
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: ports/sysutils Makefile ports/sysutils/rclean Makefile distinfo pkg-comment pkg-descr pkg-plist
On Wed May 15, 2002 at 09:55:42PM +0300, Maxim Sobolev wrote: The Anarcat wrote: [putting anti-flame on] s/on/suit on/ To invite a normal discussion you should at least provide the following information: Well, I expected people to look at the port, but I'll provide more information here. - What `rclean' is for? rclean provides a command-line tool to order and clean content of rc.conf, using option order from /etc/defaults/rc.conf and printing only choices that were different by the default value in /etc/rc.conf. Output is customizable from only used values to full listing. WWW: http://www.lapo.it/rclean/ - Why do you think it could be useful in base system? Well, that part is more personal, but I think it could remove the tendency people have of complaining about the current /etc/defaults scheme. There has been a few threads about problems arising when /etc/defaults/rc.conf was getting updated. I think rclean might help solve those problems, in the same spirit mergemaster helps managing configuration file changes. Your assumption that the list readers know answers to those two questions (or would care enough to dig for the answers by themselves) is incorrect and entitles you not to flamewar but to ugh, what this is all about? reaction from their part and likely to the complete lack of any discussion at all as a result. I wonder what's best after all. ;) I must admit I was being a bit blunt by just challenging people to put this in base, somehow assuming everything should go in. In other words, the question is: Why should this go in base? rather than: Why isn't this in base? My apologies. A. -- Un éducateur dans l'âme ne prend rien au sérieux que par rapport à ses disciples -- soi-même non excepté. - Nietzsche, Par delà le bien et le mal msg38387/pgp0.pgp Description: PGP signature
First kernel build with gcc-3.1 failure
I had a -current system with the old version of gcc, and build world/kernel that contained gcc-3.1: 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon May 6 19:31:16 EDT 2002 Now for the first time with gcc-3.1 in place I have updated source (as of just minutes ago 1500EDT 5.15.02) and am trying to build world/kernel again. and during the kernel process keep running into the following... cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -W strict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/ sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I /usr/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werr or /usr/src/sys/ddb/db_command.c cc1: warnings being treated as errors /usr/src/sys/ddb/db_command.c: In function `db_fncall': /usr/src/sys/ddb/db_command.c:549: warning: unknown conversion type character `r' in format /usr/src/sys/ddb/db_command.c:549: warning: too many arguments for format *** Error code 1 Stop in /usr/local/obj/usr/src/sys/AMNESIAC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. in the kernel config I have options DDB, DDB_UNATTENDED insight? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
gcc 3.1 simply defaults to unsigned chars. 127 1 = 254; 254 / 2 = 127. My machine is too slow to test this expeditiously, but I'm trying adding #define DEFAULT_SIGNED_CHAR 1 into freebsd-native.h . Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
On Thu, May 16, 2002 at 02:42:34AM +0900, Akinori MUSHA wrote:
I observed gcc 2.95.4 and gcc 3.1 interpret (or maybe optimize) the
following code differently (CFLAGS=-O):
int main(void)
{
unsigned char i = 127;
printf(%d\n, ((char)(i 1)) / 2);
return 0;
}
I think GCC 3.1 does a logical right shift by one to
optimize the division by two instead of an arithmetic
right shift.
ciao,
-robert
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
Bill Fenner wrote: gcc 3.1 simply defaults to unsigned chars. 127 1 = 254; 254 / 2 = 127. My machine is too slow to test this expeditiously, but I'm trying adding #define DEFAULT_SIGNED_CHAR 1 into freebsd-native.h . I will bet today's lunch money that you have found it for sure. I guess we will have to go around adding signed everywhere, if it's no longer the default. Unsigned is a stupid, counter-intuitive default, and has been, ever since I first used AIX. My bet is a conspiracy by AIX folks so that Open Source software will work on AIX without them having to fix their stupid defaults. 8-) 8-). If this isn't the default, then signed is too much like const and volatile and other you can't ignore them or I will generate bad code keywords. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
Duh. Sometimes I wish I had the patience to wait for my tests to complete before sharing my guesses. I jumped to a wildly incorrect conclusion; gcc 3.1 still defaults to signed chars. Sorry for the bizarre misdirection. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
Bill Fenner wrote: Duh. Sometimes I wish I had the patience to wait for my tests to complete before sharing my guesses. I jumped to a wildly incorrect conclusion; gcc 3.1 still defaults to signed chars. Sorry for the bizarre misdirection. There goes my lunch money. 8-(. Man, your explanation was preferrable to a real bug. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
John Baldwin [EMAIL PROTECTED] writes: The kernel overflowed it's stack. In SRM, you can try to debug this by using 'e sp' to get the stack pointer then get a stack dump and save a copy of it in a log or something, reboot the machine, then use gdb's list command on the kernel.debug to figure out the source:line for all the kernel-text addresses in the stack dump to figure out the backtrace. How do I get a stack trace? I can't get the 'examine' command to actually print anything... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
don't know how to make buildincludes in buildworld from -stable to -current
Ruslan Ermilov wrote: On Wed, May 15, 2002 at 03:32:45PM +0200, Hans Lambermont wrote: I get a persistent Signal 12 when upgrading from -stable to -current : Signal 12 indicates a non-existent system call. This means that your running world is incompatible with your kernel. Fix this first. To be sure I retried from yesterdays -stable, 'make buildword' now says after a while : cd /usr/src; make buildincludes; make installincludes make: don't know how to make buildincludes. Stop (I dont see the buildincludes target anywhere in /usr/src or in /usr/share/mk) (You should see the same error if you try to upgrade to -stable.) I think not. this system was upgraded yesterday to -stable (from a previous -stable) without problems. As usual any thoughts are welcome. Hans Lambermont -- http://lambermont.webhop.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
I observed gcc 2.95.4 and gcc 3.1 interpret (or maybe optimize) the
following code differently (CFLAGS=-O):
int main(void)
{
unsigned char i = 127;
printf(%d\n, ((char)(i 1)) / 2);
return 0;
}
gcc 2.95.4 says it's -1, whereas gcc 3.1 says it's 127. On FreeBSD
char should be signed, so I suspect it's a (optimization) bug of gcc
3.1 which should be fixed. Or we'll have to do a mass audit of the
whole src tree to check and fix the similar expressions.
Let's examine the what the right answer should be:
First - in the expression (i 1) - the unsigned char `i' will
be promoted to a signed int through the correct integral promotion
rules, then left-shifted 1 bit. The result of that is an int.
So - this becomes:
((char)(254)) / 2 ;
The expression:
(char)(254)
is then also promoted to int when it participates
in the division operation. So, the value 254 is
converted into a (signed) char, and then converted
to an int. Converting 254 to a signed character
should result in an integer value of -2.
Then, -2 / 2 becomes -1.
If characters were unsigned by default, you do
get the value 127...
So - yes - it seems gcc 3.1 does have a problem...
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Turbulence in today's -CURRENT ride: loader hangs (vs. loads)
Date: Wed, 15 May 2002 09:58:50 -0700 (PDT)
From: David Wolfskill [EMAIL PROTECTED]
[Following up after getting today's -CURRENT built on my laptop; I have
some additional information. This is hand-transcribed, since I don't
have a serial console on my laptop. I was able ot get the build machine
rebooted eventually by using loader.old to boot kernel.old. dhw]
Anyway, after the build install ( mergemaster) for today, I rebooted:
OK; different (apparent) symptom:
BTX loader 1.00 BTX version is 1.01
Console: internal video/keyboard
BIOS drive A: is disk0
BIOS drive C: is disk1
BIOS 638kB/129984kB available memory
FreeBSD/1386 bootstrap loader, Revision 1.1
([EMAIL PROTECTED], Wed May 15 10:52:22 PDT 2002)
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x304528 data=0x65534+0x70bac
\
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
/boot/kernel/acpi.ko text=0x2b67c data=0x16e4+0x6e0
\
int=0005 err= efl=00010092 eip=0011ad4d
eax=0001 ebx=8800 ecx=00034e20 edx=a040
esi= edi=00047d24 ebp=00034e20 esp=0009e674
cs=0008 ds=0010 es=0010fs=0010 gs=0010 ss=0010
cs:eip=64 62 5f 66 6f 72 63 65-5f 77 86 69 74 65 73 70
61 63 65 00 61 64 76 5f-74 65 73 74 5f 65 87 74
ss:esp=a8 46 09 00 90 46 09 00-74 0e 00 00 24 7d 04 00
cf a7 00 00 cf a7 00 00-d5 a7 00 00 c0 46 09 00
BTX halted
A rendering of the cs:eip and ss:esp lines as ASCII characters ('.'
taking the place of non-printable characters and those with the high-
order bit set) is:
db_force_w.itesp
ace.adv_test_e.t
.F...F..t...$}..
.F..
Now, in the case of this machine (hte laptop), the following (possibly)
salient differences (with respect to the build machine) exist that I
think of presently:
* It is a uni-processor, vs. the SMP build machine.
* I didn't bulid -CURRENT on the laptop yesterday, so this -CURRENT
was built using the -CURRENT I had built on Monday.
And here's my recent CVSup history:
freebeast(4.6-PRERELEASE)[1] tail /var/log/cvsup-history.log
CVSup begin from cvsup14.freebsd.org at Sat May 11 03:47:02 PDT 2002
CVSup ended from cvsup14.freebsd.org at Sat May 11 03:54:26 PDT 2002
CVSup begin from cvsup14.freebsd.org at Sun May 12 03:47:02 PDT 2002
CVSup ended from cvsup14.freebsd.org at Sun May 12 03:53:37 PDT 2002
CVSup begin from cvsup14.freebsd.org at Mon May 13 03:47:02 PDT 2002
CVSup ended from cvsup14.freebsd.org at Mon May 13 03:55:28 PDT 2002
CVSup begin from cvsup14.freebsd.org at Tue May 14 03:47:03 PDT 2002
CVSup ended from cvsup14.freebsd.org at Tue May 14 03:54:28 PDT 2002
CVSup begin from cvsup14.freebsd.org at Wed May 15 04:09:35 PDT 2002
CVSup ended from cvsup14.freebsd.org at Wed May 15 04:37:28 PDT 2002
freebeast(4.6-PRERELEASE)[2]
Still could use a clue
Thanks,
david (links to my resume at http://www.catwhisker.org/~david)
--
David H. Wolfskill [EMAIL PROTECTED]
Trying to support Microsoft products makes about as much sense
as painting a house with watercolors.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
Terry Lambert [EMAIL PROTECTED] wrote: Bill Fenner wrote: gcc 3.1 simply defaults to unsigned chars. 127 1 = 254; 254 / 2 = 127. My machine is too slow to test this expeditiously, but I'm trying adding #define DEFAULT_SIGNED_CHAR 1 into freebsd-native.h . I will bet today's lunch money that you have found it for sure. I guess we will have to go around adding signed everywhere, if it's no longer the default. Unsigned is a stupid, counter-intuitive default, and has been, ever since I first used AIX. My bet is a conspiracy by AIX folks so that Open Source software will work on AIX without them having to fix their stupid defaults. 8-) 8-). Well - it's not counter-intuitive on many machines... For example, on the IBM mainframe - there is an instruction to load a character into a register - but not one that loads *and* sign-extends. So, you can get much better code if characters are unsigned by default. So in our C/C++ compilers for the mainframe, the default is unsigned as well. I wonder if the AIX people were looking for mainframe compatibility in this decision, or was it motivated by the PowerPC instruction set? Does anyone know what the Mac default is (since they are PowerPC based as well?) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
no matter which kernel I try to boot. Booting my new kernel with the old loader (from the DP1 dist) works fine until it tries to start init(8): spec_getpages: preposterous offset 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c exec /stand/sysinstall: error 5 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall panic: no init panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 Booting DP1's GENERIC with the old loader and the new userland works fine. Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts as funny stuff) This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? I'm not sure, I'm just rebuilding now. Remember, /boot/loader.old is left around... handy in this situation (I'd forgotten 'till jhb pointed it out). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
On 15-May-2002 Dag-Erling Smorgrav wrote: John Baldwin [EMAIL PROTECTED] writes: The kernel overflowed it's stack. In SRM, you can try to debug this by using 'e sp' to get the stack pointer then get a stack dump and save a copy of it in a log or something, reboot the machine, then use gdb's list command on the kernel.debug to figure out the source:line for all the kernel-text addresses in the stack dump to figure out the backtrace. How do I get a stack trace? I can't get the 'examine' command to actually print anything... It depends on which machine actually. :-/ First do 'e sp' to get the stack pointer. Then you want to do something like this: e -n 100 value of sp without any leading 0x if that doesn't work then try: e -n 100 vmem:value of sp w/o leading 0x This should basically do a raw memory dump. However, see if phk's daddr_t reversal fixes it first. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? I'm not sure, I'm just rebuilding now. Remember, /boot/loader.old is left around... handy in this situation (I'd forgotten 'till jhb pointed it out). Yes, the daddr_t backout has fixed the loader and the filesystem problems. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: First kernel build with gcc-3.1 failure
On Wed, May 15, 2002 at 03:15:39PM -0400, Jeff Ito wrote: I had a -current system with the old version of gcc, and build world/kernel that contained gcc-3.1: ... cc1: warnings being treated as errors /usr/src/sys/ddb/db_command.c: In function `db_fncall': /usr/src/sys/ddb/db_command.c:549: warning: unknown conversion type character `r' in format /usr/src/sys/ddb/db_command.c:549: warning: too many arguments for format *** Error code 1 THIS IS AN FAQ. insight? 1. You don't pay attention to the output of config(8). Go run it and read it this time. The verbiage is there for your benefit. 2. You don't read this mailing list ([EMAIL PROTECTED]). Go read your archives or your favorite web mailing list archiver. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make includes
On Wed, May 15, 2002 at 07:43:22PM +0300, Ruslan Ermilov wrote: one can easily ``make buildworld TARGET_ARCH=foo -DNO_cross-tools''. I am now doing many cross buildworlds. Is there a target (used with -DNOCLEAN) to use to save time and resume a build at stage 4? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: First kernel build with gcc-3.1 failure
On Wed, May 15, 2002 at 03:15:47PM -0700, David O'Brien wrote: On Wed, May 15, 2002 at 03:15:39PM -0400, Jeff Ito wrote: I had a -current system with the old version of gcc, and build world/kernel that contained gcc-3.1: ... cc1: warnings being treated as errors /usr/src/sys/ddb/db_command.c: In function `db_fncall': /usr/src/sys/ddb/db_command.c:549: warning: unknown conversion type character `r' in format /usr/src/sys/ddb/db_command.c:549: warning: too many arguments for format *** Error code 1 THIS IS AN FAQ. insight? 1. You don't pay attention to the output of config(8). Go run it and read it this time. The verbiage is there for your benefit. 2. You don't read this mailing list ([EMAIL PROTECTED]). Go read your archives or your favorite web mailing list archiver. Opps, left out 3. more /usr/src/UPDATING ... 20020225: Warnings are now errors in the kernel. Unless you are a developer, you should add -DNO_WERROR to your make line. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is anyone else having trouble with dump(8) on -current?
On Tue, 2002-05-14 at 05:34, Alexander Leidinger wrote: On 7 Mai, Benjamin Lewis wrote: Now, on to the problem. I use amanda for backups, and since mid-April I've been seeing items like the following in the backup report: [edited for brevity] | DUMP: slave couldn't reopen disk: Interrupted system call | DUMP: The ENTIRE dump is aborted. sendbackup: error [/sbin/dump returned 3] \ Try the attached patch. I also have a similar patch for restore. I don't like the patch, I think I should use SA_RESTART with sigaction(), so think about this patch as a proof of concept (if it solves your problem). For those that are interested and those that come across this in the archives, I would like to thank Alexander Leidinger very much. The patch he sent me seems to have solved the problem illustrated above. I ran several test dumps immediately after rebuilding /sbin/dump, and it was very promising in that no errors were reported. Prior to the patch, I was consistently able to generate an error within 3 attempts. Since then, Amanda has run and there were no reported issues with the run. Last night was the first entirely successful run in a long time. I pulled all of the dumps back from tape, restored them to a secondary location, and used cmp to compare them to the originals. The only differences found were the expected logfiles and other ephemeral data. In short, the patch seems to have completely solved my problem My thanks to M. Leidinger, -Ben To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX halted
Date: Wed, 15 May 2002 17:14:10 -0700 (PDT) From: David Xu [EMAIL PROTECTED] Yesterday 'cvs update' and 'make world' causes BTX halted: Yes; use /boot/loader.old to boot /boot/kernel.old. Once you've done that, update src/sys/sys/types.h to rev. 1.62 rebuild. (Procedure worked for me, b oth for my laptop for my build machine.) Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] Trying to support Microsoft products makes about as much sense as painting a house with watercolors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX halted
On Wednesday 15 May 2002 04:14 pm, you wrote: Yesterday 'cvs update' and 'make world' causes BTX halted: int=000e err=0002 efl=00010002 eip=c02cdeec eax=0001 ebx=003b9c00 ecx=01ff edx=10fc esi=003b9001 edi=003c1000 ebp= esp=c03bcd99 cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip=10 44 17 fe 14 80 58 80-57 e0 51 20 91 20 12 24 13 fe 10 20 28 a8 25 26-42 22 84 e0 00 00 c1 67 ss:esp=27 12 c0 00 10 3c 00 00-90 3b 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX Halted Been fixed...cvsup and rebuild. Beech -- --- Beech Rintoul - SysAdmin - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Sinbad Network Communications \ / - NO HTML/RTF in e-mail | 3101 Penland Parkway #K-38 X - NO Word docs in e-mail | Anchorage, AK 99508-1957 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
libstdc++-v3
First: It's great to see gcc3 in -CURRENT, a round of cheers for obrien@! :) So, please, don't misread this question as some kind of hurry, hurry!, but: Is libstdc++-v3 already on anyone's schedule, and if so, when can we expect it to hit the tree? -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
So - yes - it seems gcc 3.1 does have a problem...
Indeed - easily determined by breaking down the expression.
So, who's gonna report it to gcc-bugs? knu?...
int
main()
{
unsigned char i = 127;
char j;
printf(%d\n, ((char)(i 1)));
j = ((char)(i 1)) / 2;
printf(%d\n, j);
j = ((char)(i 1));
printf(%d\n, j / 2);
return 0;
}
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
Thomas David Rivers wrote: Well - it's not counter-intuitive on many machines... For example, on the IBM mainframe - there is an instruction to load a character into a register - but not one that loads *and* sign-extends. So, you can get much better code if characters are unsigned by default. Sounds like time to get out the wire wrap tools... and fix the hardware, not the software. So in our C/C++ compilers for the mainframe, the default is unsigned as well. I wonder if the AIX people were looking for mainframe compatibility in this decision, or was it motivated by the PowerPC instruction set? Does anyone know what the Mac default is (since they are PowerPC based as well?) RS/6000's didn't used to use PPC processors at all; so it's probably intentional software compatability. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Skipping certain buildworld stages (was: Re: make includes)
On Wed, May 15, 2002 at 03:18:15PM -0700, David O'Brien wrote:
On Wed, May 15, 2002 at 07:43:22PM +0300, Ruslan Ermilov wrote:
one can easily ``make buildworld TARGET_ARCH=foo -DNO_cross-tools''.
I am now doing many cross buildworlds. Is there a target (used with
-DNOCLEAN) to use to save time and resume a build at stage 4?
With the patch I posted yesterday,
%%%
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.277
diff -u -r1.277 Makefile.inc1
--- Makefile.inc1 15 May 2002 16:29:44 - 1.277
+++ Makefile.inc1 16 May 2002 06:06:09 -
@@ -330,6 +330,12 @@
.endif
WMAKE_TGTS+= _includes _libraries _depend everything
+.for __target in ${WMAKE_TGTS}
+.if defined(NO${__target})
+WMAKE_TGTS:= ${WMAKE_TGTS:N${__target}}
+.endif
+.endfor
+
buildworld: ${WMAKE_TGTS}
.ORDER: ${WMAKE_TGTS}
%%%
it's possible to achieve this with:
: make \
: -DNO_worldtmp -DNO_bootstrap-tools -DNO_cleanobj -DNO_obj \
: -DNO_build-tools -DNO_cross-tools \
: buildworld TARGET_ARCH=foo
Which in essence is equivalent to this sh(1) script:
: cd /whatever/usr/src
: for target in _includes _libraries _depend everything; do
: make -m `pwd`/share/mk -f Makefile.inc1 \
: ${target} TARGET_ARCH=foo
: done
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg38416/pgp0.pgp
Description: PGP signature
