unsubscribe
unsubscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
On Sun, 12 Nov 2000, Marcel Moolenaar wrote: Makoto MATSUSHITA wrote: % make -j 2 modules cd ../../modules env MAKEOBJDIRPREFIX=/usr/src/sys/compile/GENERIC/modules KMODDIR=/boot/kernel make obj all === 3dfx === 3dfx Warning: Object directory not changed from original /usr/src/sys/modules/3dfx (... ok, break it ...) The problem is in the fact that the Makefile (the one in /sys/conf) contains something like: ${MAKE} obj all and ${MAKE} obj depend The net effect is that these targets are built in parallel, which obviously isn't right. The following solves the problem (i386 only): That's just one of the problems :-). "make obj all" is usually an error, but in Makefile.${MACHINE} it should be just a bad example, since the `obj' and `all' targets should be built sequentially and then the object directories will exist by the time make(1) recurses into them for the `all' target. This doesn't work right for the -j case. (In the above example, the targets are built concurrently and race each other. This is bad when the `all' target wins the race. The `obj' target runs faster, so it usually wins the race except in the first directory (3dfx)). More .ORDER statements in *.mk are required. Index: Makefile.i386 === RCS file: /home/ncvs/src/sys/conf/Makefile.i386,v retrieving revision 1.212 diff -u -r1.212 Makefile.i386 --- Makefile.i386 2000/10/29 09:47:50 1.212 +++ Makefile.i386 2000/11/13 07:49:00 @@ -271,11 +271,13 @@ modules: @mkdir -p ${.OBJDIR}/modules - cd $S/modules env ${MKMODULESENV} ${MAKE} obj all + cd $S/modules env ${MKMODULESENV} ${MAKE} obj \ + env ${MKMODULESENV} ${MAKE} all modules-depend: @mkdir -p ${.OBJDIR}/modules - cd $S/modules env ${MKMODULESENV} ${MAKE} obj depend + cd $S/modules env ${MKMODULESENV} ${MAKE} obj $$ \ + env ${MKMODULESENV} ${MAKE} depend modules-clean: cd $S/modules env ${MKMODULESENV} ${MAKE} clean `' should never be used in shell commands in makefiles, although it may be only a bad example. This is because multiple commands are executed in the same shell in the -j case, and `' gives non-simple commands which may defeat the shell's -e setting. E.g., the command: cd /; set -e; cd /nonesuch false; rm -rf * removes everything under "/", not everything under /nonesuch, despite checking that the cd to /nonesuch worked. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
bde (In the above example, the targets are built concurrently and race bde each other. This is bad when the `all' target wins the race. The bde `obj' target runs faster, so it usually wins the race except in the bde first directory (3dfx)). More .ORDER statements in *.mk are required. Thank you for giving us a details of this problem. But can we fix this problem with .ORDER statements? Putting ".ORDER: obj all" or alike to Makefile doesn't fix to me (maybe I misunderstand the usage of .ORDER statement)... bde `' should never be used in shell commands in makefiles, although it bde may be only a bad example. This is because multiple commands are bde executed in the same shell in the -j case, and `' gives non-simple bde commands which may defeat the shell's -e setting. What should we do if we want to check the existence of a directory and kick one (not two or more) command after chdir to that directory? Much Makefiles in our FreeBSD repository employ "cd ${dir} command" to do this... Should we say if [ -d ${dir} ]; then \ (cd ${dir}; command) \ else false fi or exist() directive of make(1) ? *** Anyway, attached below is current sample patch to fix this problem. "make obj" and "make all" are separated to two individual commands (redundant 'cd' clause, but it should work). -- - Makoto `MAR' MATSUSHITA Index: Makefile === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/release/Makefile,v retrieving revision 1.585 diff -c -r1.585 Makefile *** Makefile2000/11/12 11:04:11 1.585 --- Makefile2000/11/13 05:37:12 *** *** 831,837 @rm -f ${RD}/kernels/*.ko @cd ${.CURDIR}/../sys/${MACHINE}/conf config ${KERNEL} @cd ${.CURDIR}/../sys/compile/${KERNEL} \ ! make kernel-depend \ make ${KERNEL_FLAGS} modules \ make modules-reinstall DESTDIR=${RD}/kernels \ --- 831,837 @rm -f ${RD}/kernels/*.ko @cd ${.CURDIR}/../sys/${MACHINE}/conf config ${KERNEL} @cd ${.CURDIR}/../sys/compile/${KERNEL} \ ! make modules-depend \ make ${KERNEL_FLAGS} modules \ make modules-reinstall DESTDIR=${RD}/kernels \ Index: Makefile.alpha === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/sys/conf/Makefile.alpha,v retrieving revision 1.79 diff -c -r1.79 Makefile.alpha *** Makefile.alpha 2000/10/29 09:47:50 1.79 --- Makefile.alpha 2000/11/13 10:09:34 *** *** 310,320 modules: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj all modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj depend modules-clean: cd $S/modules env ${MKMODULESENV} ${MAKE} clean --- 310,322 modules: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj ! cd $S/modules env ${MKMODULESENV} ${MAKE} all modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj ! cd $S/modules env ${MKMODULESENV} ${MAKE} depend modules-clean: cd $S/modules env ${MKMODULESENV} ${MAKE} clean Index: Makefile.i386 === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/sys/conf/Makefile.i386,v retrieving revision 1.212 diff -c -r1.212 Makefile.i386 *** Makefile.i386 2000/10/29 09:47:50 1.212 --- Makefile.i386 2000/11/13 10:10:03 *** *** 271,281 modules: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj all modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj depend modules-clean: cd $S/modules env ${MKMODULESENV} ${MAKE} clean --- 271,283 modules: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj ! cd $S/modules env ${MKMODULESENV} ${MAKE} all modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj ! cd $S/modules env ${MKMODULESENV} ${MAKE} depend modules-clean: cd $S/modules env ${MKMODULESENV} ${MAKE} clean Index: Makefile.ia64 === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/sys/conf/Makefile.ia64,v retrieving revision 1.4 diff -c -r1.4 Makefile.ia64 *** Makefile.ia64 2000/10/29 09:47:50 1.4 --- Makefile.ia64 2000/11/13 10:10:41 *** *** 275,285 modules: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj all modules-depend:
Re: make modules kicks the first module directory twice
On Mon, 13 Nov 2000, Makoto MATSUSHITA wrote: bde (In the above example, the targets are built concurrently and race bde each other. This is bad when the `all' target wins the race. The bde `obj' target runs faster, so it usually wins the race except in the bde first directory (3dfx)). More .ORDER statements in *.mk are required. Thank you for giving us a details of this problem. But can we fix this problem with .ORDER statements? Putting ".ORDER: obj all" or alike to Makefile doesn't fix to me (maybe I misunderstand the usage of .ORDER statement)... It didn't work for me either :-). I put it in bsd.obj.mk near the `obj' target, with the idea that this would cover all uses of the obj target. The problem seems to be that we both put it in the wrong place. I think it needs to be in bsd.subdir.mk for this case and in bsd.obj.mk for most cases. bde `' should never be used in shell commands in makefiles, although it bde may be only a bad example. This is because multiple commands are bde executed in the same shell in the -j case, and `' gives non-simple bde commands which may defeat the shell's -e setting. What should we do if we want to check the existence of a directory and kick one (not two or more) command after chdir to that directory? Much Makefiles in our FreeBSD repository employ "cd ${dir} command" to do this... Should we say if [ -d ${dir} ]; then \ (cd ${dir}; command) \ else false fi or exist() directive of make(1) ? Just use a semicolon instead of "" ("cd foo; command"). This gives multiple single commands, and make(1) execs sh(1) with -e, so the shell exits if any of the simple commands fails. ("simple" here is a technical term. See sh.1.) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
world breakage?
During make buildworld: === usr.sbin/lpr/lpd cc -O -pipe -I/usr/src/usr.sbin/lpr/lpd/../common_source -Wall -Wnested-externs -Wmissing-prototypes -Wno-unused -Wredundant-decls -Wstrict-prototypes -I/usr/ obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/lpr/lpd/lpd.c /usr/src/usr.sbin/lpr/lpd/lpd.c: In function `main': /usr/src/usr.sbin/lpr/lpd/lpd.c:129: warning: `finet' might be used uninitialize d in this function /usr/src/usr.sbin/lpr/lpd/lpd.c:320: warning: `domain' might be used uninitializ ed in this function /usr/src/usr.sbin/lpr/lpd/lpd.c:320: warning: `s' might be used uninitialized in this function cc -O -pipe -I/usr/src/usr.sbin/lpr/lpd/../common_source -Wall -Wnested-externs -Wmissing-prototypes -Wno-unused -Wredundant-decls -Wstrict-prototypes -I/usr/ obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/lpr/lpd/printjob.c /usr/src/usr.sbin/lpr/lpd/printjob.c: In function `printit': /usr/src/usr.sbin/lpr/lpd/printjob.c:512: `didignorehdr' undeclared (first use i n this function) /usr/src/usr.sbin/lpr/lpd/printjob.c:512: (Each undeclared identifier is reporte d only once /usr/src/usr.sbin/lpr/lpd/printjob.c:512: for each function it appears in.) *** Error code 1 Stop in /usr/src/usr.sbin/lpr/lpd. *** Error code 1 Stop in /usr/src/usr.sbin/lpr. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I think it wasn't reported yet? No time to debug it, I am at work ;-) Bye, Andrea -- Loose bits sink chips. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage?
On Mon, 13 Nov 2000 17:24:41 +0100, Andrea Campi wrote: I think it wasn't reported yet? No time to debug it, I am at work ;-) Reported and fixed. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: savecore broken because kern.bootfile is set wrong
Though the alpha code (alpha/libalpha/bootinfo.c) also fill in a lot of stuff in bi, it has no reference at all to "kernelname". Did it ever work? :-) Hmm. Maybe not. I'd convinced myself that the loader is currently just passing "kernel" either as an environmental variable or in bootinfo, but you're right about the loader. Time to fix... -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
On Sun, Nov 12, 2000 at 11:58:39PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Makoto MATSUSHITA writes: : It does not fix this problem. However, if we separate the execution of : "make obj" and "make all", we can avoid (again, not *fix*) the problem. : Maybe this change is reasonable; there is few meaning doing "make : kernel-depend" in "doMODULES" target. I think that make has no business doing an implicit make obj for the all target. Someone has to run `make obj' for the modules tree. How are you doing it locally? I have been running with patches in my tree that doesn't do the obj target if .depend exists. can you post them for review. Of course, you have to be more careful about running make depend in that case Now *that* sounds scarry to me. We'll have people all over the lists who forget to and would now get rather bitten. From the sounds of it, your patch doesn't create as robust a world, but maybe it does. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
On Mon, Nov 13, 2000 at 07:51:11PM +0900, Makoto MATSUSHITA wrote: ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj all --- 310,322 ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj ! cd $S/modules env ${MKMODULESENV} ${MAKE} all I can certainly commit this type of fix. The combined make invocation was an optimization someone recommended. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
Bruce Evans wrote: Index: Makefile.i386 === RCS file: /home/ncvs/src/sys/conf/Makefile.i386,v retrieving revision 1.212 diff -u -r1.212 Makefile.i386 --- Makefile.i386 2000/10/29 09:47:50 1.212 +++ Makefile.i386 2000/11/13 07:49:00 @@ -271,11 +271,13 @@ modules: @mkdir -p ${.OBJDIR}/modules - cd $S/modules env ${MKMODULESENV} ${MAKE} obj all + cd $S/modules env ${MKMODULESENV} ${MAKE} obj \ + env ${MKMODULESENV} ${MAKE} all modules-depend: @mkdir -p ${.OBJDIR}/modules - cd $S/modules env ${MKMODULESENV} ${MAKE} obj depend + cd $S/modules env ${MKMODULESENV} ${MAKE} obj $$ \ + env ${MKMODULESENV} ${MAKE} depend modules-clean: cd $S/modules env ${MKMODULESENV} ${MAKE} clean `' should never be used in shell commands in makefiles, although it may be only a bad example. Mostly that, yes. The first try for a "fix" was: cd $S/modules env ${MKMODULESENV} ${MAKE} obj cd $S/modules env ${MKMODULESENV} ${MAKE} all But since $S expands to "../.." and -j runs a single shell, the first cd will succeed, but not the second. I simply copied the "construction" in the second and posted fix. I'll commit a fix with just semi-colons today for all architectures if someone hasn't done that already by that time. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
David O'Brien wrote: On Mon, Nov 13, 2000 at 07:51:11PM +0900, Makoto MATSUSHITA wrote: ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj all --- 310,322 ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj ! cd $S/modules env ${MKMODULESENV} ${MAKE} all I can certainly commit this type of fix. The combined make invocation was an optimization someone recommended. No you can't. $S expands to "../.." which only works for the first cd in the -jX case. The second cd will fail. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
Marcel Moolenaar wrote: David O'Brien wrote: On Mon, Nov 13, 2000 at 07:51:11PM +0900, Makoto MATSUSHITA wrote: ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj all --- 310,322 ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj ! cd $S/modules env ${MKMODULESENV} ${MAKE} all I can certainly commit this type of fix. The combined make invocation was an optimization someone recommended. No you can't. Oops. A smiley was intended here. I'm not the authoritive kind of guy :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
On Mon, Nov 13, 2000 at 01:19:38PM -0500, Marcel Moolenaar wrote: I'll commit a fix with just semi-colons today for all architectures if someone hasn't done that already by that time. Can you post a patch first. There seems to be some subtleties here that might make a review useful. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current has hosed the i8254 timecounter...
It seems that something recently toasted the quasi-magic i8254 timecounter code to the point of unusability. On my laptop I run a ntpdate every minute, and the result looks like this: Nov 13 23:37:00 [...] step time server 212.242.40.181 offset -2.862805 sec Nov 13 23:38:00 [...] step time server 212.242.40.181 offset -6.109507 sec Nov 13 23:39:00 [...] step time server 212.242.40.181 offset -5.299533 sec Nov 13 23:40:01 [...] step time server 212.242.40.181 offset -11.220085 sec Nov 13 23:41:00 [...] step time server 212.242.40.181 offset -6.449271 sec Nov 13 23:42:00 [...] step time server 212.242.40.181 offset -5.190362 sec Nov 13 23:43:00 [...] step time server 212.242.40.181 offset -5.438783 sec Nov 13 23:45:00 [...] step time server 212.242.40.181 offset -4.535331 sec Nov 13 23:46:00 [...] step time server 212.242.40.181 offset -6.052685 sec Nov 13 23:47:01 [...] step time server 212.242.40.181 offset -3.289484 sec Nov 13 23:48:00 [...] step time server 212.242.40.181 offset -2.659785 sec Nov 13 23:49:00 [...] step time server 212.242.40.181 offset -3.276033 sec Nov 13 23:50:00 [...] step time server 212.242.40.181 offset -0.919082 sec Nov 13 23:51:00 [...] step time server 212.242.40.181 offset -4.163177 sec Nov 13 23:52:00 [...] step time server 212.242.40.181 offset -7.449300 sec This is on a laptop with APM enabled btw. You should be able to force the use of the i8254 timecounter by sysctl -w kern.timecounter.hardware=i8254 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
really strange problem - extracting X turns my system off, literally
Hi, I'm bewildered and looking for clues ... I'm running -current, cvsup'd and rebuild world as of yesterday: FreeBSD stage.bsdhome.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Nov 12 18:30:15 EST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I went to install X from Ports and during extraction, my system just turned itself off! Not reboot, mind you, it powered down. I use a serial console so I would be able to tell if any messages printed out just before that final event, but there's nothing. Nothing in /var/log/messages either. Here are the last few messages of the X install via ports: [root@stage]:/XFree86- make install === Extracting for XFree86-3.3.6_4 Checksum OK for xc/X336src-1.tgz. Checksum OK for xc/X336src-2.tgz. Checksum OK for xc/fix-01-r128. Checksum OK for xc/fix-04-s3trio3d2x. Checksum OK for xc/fix-05-s3trio3d. Checksum OK for xc/fix-06-s3trio3d2x. Checksum OK for xc/fix-07-s3trio64v2gx+netfinity. Checksum OK for xc/fix-08-s3savage_ix+mx. [extract for a minute or two, then powerdown] So, I rebuild my world, reboot and try again ... it powered down at the exact same spot! Any ideas? Note that this machine has successfully been completing buildworld/kernel installkernel/world's for the last several months. Thanks, -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
On Mon, Nov 13, 2000 at 12:23:08PM -0700, Warner Losh wrote: : I think that make has no business doing an implicit make obj for the : all target. : Someone has to run `make obj' for the modules tree. How are you doing it : locally? Right now we do it twice. Once in make dpeend and again in make all. My patch removes it from make all. ..snip.. I'm not sure what you're criteria for a robust world is here. If the directory doesn't exist, it will warn the user. It doesn't warn the user, it errors out (possibly a suttle distinction I'm making). Also in the past a `make depend' for the kernel was not required. Just highly suggested. Are we really prepared to make it a requirement now? To tell the truth, IMHO the modules should just build in the current directory (and thus could share some .o's with the kernel build). -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
In message [EMAIL PROTECTED] "David O'Brien" writes: : It doesn't warn the user, it errors out (possibly a suttle distinction : I'm making). Also in the past a `make depend' for the kernel was not : required. Just highly suggested. Are we really prepared to make it a : requirement now? I am, but others might not be. : To tell the truth, IMHO the modules should just build in the current : directory (and thus could share some .o's with the kernel build). Me too. I'm tired of building things twice :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
David O'Brien wrote: On Mon, Nov 13, 2000 at 01:19:38PM -0500, Marcel Moolenaar wrote: I'll commit a fix with just semi-colons today for all architectures if someone hasn't done that already by that time. Can you post a patch first. There seems to be some subtleties here that might make a review useful. Sure. BTW: I'm also looking at Warner's patch. Maybe that's the better fix for it, but I have to dig into the Makefiles a bit more to get a better picture... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make modules kicks the first module directory twice
marcel No you can't. $S expands to "../.." which only works for the marcel first cd in the -jX case. The second cd will fail. Ouch... give me one more chance to submit a patch. Here's summary: * src/release/Makefile should use 'module-depend' while checking dependancy of modules (not kernel-depend). * For parallel build: "command command" - "command; command" * For parallel build: "make obj depend" - "make obj; make depend" * Avoid to do run "obj" target again in "modules" target (comes from an email of [EMAIL PROTECTED]) -- - Makoto `MAR' MATSUSHITA Index: Makefile === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/release/Makefile,v retrieving revision 1.585 diff -c -r1.585 Makefile *** Makefile2000/11/12 11:04:11 1.585 --- Makefile2000/11/13 05:37:12 *** *** 831,837 @rm -f ${RD}/kernels/*.ko @cd ${.CURDIR}/../sys/${MACHINE}/conf config ${KERNEL} @cd ${.CURDIR}/../sys/compile/${KERNEL} \ ! make kernel-depend \ make ${KERNEL_FLAGS} modules \ make modules-reinstall DESTDIR=${RD}/kernels \ --- 831,837 @rm -f ${RD}/kernels/*.ko @cd ${.CURDIR}/../sys/${MACHINE}/conf config ${KERNEL} @cd ${.CURDIR}/../sys/compile/${KERNEL} \ ! make modules-depend \ make ${KERNEL_FLAGS} modules \ make modules-reinstall DESTDIR=${RD}/kernels \ Index: Makefile.alpha === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/sys/conf/Makefile.alpha,v retrieving revision 1.79 diff -c -r1.79 Makefile.alpha *** Makefile.alpha 2000/10/29 09:47:50 1.79 --- Makefile.alpha 2000/11/14 00:42:39 *** *** 252,258 echo ${CFILES} | tr -s ' ' '\12' | sed 's/\.c/.o/' | \ sort -u | comm -23 - dontlink | \ sed 's,../.*/\(.*.o\),rm -f \1;ln -s ../GENERIC/\1 \1,' makelinks ! sh makelinks rm -f dontlink kernel-tags: @[ -f .depend ] || { echo "you must make depend first"; exit 1; } --- 252,258 echo ${CFILES} | tr -s ' ' '\12' | sed 's/\.c/.o/' | \ sort -u | comm -23 - dontlink | \ sed 's,../.*/\(.*.o\),rm -f \1;ln -s ../GENERIC/\1 \1,' makelinks ! sh makelinks; rm -f dontlink kernel-tags: @[ -f .depend ] || { echo "you must make depend first"; exit 1; } *** *** 309,338 MKMODULESENV= MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR} modules: ! @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj all modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj depend modules-clean: ! cd $S/modules env ${MKMODULESENV} ${MAKE} clean modules-cleandepend: ! cd $S/modules env ${MKMODULESENV} ${MAKE} cleandepend modules-cleandir: ! cd $S/modules env ${MKMODULESENV} ${MAKE} cleandir modules-tags: ! cd $S/modules env ${MKMODULESENV} ${MAKE} tags modules-install modules-install.debug: ! cd $S/modules env ${MKMODULESENV} ${MAKE} install modules-reinstall modules-reinstall.debug: ! cd $S/modules env ${MKMODULESENV} ${MAKE} install config.o: ${NORMAL_C} --- 309,342 MKMODULESENV= MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR} modules: ! @if [ ! -d ${.OBJDIR}/modules ]; then \ ! echo You must run make depend before building modules; \ ! exit 1; \ ! fi ! cd $S/modules; env ${MKMODULESENV} ${MAKE} all modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules; env ${MKMODULESENV} ${MAKE} obj ! env ${MKMODULESENV} ${MAKE} depend modules-clean: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} clean modules-cleandepend: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} cleandepend modules-cleandir: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} cleandir modules-tags: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} tags modules-install modules-install.debug: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} install modules-reinstall modules-reinstall.debug: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} install config.o: ${NORMAL_C} Index: Makefile.i386 === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/sys/conf/Makefile.i386,v retrieving revision 1.212 diff -c -r1.212 Makefile.i386 *** Makefile.i386 2000/10/29 09:47:50 1.212 --- Makefile.i386 2000/11/14 00:43:16 *** *** 212,218 echo ${CFILES} | tr -s ' ' '\12' | sed 's/\.c/.o/' | \ sort -u | comm -23 - dontlink | \ sed 's,../.*/\(.*.o\),rm
Re: make modules kicks the first module directory twice
[-stable removed from the cc list] Makoto MATSUSHITA wrote: marcel No you can't. $S expands to "../.." which only works for the marcel first cd in the -jX case. The second cd will fail. Ouch... Sorry :-) give me one more chance to submit a patch. Here's summary: You're not going to like this: modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules; env ${MKMODULESENV} ${MAKE} obj ! env ${MKMODULESENV} ${MAKE} depend For the non parallel case this doesn't work, because the "${MAKE} depend" is not run from the right directory (ie "$S/modules") because the second make doesn't get started from the same shell. Example: gauss% more ~/mf all: cd ../marcel; pwd pwd *** Non-parallel case gauss% cd /xtra/ncvs gauss% make -f ~/mf cd ../marcel; pwd /xtra/marcel pwd /xtra/ncvs *** Parallel case gauss% make -f ~/mf -j2 cd ../marcel; pwd /xtra/marcel pwd /xtra/marcel ...other than that... :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
getty bug when run by hand
Hi, I've been working on serial ports/consoles the last few days and have run into what I consider a bug in getty (-current).. When the following command is run as root: /usr/obj/usr/src/libexec/getty/getty std.38400 ttyd1 the call to login_tty() fails in the opentty() function: else { login_tty(i); return 1; } However, the return code is not checked. File descripters 0, 1, and 2 are not modified to point at ttyd1, and the getty then proceeds to run on the current terminal session. At a minimum, I'd like to commit the following patch. It would have helped avoid some frustrating moments... === RCS file: /home/ncvs/src/libexec/getty/main.c,v retrieving revision 1.31 diff -u -r1.31 main.c --- main.c 2000/10/10 01:53:00 1.31 +++ main.c 2000/11/14 02:25:31 @@ -444,7 +444,10 @@ return 0; } else { - login_tty(i); + if (login_tty(i) 0) { + syslog(LOG_ERR, "login_tty %s: %m", ttyn); + return 0; + } return 1; } } This of course then leads to the question of why the TIOCSCTTY ioctl call failes. From the above change: Nov 13 17:25:47 mail getty[1236]: login_tty /dev/ttyd1: Operation not permitted It's worth noting that /dev/ttyd1 has been successfully openned on fd 3 this point. The serial ports work fine with tip or kermit and from dmesg are: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A comments welcome. -John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio patch to use mutexes
I am seeing lots of silo overflows in -current SMP. #uname -a FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #2: \ Mon Nov 13 19:31:49 PST 2000 \ root@celebris:/usr/src/sys/compile/CELEBRIS-SMP i386 I this is not related to the recent patch for conversion to mutex. I tried both ways. I don't know when the problem started, I have been using another machine to run ppp, and just switched back to this one. I am sure it started late this year. I have messages going back to Apr 7 2000. There were no silo overflows early this year, around Jan and Feb. Same ISP, same setup. I saw one silo overflow in July. But, I don't know how much I ran ppp during that time. During the past 10 minutes, I saw 43. I have attached dmesg. I am running ppp via tun to my ISP at 56k. I see throughput at near that, when ftp'ing large files. The serial port is set to 115200. tomdean === part of ppp.conf = set device /dev/cuaa0 set speed 115200 set parity none set timeout 0 disable lqr deny lqr ... === dmesg = Copyright (c) 1992-2000 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: Mon Nov 13 19:31:49 PST 2000 root@celebris:/usr/src/sys/compile/CELEBRIS-SMP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (128.01-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping = 5 Features=0x3bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC real memory = 100663296 (98304K bytes) avail memory = 94744576 (92524K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc0313000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc031309c. Intel Pentium detected, installing workaround for F00F bug npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 ncr0: ncr 53c810 fast10 scsi port 0xec00-0xecff mem 0xfedfbf00-0xfedfbfff irq 11 at device 1.0 on pci0 isab0: Intel 82378IB PCI to ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 pci0: Matrox MGA Millennium 2064W graphics accelerator at 6.0 irq 9 de0: Digital 21041 Ethernet port 0xe880-0xe8ff mem 0xfedfbe80-0xfedfbeff irq 10 at device 8.0 on pci0 de0: DEC DE450-CA 21041 [10Mb/s] pass 1.1 de0: address 00:00:f8:02:76:db atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: IBM Enhanced (101/102-key) KC can't assign resources unknown: Microsoft PS/2 Mouse can't assign resources unknown: 16550 compatible COM device can't assign resources unknown: 16550 compatible COM device can't assign resources unknown: LPT printer port can't assign resources unknown: Floppy Controller can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Waiting 10 seconds for SCSI devices to settle Mounting root from ufs:/dev/da1s1a da0 at ncr0 bus 0 target 0 lun 0 da0: QUANTUM FIREBALL1080S 1Q09 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 8) da0: 1042MB (2134305 512 byte sectors: 255H 63S/T 132C) cd0 at ncr0 bus 0 target 5 lun 0 cd0: TOSHIBA CD-ROM XM-5401TA 3605 Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 8) cd0: cd present [329507 x 2048 byte records] da2 at ncr0 bus 0 target 2 lun 0 da2: QUANTUM FIREBALL ST3.2S 0F0C Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da2: 3090MB (6328861 512 byte sectors: 255H 63S/T 393C) da1 at ncr0 bus 0 target 1 lun 0 da1: IBM DNES-309170 SAH0 Fixed Direct Access SCSI-3 device da1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da1: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) SMP: AP CPU #1 Launched! de0: enabling BNC port sio0: 1 more silo overflow (total 1) sio0: 2 more silo overflows (total 3) sio0: 1 more silo overflow (total 4) sio0: 2 more silo overflows (total 6) sio0: 1 more silo overflow (total 7) sio0: 2 more silo
RQ review: [was: Re: make modules kicks the first module directory twice]
Makoto MATSUSHITA wrote: Ouch... give me one more chance to submit a patch. Here's summary: I see no reason to not commit Makoto-san's patches with the fix he sent me for the modules-depend target. The fix is (modulo indentation): modules-depend: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} obj; \ ! env ${MKMODULESENV} ${MAKE} depend It contains everything mentioned so far, which is: * src/release/Makefile should use 'module-depend' while checking dependancy of modules (not kernel-depend). * For parallel build: "command command" - "command; command" * For parallel build: "make obj depend" - "make obj; make depend" * Avoid to do run "obj" target again in "modules" target (comes from an email of [EMAIL PROTECTED]) Any objections? (patches follow for your convenience) Index: Makefile === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/release/Makefile,v retrieving revision 1.585 diff -c -r1.585 Makefile *** Makefile2000/11/12 11:04:11 1.585 --- Makefile2000/11/13 05:37:12 *** *** 831,837 @rm -f ${RD}/kernels/*.ko @cd ${.CURDIR}/../sys/${MACHINE}/conf config ${KERNEL} @cd ${.CURDIR}/../sys/compile/${KERNEL} \ ! make kernel-depend \ make ${KERNEL_FLAGS} modules \ make modules-reinstall DESTDIR=${RD}/kernels \ --- 831,837 @rm -f ${RD}/kernels/*.ko @cd ${.CURDIR}/../sys/${MACHINE}/conf config ${KERNEL} @cd ${.CURDIR}/../sys/compile/${KERNEL} \ ! make modules-depend \ make ${KERNEL_FLAGS} modules \ make modules-reinstall DESTDIR=${RD}/kernels \ Index: Makefile.alpha === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/sys/conf/Makefile.alpha,v retrieving revision 1.79 diff -c -r1.79 Makefile.alpha *** Makefile.alpha 2000/10/29 09:47:50 1.79 --- Makefile.alpha 2000/11/14 00:42:39 *** *** 252,258 echo ${CFILES} | tr -s ' ' '\12' | sed 's/\.c/.o/' | \ sort -u | comm -23 - dontlink | \ sed 's,../.*/\(.*.o\),rm -f \1;ln -s ../GENERIC/\1 \1,' makelinks ! sh makelinks rm -f dontlink kernel-tags: @[ -f .depend ] || { echo "you must make depend first"; exit 1; } --- 252,258 echo ${CFILES} | tr -s ' ' '\12' | sed 's/\.c/.o/' | \ sort -u | comm -23 - dontlink | \ sed 's,../.*/\(.*.o\),rm -f \1;ln -s ../GENERIC/\1 \1,' makelinks ! sh makelinks; rm -f dontlink kernel-tags: @[ -f .depend ] || { echo "you must make depend first"; exit 1; } *** *** 309,338 MKMODULESENV= MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR} modules: ! @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj all modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules env ${MKMODULESENV} ${MAKE} obj depend modules-clean: ! cd $S/modules env ${MKMODULESENV} ${MAKE} clean modules-cleandepend: ! cd $S/modules env ${MKMODULESENV} ${MAKE} cleandepend modules-cleandir: ! cd $S/modules env ${MKMODULESENV} ${MAKE} cleandir modules-tags: ! cd $S/modules env ${MKMODULESENV} ${MAKE} tags modules-install modules-install.debug: ! cd $S/modules env ${MKMODULESENV} ${MAKE} install modules-reinstall modules-reinstall.debug: ! cd $S/modules env ${MKMODULESENV} ${MAKE} install config.o: ${NORMAL_C} --- 309,342 MKMODULESENV= MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR} modules: ! @if [ ! -d ${.OBJDIR}/modules ]; then \ ! echo You must run make depend before building modules; \ ! exit 1; \ ! fi ! cd $S/modules; env ${MKMODULESENV} ${MAKE} all modules-depend: @mkdir -p ${.OBJDIR}/modules ! cd $S/modules; env ${MKMODULESENV} ${MAKE} obj ! env ${MKMODULESENV} ${MAKE} depend modules-clean: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} clean modules-cleandepend: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} cleandepend modules-cleandir: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} cleandir modules-tags: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} tags modules-install modules-install.debug: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} install modules-reinstall modules-reinstall.debug: ! cd $S/modules; env ${MKMODULESENV} ${MAKE} install config.o: ${NORMAL_C} Index: Makefile.i386 === RCS file: /lab/FreeBSD/FreeBSD.cvs/src/sys/conf/Makefile.i386,v
Re: make modules kicks the first module directory twice
In message [EMAIL PROTECTED] Marcel Moolenaar writes: : BTW: I'm also looking at Warner's patch. Maybe that's the better fix for : it, but I have to dig into the Makefiles a bit more to get a better : picture... The implications are that make obj isn't done unless you've run make depend first. If a new directory is added and a make depend isn't run, then the modules won't get built into the obj tree, but instead will be built into $S/modules. This isn't too bad because unless you have multiple kernels that are skewed in version that you'll be doing make installs from from the same tree (which isn't supported, officially, now, but does accidentally usually work). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio patch to use mutexes
On Mon, 13 Nov 2000, Thomas D. Dean wrote: I am seeing lots of silo overflows in -current SMP. #uname -a FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #2: \ Mon Nov 13 19:31:49 PST 2000 \ root@celebris:/usr/src/sys/compile/CELEBRIS-SMP i386 SMPng has many pessimizations that break sio on slow machines, but I would have thought that your machine (P5 128MHz?) was fast enough. With non-SMP kernels, I have only seen silo overflows on my slowest runnable machine (486DX2/66 with 16450 at 115200 bps. A 386/20 with an 8250 at 115200 bps should work). There is just too much code in latency-critical code for slow machines to work (on the 486DX2/66, sio latency is up by a factor of 5-10; sio overheads are only up by 25-50%). I have unfinished fixes for this. I this is not related to the recent patch for conversion to mutex. I tried both ways. The patches give small or negative optimizations for the SMP case and not so small pessimizations for the non-SMP case. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message