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
