From owner-freebsd-current Sun Apr 23 0:32:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id 1B0BD37B753 for ; Sun, 23 Apr 2000 00:32:53 -0700 (PDT) (envelope-from shocking@prth.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id PAA03414; Sun, 23 Apr 2000 15:30:12 +0800 (WST) Received: from bleep.craftncomp.com (dialin20 [157.147.225.220]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id PAA08348; Sun, 23 Apr 2000 15:31:41 +0800 (WST) Received: from bloop.craftncomp.com (bloop.prth.tensor.pgs.com [202.12.111.1]) by bleep.craftncomp.com (8.9.3/8.9.3) with ESMTP id PAA01764; Sun, 23 Apr 2000 15:30:14 +0800 (WST) (envelope-from shocking@prth.pgs.com) Received: from bloop.craftncomp.com (localhost [127.0.0.1]) by bloop.craftncomp.com (8.9.3/8.9.3) with ESMTP id PAA82116; Sun, 23 Apr 2000 15:28:55 +0800 (WST) (envelope-from shocking@bloop.craftncomp.com) Message-Id: <200004230728.PAA82116@bloop.craftncomp.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: current@freebsd.org Cc: sobomax@altavista.net Subject: Last changes to SDL made smpeg not work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Apr 2000 15:28:54 +0800 From: Stephen Hocking Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The mpeg player smpeg doesn't work (catches a signal then just hangs) when you compile & link against the SDL which uses the native threads - however when you compile against one that uses linux threads, then it does. I've seen some problems with sdl test apps that mix sound & video when we use native threads rather than the linux threads port. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 0:38:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 5447837B6E5; Sun, 23 Apr 2000 00:38:04 -0700 (PDT) (envelope-from leifn@neland.dk) Received: (from uucp@localhost) by ns.internet.dk (8.9.2/8.9.3) with UUCP id JAA11301; Sun, 23 Apr 2000 09:37:58 +0200 (CEST) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.9.3/8.9.3) with ESMTP id JAA39413; Sun, 23 Apr 2000 09:37:47 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Sun, 23 Apr 2000 09:37:46 +0200 (CEST) From: Leif Neland To: Kris Kennaway Cc: Christoph Kukulies , Bill Fumerola , freebsd-current@FreeBSD.ORG Subject: Re: Stale modules (Re: panic in the morning) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 19 Apr 2000, Kris Kennaway wrote: > On Wed, 19 Apr 2000, Christoph Kukulies wrote: > > > I cvsup'ed, built world and kernel. Hhmm, actually I see no reason why > > there should be a problem since everything should be done by make world. > > make world doesn't build a kernel. Making a kernel doesn't build > modules. This bit me again the other day when updating, as well - panic at > boot when loading a stale linux.ko. > If making world _and_ kernel doesn't build modules, what _then_? Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 0:38:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137]) by hub.freebsd.org (Postfix) with ESMTP id 4272837B7C3 for ; Sun, 23 Apr 2000 00:38:24 -0700 (PDT) (envelope-from cpiazza@norn.ca.eu.org) Received: by norn.ca.eu.org (Postfix, from userid 1000) id 959EFED; Sun, 23 Apr 2000 00:38:23 -0700 (PDT) Date: Sun, 23 Apr 2000 00:38:23 -0700 From: Chris Piazza To: Stephen Hocking Cc: current@FreeBSD.ORG, sobomax@altavista.net Subject: Re: Last changes to SDL made smpeg not work Message-ID: <20000423003823.B3704@norn.ca.eu.org> References: <200004230728.PAA82116@bloop.craftncomp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004230728.PAA82116@bloop.craftncomp.com>; from shocking@prth.pgs.com on Sun, Apr 23, 2000 at 03:28:54PM +0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 23, 2000 at 03:28:54PM +0800, Stephen Hocking wrote: > The mpeg player smpeg doesn't work (catches a signal then just hangs) when you > compile & link against the SDL which uses the native threads - however when > you compile against one that uses linux threads, then it does. I've seen some > problems with sdl test apps that mix sound & video when we use native threads > rather than the linux threads port. I had just noticed this, too. It works fine if you pass --noaudio, though. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 1:18:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id 32E0F37B961 for ; Sun, 23 Apr 2000 01:18:55 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 21625 invoked from network); 23 Apr 2000 08:18:53 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 23 Apr 2000 08:18:53 -0000 Message-ID: <3902B1EB.A9E00EAB@cvzoom.net> Date: Sun, 23 Apr 2000 04:18:51 -0400 From: Donn Miller X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Leif Neland Cc: Kris Kennaway , Christoph Kukulies , Bill Fumerola , freebsd-current@FreeBSD.ORG Subject: Re: Stale modules (Re: panic in the morning) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Leif Neland wrote: > > make world doesn't build a kernel. Making a kernel doesn't build > > modules. This bit me again the other day when updating, as well - panic at > > boot when loading a stale linux.ko. > > > If making world _and_ kernel doesn't build modules, what _then_? Making world builds kernel modules. If you followed this thread before, I stated that modules should be built with the kernel. After all, they ARE kernel modules, and are part of the kernel, and not the world. I'd like to discuss further the possibility of creating some sort of mechanism where the modules can be built with the kernel. Also, we can have some sort of option in LINT or GENERIC where a keyword, such as module, can be put somewhere in the kernel config file line to compile certain drivers as modules instead of statically linking them into the kernel. Which mailing list would be appropriate for discussing kernel modules, etc.? - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 2: 2:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id 194E137B6E5; Sun, 23 Apr 2000 02:02:22 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 12jIHJ-0008kb-0C; Sun, 23 Apr 2000 09:02:09 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA35525; Sun, 23 Apr 2000 10:11:10 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 23 Apr 2000 10:07:38 +0100 (BST) From: Doug Rabson To: Greg Lehey Cc: FreeBSD Committers , FreeBSD current users Subject: Re: Remote serial gdb is broken in -CURRENT. In-Reply-To: <20000423154307.L4675@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Greg Lehey wrote: > In the last few days, my remote serial gdb has almost completely > stopped working. Previously I had (almost) no trouble at 38400 bps; > now I can barely get a response at all at 9600 bps. Does anybody have > an idea where this could be coming from? I noticed this too but I have no idea why. I also had to move back to 9600. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 6:45:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id EE4B037B5E8 for ; Sun, 23 Apr 2000 06:45:10 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 401 invoked from network); 23 Apr 2000 13:45:07 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 23 Apr 2000 13:45:07 -0000 Date: Sun, 23 Apr 2000 23:45:04 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: attila! Cc: freebsd-current@FreeBSD.ORG Subject: Re: __func__ not declared for kernel build (5.0-CURRENT) In-Reply-To: <200004222157.VAA55016@hun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 22 Apr 2000, attila! wrote: > '__func__ is not found for either the 'GENERIC' or 'hun' target. __func__ is a new feature in C99. It is an alias for the gcc feature __FUNCTION_NAME. Both give the name of the current function as a string. This feature should not be used until C99 becomes Normal, if ever. Using it breaks portability. It apparently even breaks compiling current kernels with the version of gcc in FreeBSD-3.4. I think __func__ was added in egcs (the Changelog entry for adding it in gcc is dated Dec 1 1998). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 9:17:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by hub.freebsd.org (Postfix) with ESMTP id D304A37B6BA for ; Sun, 23 Apr 2000 09:17:28 -0700 (PDT) (envelope-from netchild@leidinger.net) Received: from [62.104.201.2] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.14 #3) id 12jOmx-000433-00 for current@freebsd.org; Sun, 23 Apr 2000 17:59:15 +0200 Received: from [213.6.54.227] (helo=Magelan.Leidinger.net) by mx1.freenet.de with esmtp (Exim 3.14 #3) id 12jOms-0000Kn-00 for current@freebsd.org; Sun, 23 Apr 2000 17:59:11 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.9.3/8.9.3) with ESMTP id RAA07061 for ; Sun, 23 Apr 2000 17:58:49 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200004231558.RAA07061@Magelan.Leidinger.net> Date: Sun, 23 Apr 2000 17:58:45 +0200 (CEST) From: Alexander Leidinger Subject: pthread_cond_broadcast() not delivered To: current@freebsd.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY="0-1804289383-956505532=:1425" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --0-1804289383-956505532=:1425 Content-Type: TEXT/plain; charset=us-ascii Hi, (14) netchild@ttyp2% uname -a FreeBSD Magelan.Leidinger.net 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Fri Apr 21 17:28:37 CEST 2000 root@:/big/usr/src/sys/compile/WORK i386 I've an application which uses pthread_cond_{wait,broadcast}() and the debug output gives me the impression that the broadcast did not get delivered anymore. I run this program only occasionally, but with 4-current (last year) it worked, and I haven't changed anything mutex-/cond-related in it since then. I've attached a short test-prog (1.7k) which shows the same behavior, compile it with "cc -D_THREAD_SAFE -pthread test.c" and run "./a.out". It should print something like: ---snip--- First: thread started, waiting for pthread_cond_broadcast(). Second: lock. Second: broadcast. Second: unlock. Second: sleep. First: got broadcast. First: join. Second: exit. ---snip--- but it prints: ---snip--- First: thread started, waiting for pthread_cond_broadcast(). Second: lock. Second: broadcast. Second: unlock. Second: sleep. Second: exit. ---snip--- and waits forever (in state "poll"). Bye, Alexander. -- Secret hacker rule #11: hackers read manuals. http://www.Leidinger.net Alexander+Home @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E --0-1804289383-956505532=:1425 Content-Type: TEXT/plain; CHARSET=US-ASCII Content-Disposition: attachment; filename="test.c" #include #include #include #include pthread_mutex_t *main_mutex; pthread_cond_t *main_cond; void * second_thread(void *arg); int main(void) { pthread_t *thread; int thread_error, ret; setvbuf(stdout, NULL, _IONBF, BUFSIZ); setvbuf(stderr, NULL, _IONBF, BUFSIZ); /* mutex */ main_mutex = (pthread_mutex_t *)malloc(sizeof(pthread_mutex_t)); if(main_mutex == NULL) { return -1; } do { ret = pthread_mutex_init(main_mutex, NULL); } while(ret == EAGAIN); if(ret != 0) return -1; /* cond */ main_cond = (pthread_cond_t *)malloc(sizeof(pthread_cond_t)); if(main_cond == NULL) { return -1; } do { ret = pthread_cond_init(main_cond, NULL); } while(ret == EAGAIN); if(ret != 0) return -1; /* lock mutex */ pthread_mutex_lock(main_mutex); /* thread */ thread = (pthread_t *)malloc(sizeof(pthread_t)); if(thread == NULL) pthread_exit(0); /* error, not enough memory */ /* create pthread */ do{ thread_error = pthread_create(thread, NULL, &second_thread, NULL); } while(thread_error == EAGAIN); fprintf(stderr, "First: thread started, waiting for pthread_cond_broadcast().\n"); /* syncronize */ pthread_cond_wait(main_cond, main_mutex); fprintf(stderr, "First: got broadcast.\n"); sleep(2); fprintf(stderr, "First: join.\n"); pthread_join(*thread, NULL); exit(0); } void * second_thread(void *arg) { /* syncronize */ fprintf(stderr, "Second: lock.\n"); pthread_mutex_lock(main_mutex); fprintf(stderr, "Second: broadcast.\n"); pthread_cond_broadcast(main_cond); fprintf(stderr, "Second: unlock.\n"); pthread_mutex_lock(main_mutex); fprintf(stderr, "Second: sleep.\n"); sleep(10); fprintf(stderr, "Second: exit.\n"); pthread_exit(0); } --0-1804289383-956505532=:1425-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 9:32:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 7019237B9DB for ; Sun, 23 Apr 2000 09:32:52 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id JAA09939 for ; Sun, 23 Apr 2000 09:34:11 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: current@freebsd.org Subject: worldbuild breakage of the day (BOTD?) Date: Sun, 23 Apr 2000 09:34:11 -0700 Message-ID: <9936.956507651@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/ src/usr.bin/netstat/ipx.c cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/ src/usr.bin/netstat/route.c /usr/src/usr.bin/netstat/route.c: In function `p_tree': /usr/src/usr.bin/netstat/route.c:284: structure has no member named `rn_b' /usr/src/usr.bin/netstat/route.c:308: structure has no member named `rn_r' /usr/src/usr.bin/netstat/route.c:309: structure has no member named `rn_l' /usr/src/usr.bin/netstat/route.c: In function `p_rtnode': /usr/src/usr.bin/netstat/route.c:321: structure has no member named `rn_b' /usr/src/usr.bin/netstat/route.c:329: structure has no member named `rn_b' /usr/src/usr.bin/netstat/route.c:330: structure has no member named `rn_l' /usr/src/usr.bin/netstat/route.c:330: structure has no member named `rn_r' /usr/src/usr.bin/netstat/route.c:336: structure has no member named `rm_b' *** Error code 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 10:30:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B46C437B688 for ; Sun, 23 Apr 2000 10:30:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA62311; Sun, 23 Apr 2000 10:30:20 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 10:30:20 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231730.KAA62311@apollo.backplane.com> To: Bruce Evans Cc: attila , freebsd-current@FreeBSD.ORG Subject: Re: __func__ not declared for kernel build (5.0-CURRENT) References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Sat, 22 Apr 2000, attila! wrote: : :> '__func__ is not found for either the 'GENERIC' or 'hun' target. : :__func__ is a new feature in C99. It is an alias for the gcc feature :__FUNCTION_NAME. Both give the name of the current function as a string. : :This feature should not be used until C99 becomes Normal, if ever. :Using it breaks portability. It apparently even breaks compiling :current kernels with the version of gcc in FreeBSD-3.4. I think :__func__ was added in egcs (the Changelog entry for adding it in gcc :is dated Dec 1 1998). : :Bruce You mean __FUNCTION__ ? __FILE__ and __LINE__ have been standard for a long time. The obviously missing __FUNCTION__ was added by GCC many years ago, but it was a while before it's use in defines in header (.h) files was dealt with properly. I wish these stupid standards committees would just choose something that people are already using rather then make up new names! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 10:42: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from hun.org (hun.org [216.190.28.252]) by hub.freebsd.org (Postfix) with ESMTP id 5701E37B688 for ; Sun, 23 Apr 2000 10:42:03 -0700 (PDT) (envelope-from attila@hun.org) Received: (from attila@localhost) by hun.org (8.9.3/8.9.2) id RAA00425; Sun, 23 Apr 2000 17:41:53 GMT (envelope-from attila) Date: Sun, 23 Apr 2000 17:41:53 GMT Message-Id: <200004231741.RAA00425@hun.org> From: attila! Organization: hun.org, over 40 years beyond the fringe home for unpenitent hackers and anarcho-cryptophreaks Mailer: FreeBSD 4.0-current with XEmacs V20.4 (see alt.religion.emacs) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit; Content-Disposition: Inline Cc: Bruce Evans To: freebsd-current@FreeBSD.ORG Subject: on the road to stomping out __func__ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG you're correct (see reply from Bruce Evans below) __func__ is in /usr/src/contrib/gcc/c-common.c ChangeLog:9854: `__func__'. c-common.c:164:/* Make bindings for __FUNCTION__, __PRETTY_FUNCTION__, and __func__. */ c-common.c:190: declare_hidden_char_array ("__func__", name); which, if as indicated in ChangeLog:9854 Tue Dec 1 20:49:49 1998 Ulrich Drepper Stephen L Moshier Richard Henderson * c-common.c (declare_function_name): Declare predefined variable `__func__'. makes me question why the gcc compiler which I believe was in use for 4.0-CURRENT prior to 21 Jul 99, does not include the declaration, particularly since the compiler used for the compile was based on a CURRENT cvsup of 29 Jun 99.... However, that still leaves me between a rock and a hard spot! Kernel usage appears limited solely to two error statements in /usr/src/sys/i386/i386/cksum.c in_cksum.c: 238 if (len) 239 printf("%s: out of data by %d\n", __func__, len); 426 if (len) 427 printf("%s: out of data by %d\n", __func__, len); Which is easily enough circumvented (kludged): 238 if (len) 243 printf("%s: out of data by %d\n", "in_cksum", len); 431 if (len) 435 printf("%s: out of data by %d\n", "in_cksum_skip", len); Which is an abomination... and like Bruce, I question the need for __func__ at this point... But, beggars can not be choosers, and, it does compile, without errors, both GENERIC and the target 'hun'. And, even better, it appears to execute X from 4.0-CURRENT along with Xemacs, pine, xshisen (great during long compiles) etc. --what more could I ask for? Easy, a good 'make world' and update of /etc files. since my cvsup is from 000422.1619 UCT, maybe JKH's 'BOTD' in netstat.c had not crept in... On Sun, 23 Apr 2000, Bruce Evans wrote: + On Sat, 22 Apr 2000, attila! wrote: + + > '__func__ is not found for either the 'GENERIC' or 'hun' target. + + __func__ is a new feature in C99. It is an alias for the gcc feature + __FUNCTION_NAME. Both give the name of the current function as a string. + + This feature should not be used until C99 becomes Normal, if ever. + Using it breaks portability. It apparently even breaks compiling + current kernels with the version of gcc in FreeBSD-3.4. I think + __func__ was added in egcs (the Changelog entry for adding it in gcc + is dated Dec 1 1998). + To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 11:10: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1E5B037B9B4 for ; Sun, 23 Apr 2000 11:10:02 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA29230; Sun, 23 Apr 2000 14:09:40 -0400 (EDT) Date: Sun, 23 Apr 2000 14:09:40 -0400 (EDT) From: Daniel Eischen Message-Id: <200004231809.OAA29230@pcnet1.pcnet.com> To: Alexander@Leidinger.net, current@FreeBSD.ORG Subject: Re: pthread_cond_broadcast() not delivered Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alexander Leidinger wrote: > Hi, > > (14) netchild@ttyp2% uname -a > FreeBSD Magelan.Leidinger.net 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Fri Apr 21 17:28:37 CEST 2000 root@:/big/usr/src/sys/compile/WORK i386 > > I've an application which uses pthread_cond_{wait,broadcast}() and > the debug output gives me the impression that the broadcast did not get > delivered anymore. > > I run this program only occasionally, but with 4-current (last year) it > worked, and I haven't changed anything mutex-/cond-related in it since > then. > > I've attached a short test-prog (1.7k) which shows the same behavior, > compile it with "cc -D_THREAD_SAFE -pthread test.c" and run "./a.out". If you want it to work correctly, you have to make the second thread release the mutex. Look at it more closely: void * second_thread(void *arg) { /* syncronize */ fprintf(stderr, "Second: lock.\n"); pthread_mutex_lock(main_mutex); fprintf(stderr, "Second: broadcast.\n"); pthread_cond_broadcast(main_cond); fprintf(stderr, "Second: unlock.\n"); pthread_mutex_lock(main_mutex); ^^^^^^^^^^^^^^^^^^ fprintf(stderr, "Second: sleep.\n"); sleep(10); fprintf(stderr, "Second: exit.\n"); pthread_exit(0); } -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 11:35:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DF2FC37B9EA; Sun, 23 Apr 2000 11:35:16 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA62963; Sun, 23 Apr 2000 11:35:14 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 11:35:14 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231835.LAA62963@apollo.backplane.com> To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is the same patch I put up for review two weeks ago. I got one positive comment back and nothing else, so I presume nobody has a problem with it. I've been running with it for a while but have only tested it with a few linux applications (Java (jre, jdk), and the oracle installer stuff). http://www.backplane.com/FreeBSD4/linux-script-01.diff This patch fixes #! paths in scripts run under linux emulation, causing /compat/linux to be searched for the script binary when the script is exec'd from a program running under emulation. Often linux applications run scripts to do various things. Without this patch these scripts effectively 'break out' of the linux emulation (for example, use the FreeBSD version of /bin/sh instead of the linux version of /bin/sh) which can cause compatibility problems, especially when the scripts run other utilities that they expect to be the linux version rather then FreeBSD version (install, cat, grep, etc...) I intend to commit this to -current and immediately MFC it to -stable. I don't expect there to be any controversy though I'm sure there is a cleaner way to do it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 11:38:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id E52FE37B9CC; Sun, 23 Apr 2000 11:38:41 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA45498; Sun, 23 Apr 2000 20:37:51 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-reply-to: Your message of "Sun, 23 Apr 2000 11:35:14 PDT." <200004231835.LAA62963@apollo.backplane.com> Date: Sun, 23 Apr 2000 20:37:51 +0200 Message-ID: <45496.956515071@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200004231835.LAA62963@apollo.backplane.com>, Matthew Dillon writes: > I intend to commit this to -current and immediately MFC it to -stable. > I don't expect there to be any controversy though I'm sure there is a > cleaner way to do it. I don't see anything justifying an immediate MFC in this patch. Please allow the normal waiting period to elapse before you MFC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 11:46:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2C7FC37B9F2; Sun, 23 Apr 2000 11:46:38 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA63231; Sun, 23 Apr 2000 11:46:34 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 11:46:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231846.LAA63231@apollo.backplane.com> To: Poul-Henning Kamp Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <45496.956515071@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200004231835.LAA62963@apollo.backplane.com>, Matthew Dillon writes: : :> I intend to commit this to -current and immediately MFC it to -stable. :> I don't expect there to be any controversy though I'm sure there is a :> cleaner way to do it. : :I don't see anything justifying an immediate MFC in this patch. Please :allow the normal waiting period to elapse before you MFC. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 It's such a simple patch, and it fixes problems that would otherwise exist under 4.x's linux emulation, and it only effects the linux emulation. And I've been running it for a while under 5.x already (as I said). And I put it up for a review 2 weeks ago. And it makes no major infrastructure changes to the core system. Unless you can justify a reason for it NOT to be MFC'd immediately, I see no reason to wait for this particular baby. That is, unless you *like* linux applications that use scripts to start running FreeBSD utilities even when you have all the appropriate linux packages installed! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 11:50:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id DC55837BA18; Sun, 23 Apr 2000 11:50:53 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA45596; Sun, 23 Apr 2000 20:50:10 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-reply-to: Your message of "Sun, 23 Apr 2000 11:46:34 PDT." <200004231846.LAA63231@apollo.backplane.com> Date: Sun, 23 Apr 2000 20:50:09 +0200 Message-ID: <45594.956515809@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200004231846.LAA63231@apollo.backplane.com>, Matthew Dillon writes: >:I don't see anything justifying an immediate MFC in this patch. Please >:allow the normal waiting period to elapse before you MFC. > > Unless you can justify a reason for it NOT to be MFC'd immediately, I > see no reason to wait for this particular baby. Sorry, Matt, that is not the way it works. Unless there is an overriding issue, things do not get MFC'ed immediately. You have only cited reasons why it would be much more convenient for you personally to MFC right away, that is not enough to justify an immediate MFC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 11:55:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 79B3637B52A; Sun, 23 Apr 2000 11:55:08 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA63309; Sun, 23 Apr 2000 11:55:08 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 11:55:08 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231855.LAA63309@apollo.backplane.com> To: Poul-Henning Kamp , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <45496.956515071@critter.freebsd.dk> <200004231846.LAA63231@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There's another good reason to MFC the linux patch on wednesday... that is, to do it at the same time the SMP cleanup is MFC'd, and that is because both patch sets require the linux kernel module to be recompiled and I'd rather not force people to do that twice. The SMP patchset, in fact, requires that all kernel modules be recompiled due to the locks that were removed from the spl*() macros. This is something I would contemplate doing for 4.0->4.1, but not something I would consider for 4.1 onward. Even though 4.0 is the most stable .0 release we've ever had, it's still a .0. I wonder if it makes sense to add a release id to the module header and have the module loader refuse (unless forced) to load modules that are out-of-date with the kernel? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12: 0:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id D17D137BA2F; Sun, 23 Apr 2000 12:00:33 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA45657; Sun, 23 Apr 2000 20:59:48 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-reply-to: Your message of "Sun, 23 Apr 2000 11:55:08 PDT." <200004231855.LAA63309@apollo.backplane.com> Date: Sun, 23 Apr 2000 20:59:48 +0200 Message-ID: <45655.956516388@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200004231855.LAA63309@apollo.backplane.com>, Matthew Dillon writes: > There's another good reason to MFC the linux patch on wednesday... > that is, to do it at the same time the SMP cleanup is MFC'd, and that > is because both patch sets require the linux kernel module to be > recompiled and I'd rather not force people to do that twice. Matt, this is not a valid reason either. Unless there is *urgent* and *overriding* reasons, and that basically means that the security-officer says so, all changes must be shaken out in -current first. That's just the way it is Matt. Get used to it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12: 1:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F0E5037B90D; Sun, 23 Apr 2000 12:01:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA63381; Sun, 23 Apr 2000 12:01:46 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 12:01:46 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231901.MAA63381@apollo.backplane.com> To: Poul-Henning Kamp Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <45594.956515809@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In message <200004231846.LAA63231@apollo.backplane.com>, Matthew Dillon writes: : :>:I don't see anything justifying an immediate MFC in this patch. Please :>:allow the normal waiting period to elapse before you MFC. :> :> Unless you can justify a reason for it NOT to be MFC'd immediately, I :> see no reason to wait for this particular baby. : :Sorry, Matt, that is not the way it works. Unless there is an overriding :issue, things do not get MFC'ed immediately. : :You have only cited reasons why it would be much more convenient for you :personally to MFC right away, that is not enough to justify an immediate :MFC. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I'm sorry, Poul, but you are going to have to come up with better reasoning then that. Not all changes committed to -current require a waiting period before being MFC'd to stable. Specifically, simple and obvious bug fixes certainly do not need a waiting period. My reasoning has nothing to do with what is or is not personally convenient for me, and frankly your insinuation that it is is rather insulting. After all, look how long I've waited for the SMP patches before considering MFCing those? It sure would have been more convenient for me to MFC them a week after 5.0 stabilized and before I began work on other patch sets but I didn't. Due to the gravity of the changes I thought it would be best to give them a really good test run under 5.x (and note: I received permission from Jordan to MFC the SMP stuff weeks ago, and even with that permission I decided to wait). I do not consider the linux scripting patch to be a major infrastructure change, I consider it to be a simple bug fix. If you have a functional issue with the patch I'm all ears. If you disagree with my assessment of the triviality of the linux scripting patch, then I will ask for a second opinion from someone who is not quite so jaded in regards to my commits... say Jordan or DG. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12: 6:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id F3E3237B690; Sun, 23 Apr 2000 12:06:25 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA45716; Sun, 23 Apr 2000 21:05:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-reply-to: Your message of "Sun, 23 Apr 2000 12:01:46 PDT." <200004231901.MAA63381@apollo.backplane.com> Date: Sun, 23 Apr 2000 21:05:41 +0200 Message-ID: <45714.956516741@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200004231901.MAA63381@apollo.backplane.com>, Matthew Dillon writes: > I'm sorry, Poul, but you are going to have to come up with better > reasoning then that. > > Not all changes committed to -current require a waiting period before > being MFC'd to stable. Specifically, simple and obvious bug fixes > certainly do not need a waiting period. Matt, This does not apply to your patch. The "simple and obvious" loophole applies to spelling fixes and similar, not to anything which changes behaviour of the system. Your current patch does not qualify for immediate MFC status unless the security officer says so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12: 9:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 665EE37B64A; Sun, 23 Apr 2000 12:09:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA63432; Sun, 23 Apr 2000 12:09:18 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 12:09:18 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231909.MAA63432@apollo.backplane.com> To: Poul-Henning Kamp Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <45655.956516388@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200004231855.LAA63309@apollo.backplane.com>, Matthew Dillon writes: : :> There's another good reason to MFC the linux patch on wednesday... :> that is, to do it at the same time the SMP cleanup is MFC'd, and that :> is because both patch sets require the linux kernel module to be :> recompiled and I'd rather not force people to do that twice. : :Matt, this is not a valid reason either. : :Unless there is *urgent* and *overriding* reasons, and that basically :means that the security-officer says so, all changes must be shaken :out in -current first. : :That's just the way it is Matt. Get used to it. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I think you're confused, Poul. I've gone over the commits made to the tree by people over the last few months and frankly there are dozens of simultanious -current and -stable commits. A quick check shows that most of them are trivial bug fixes. I will also point out that the current STABLE and CURRENT trees are being treated as a special case. Jordan himself said so! And that he has made a specific statement indicating that people could develop in the 4.x tree due to the potential breakage in the 5.x tree. This seems entirely appropriate to me. If the rules have changed since that announcement, then I recommend that core make an official statement to correct it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:10: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id B124F37BA74; Sun, 23 Apr 2000 12:09:58 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id MAA09128; Sun, 23 Apr 2000 12:09:36 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200004231909.MAA09128@gndrsh.dnsmgr.net> Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-Reply-To: <200004231855.LAA63309@apollo.backplane.com> from Matthew Dillon at "Apr 23, 2000 11:55:08 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sun, 23 Apr 2000 12:09:36 -0700 (PDT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There's another good reason to MFC the linux patch on wednesday... > that is, to do it at the same time the SMP cleanup is MFC'd, and that > is because both patch sets require the linux kernel module to be > recompiled and I'd rather not force people to do that twice. > > The SMP patchset, in fact, requires that all kernel modules be > recompiled due to the locks that were removed from the spl*() macros. In that case I have a strong objection to the SMP patchset being merged to 4.0. I have kernel modules in object format only that are working now, which this would break :-(. Either way, nothing ever should me an immediate MFC, even a blantant security hole should not be MFC'ed immediately, code needs to be tested, and some other person might find a few niglets that need cleaned up before you MFC it. Who knows, you might even break the system, and an immediate MFC would break both at once. Never, ever should anything be immediatly merged. IMHO, no even spelling fixes, as I have seen those done wrong, patched, and MFC'ed again. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:12:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id BE7B337B9F1; Sun, 23 Apr 2000 12:12:22 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA45768; Sun, 23 Apr 2000 21:11:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-reply-to: Your message of "Sun, 23 Apr 2000 12:09:18 PDT." <200004231909.MAA63432@apollo.backplane.com> Date: Sun, 23 Apr 2000 21:11:38 +0200 Message-ID: <45766.956517098@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt, I will say it this last time: Your patch does not qualify for immediate MFC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:13:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 1934C37B8E4; Sun, 23 Apr 2000 12:13:25 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id MAA09141; Sun, 23 Apr 2000 12:13:02 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200004231913.MAA09141@gndrsh.dnsmgr.net> Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-Reply-To: <200004231909.MAA63432@apollo.backplane.com> from Matthew Dillon at "Apr 23, 2000 12:09:18 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sun, 23 Apr 2000 12:13:02 -0700 (PDT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > : > :In message <200004231855.LAA63309@apollo.backplane.com>, Matthew Dillon writes: > : > :> There's another good reason to MFC the linux patch on wednesday... > :> that is, to do it at the same time the SMP cleanup is MFC'd, and that > :> is because both patch sets require the linux kernel module to be > :> recompiled and I'd rather not force people to do that twice. > : > :Matt, this is not a valid reason either. > : > :Unless there is *urgent* and *overriding* reasons, and that basically > :means that the security-officer says so, all changes must be shaken > :out in -current first. > : > :That's just the way it is Matt. Get used to it. > : > :-- > :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > I think you're confused, Poul. I've gone over the commits made > to the tree by people over the last few months and frankly there > are dozens of simultanious -current and -stable commits. A quick > check shows that most of them are trivial bug fixes. And look at how many of them had to be patched, re-merged, etc. IMHO people are getting way way to loose with MFC right after a commit. I don't even want to see a MFC for a 1 character spelling fixed MFC'ed in less than 3 days anymore. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:22:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5AAC837BA43; Sun, 23 Apr 2000 12:22:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA63538; Sun, 23 Apr 2000 12:22:00 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 12:22:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231922.MAA63538@apollo.backplane.com> To: "Rodney W. Grimes" Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <200004231913.MAA09141@gndrsh.dnsmgr.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> : :> :-- :> :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :> :> I think you're confused, Poul. I've gone over the commits made :> to the tree by people over the last few months and frankly there :> are dozens of simultanious -current and -stable commits. A quick :> check shows that most of them are trivial bug fixes. : :And look at how many of them had to be patched, re-merged, etc. IMHO :people are getting way way to loose with MFC right after a commit. I :don't even want to see a MFC for a 1 character spelling fixed MFC'ed :in less than 3 days anymore. : :-- :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net Perfectly acceptable to me ... *IF* core decides to change the rules they've made for the current development trees (stable and current) and makes an official statement that covers everyone rather then just Matt. I think the work required to accomplish the BSDI merger is overrated anyway (in regards to the source tree). I kinda expected the BSDI people to start working on it immediately but obviously the pace is going to be a lot slower. Core should consider reverting the special rules that were originally created with the expectation of major breakage in 5.x back to the set of rules we had for 3.x and 4.x. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:27:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 7AAE137BA15; Sun, 23 Apr 2000 12:27:23 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA45853; Sun, 23 Apr 2000 21:24:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-reply-to: Your message of "Sun, 23 Apr 2000 12:22:00 PDT." <200004231922.MAA63538@apollo.backplane.com> Date: Sun, 23 Apr 2000 21:24:35 +0200 Message-ID: <45851.956517875@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200004231922.MAA63538@apollo.backplane.com>, Matthew Dillon writes: > Core should consider reverting the special rules that were originally > created with the expectation of major breakage in 5.x back to > the set of rules we had for 3.x and 4.x. I have no idea what special rules you are talking about for 4.x/5.x. 4.x-stable is a -stable tree and shall be treated as such. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:29: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4529737BA0B; Sun, 23 Apr 2000 12:28:59 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA63577; Sun, 23 Apr 2000 12:28:56 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 12:28:56 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231928.MAA63577@apollo.backplane.com> To: Poul-Henning Kamp Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <45766.956517098@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :Matt, : :I will say it this last time: : : Your patch does not qualify for immediate MFC. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 And I will say this to you for the last time: Under the current rules my patch DOES qualify for an immediate MFC. Hell, by the current rules developers can commit to 4.x FIRST! And unless you can come up with something better then this superior attitude bullshit, that is what is going to happen in this particular case. Frankly, what it comes down to is that if DG or Jordan ask me to delay, I know they will have a damn good reason for doing so and I will of course delay. But you, Poul, have used up all your brownie points and I'm getting tired of you changing the rules to suit your current whims, and then changing them again to justify your own commits. Your duel-standard is getting rather tired and your words simply do not have any weight with me any more. If core wants to change the current rules, that's fine by me. As I said before I think the breakage that we thought would happen with 5.x due to the BSDI merger that prompted the loose rules for 4.x is overrated, and the rules should probably be reverted back to standard. -Matt Matthew Dillon :phk@FreeBSD.ORG | TCP/IP since RFC 956 :FreeBSD coreteam member | BSD since 4.3-tahoe :Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:30:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B87B737BAF3; Sun, 23 Apr 2000 12:30:22 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA63599; Sun, 23 Apr 2000 12:30:19 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 12:30:19 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231930.MAA63599@apollo.backplane.com> To: Poul-Henning Kamp Cc: "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <45851.956517875@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200004231922.MAA63538@apollo.backplane.com>, Matthew Dillon writes: : :> Core should consider reverting the special rules that were originally :> created with the expectation of major breakage in 5.x back to :> the set of rules we had for 3.x and 4.x. : :I have no idea what special rules you are talking about for 4.x/5.x. : :4.x-stable is a -stable tree and shall be treated as such. Really, then you have a short memory. Why don't we ask Jordan for a clarification. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:47:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from hun.org (hun.org [216.190.28.252]) by hub.freebsd.org (Postfix) with ESMTP id D775A37B50B; Sun, 23 Apr 2000 12:47:34 -0700 (PDT) (envelope-from attila@hun.org) Received: (from attila@localhost) by hun.org (8.9.3/8.9.2) id TAA36929; Sun, 23 Apr 2000 19:47:23 GMT (envelope-from attila) Date: Sun, 23 Apr 2000 19:47:23 GMT Message-Id: <200004231947.TAA36929@hun.org> From: attila! Organization: hun.org, over 40 years beyond the fringe home for unpenitent hackers and anarcho-cryptophreaks Mailer: FreeBSD 5.0-current with XEmacs V20.4 (see alt.religion.emacs) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit; Content-Disposition: Inline To: Donn Miller Cc: Leif Neland , Kris Kennaway , Christoph Kukulies , Bill Fumerola , freebsd-current@FreeBSD.ORG Subject: attachable driver modules (Re: Stale modules (Re: panic in the morning)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Donn Miller wrote: > I'd like to discuss further the possibility of creating some sort of > mechanism where the modules can be built with the kernel. Also, we > can have some sort of option in LINT or GENERIC where a keyword, such > as module, can be put somewhere in the kernel config file line to > compile certain drivers as modules instead of statically linking them > into the kernel. > An item which would probably go a long way towards demystifying the kernel process would be to use loader.rc to add device modules at load time; for instance, all the Ethernet cards, the list of which is always in flux. Theoretically, it should be possible to go as far as the disk, tape, CD, etc. drives (no point in floppies), and even a choice between the console and a VT220 on a port. Initial load would bring in a /GENERIC from which a GUI with check the boxes would configure loader.rc and subsequent reboots would be with the standard /kernel. To modify an existing /kernel, reboot with /GENERIC... or make the editor accessible, maybe even including an X option. The Linux crowd, or at least Caldera and Corel, are trying to beautify the install... I have ranted for over 20 years, starting with Bell Labs, BSD 4.0, and numerous keynotes in Europe in the 80s (too inflammatory to the 100+ U.S. feel-good *ix vendors). I can remember being impressed with SUN's GUI install in the 1982 SUN 2 (I still have both a "macho" SUN 1 and a SUN 2). We, who as a whole live by RTFM (and my extension of RTFS-source), have not been willing to grant the unwashed an audience. But, keep in mind, Bill Gate$, with a snappy check the box setup, marginalized us --and still does despite an "almost usable" product with daily or hourly BSODs vs. my last uptime of 272 days! It's all well and good that us 'cognizenti' or 'intelligentsia' are perfectly happy with a command line interface. But X permits me to run at least 4 'xterm' windows, pine, Xemacs, dclock, xcdplayer, xshisen, and Netscape --and have as many as 40 open Netscape windows (great for picking e-News articles in a batch or diversions --no backstepping). I could care less about KDE's or Gnome's flash (in fact, KDE's visible primary folders plus the icons are a nuisance) --hence I use the old standby: 'TWM' which works fine for me. the bottom line is if we (and Linux and the rest of the crowd) wish to push Gate$' $lop off the desktop, we need to be user- friendly --that, and hope Judge Jackson forces 'Office' into Open Source which would sure light BadBillyG's fire! attila out... -- Caveat: No Microsoft programs or processes were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, please be advised I am not responsible for any harm you may suffer as a result. ___ ___ ___ _ __ ___ | _ ) __| \ freeBSD: The Power to Serve! _ __ ___ ____ | _ \__ \ |) | Release 5.0-CURRENT - The Fast Lane! __ ____ _____ |___/___/___/ It's like a wigwam -- no Gates, no Windows, and an Apache inside. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 12:48: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.79.126]) by hub.freebsd.org (Postfix) with ESMTP id E9B0F37BACC; Sun, 23 Apr 2000 12:47:58 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.79.115]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA28428; Sun, 23 Apr 2000 13:47:35 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA08296; Sun, 23 Apr 2000 13:47:35 -0600 (MDT) (envelope-from nate) Date: Sun, 23 Apr 2000 13:47:35 -0600 (MDT) Message-Id: <200004231947.NAA08296@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: Matthew Dillon , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-Reply-To: <45851.956517875@critter.freebsd.dk> References: <200004231922.MAA63538@apollo.backplane.com> <45851.956517875@critter.freebsd.dk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Core should consider reverting the special rules that were originally > > created with the expectation of major breakage in 5.x back to > > the set of rules we had for 3.x and 4.x. > > I have no idea what special rules you are talking about for 4.x/5.x. > > 4.x-stable is a -stable tree and shall be treated as such. I was under the impression that 4.x hasn't been designated as the stable branch (yet). That will happen when 4.1 is released, but until that happens 3.x is still considered the -stable release. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13: 2:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 742B837B66B; Sun, 23 Apr 2000 13:02:17 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Sun, 23 Apr 2000 15:02:07 -0500 From: Richard Wackerbarth To: Matthew Dillon Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday Date: Sun, 23 Apr 2000 15:02:06 -0500 X-Mailer: KMail [version 1.1.40] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG References: <45766.956517098@critter.freebsd.dk> <200004231928.MAA63577@apollo.backplane.com> In-Reply-To: <200004231928.MAA63577@apollo.backplane.com> MIME-Version: 1.0 Message-Id: <00042315020600.20614@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Matthew Dillon wrote: > If core wants to change the current rules, that's fine by me. As I > said before I think the breakage that we thought would happen with 5.x > due to the BSDI merger that prompted the loose rules for 4.x is > overrated, and the rules should probably be reverted back to standard. Well, unless I missed some REQUIREMENT in "the rules", there is nothing to prevent you from applying to your own actions the policy that you think should be the rule and apply to everyone. Just because you COULD do something and stay within the letter of the law, that is no excuse to do it. Although I suspect that your change is a general improvement, it is certainly a change that might have adverse impact on some users. Therefore, I think that if should receive closer and more widespread review before being committed to any of the "stable" branches. Personally, I will use the attitude that you have been expressing to justify my claim that FreeBSD is still just a "developers' sandbox". Until ALL the developers start to think about changes from the perspective of the end user, it will remain so. IMHO, there is entirely too much rush to force untested changes on everyone. Every change should flow through the slowly widening set of exposures afforded by gradual commits to the various forums. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:14:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 07B2637BA1F; Sun, 23 Apr 2000 13:14:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64138; Sun, 23 Apr 2000 13:14:21 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 13:14:21 -0700 (PDT) From: Matthew Dillon Message-Id: <200004232014.NAA64138@apollo.backplane.com> To: "Rodney W. Grimes" Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: SMP changes and breaking kld object module compatibility References: <200004231909.MAA09128@gndrsh.dnsmgr.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> There's another good reason to MFC the linux patch on wednesday... :> that is, to do it at the same time the SMP cleanup is MFC'd, and that :> is because both patch sets require the linux kernel module to be :> recompiled and I'd rather not force people to do that twice. :> :> The SMP patchset, in fact, requires that all kernel modules be :> recompiled due to the locks that were removed from the spl*() macros. : :In that case I have a strong objection to the SMP patchset being :merged to 4.0. I have kernel modules in object format only that :are working now, which this would break :-(. : :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net This is a legitimate topic for discussion. In general I agree with the concept but I think .0 releases have to have a bit more flexibility, and that 4.0 in particular (due to the rules change made for the BSDI merger) has to be even more flexible. We should be allowed to break kernel module loader compatibility in between a .0 and a .1 release if it is deemed necessary, but that it should be avoided (as much as possible) after the .1 release. I would put forth that the SMP patches are a special case in that they provide a base for which further BGL unwinding can occur in both 4.x and 5.x without further API breakages (beyond this one). If we do not MFC the SMP cleanup, then there is no chance of being able to MFC *ANY* further SMP-related lock removal or performance work from 5.x to 4.x. I believe that it is fairly important to try to extend the SMP work into 4.x as much as possible, otherwise certain significant performance improvements that might be made in a very unstable 5.x will not be available to the general public in the stable 4.x for another year. I expect most production machines will be running 4.x for at least the year and a half. To be blunt, if we don't do this now then we are going to be behind the competition (linux, solaris) for much too long. As an example of how important this can be I would point back to the 3.x and 4.x trees during the VM work I did. By not MFCing from the outset we reached a point where bug fixes going into 4.x could *not* be backported to 3.x without a lot of work. We reached a point where bug fixes (garbage after file EOF in mmaps for example) simply could not be backported, or required a lot of work (some of the NFS fixes had to be rewritten for 3.x). I think it may be even more important for 4.x and 5.x in regards to the SMP work. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:21:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 24D8537BA0F; Sun, 23 Apr 2000 13:21:18 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id NAA06740; Sun, 23 Apr 2000 13:18:26 -0700 (PDT) Message-Id: <200004232018.NAA06740@implode.root.com> To: Matthew Dillon Cc: Poul-Henning Kamp , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-reply-to: Your message of "Sun, 23 Apr 2000 12:01:46 PDT." <200004231901.MAA63381@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 23 Apr 2000 13:18:26 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I do not consider the linux scripting patch to be a major infrastructure > change, I consider it to be a simple bug fix. If you have a functional > issue with the patch I'm all ears. If you disagree with my assessment of > the triviality of the linux scripting patch, then I will ask for a > second opinion from someone who is not quite so jaded in regards to my > commits... say Jordan or DG. I'm sure you're right that the impact is minor. I'm a little uncomfortable with immediate MFC's, even though I've been guilty of doing that myself at times in the past. Can we perhaps compromise and allow for a one day delay? At least that would catch glaring mistakes like mis-applied patches that happen sometimes even with highly skilled developers who have only the best intentions. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:22:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 7DDD037BAAC for ; Sun, 23 Apr 2000 13:22:14 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Sun, 23 Apr 2000 15:21:49 -0500 From: Richard Wackerbarth To: Matthew Dillon Subject: Re: SMP changes and breaking kld object module compatibility Date: Sun, 23 Apr 2000 15:21:49 -0500 X-Mailer: KMail [version 1.1.40] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <200004232014.NAA64138@apollo.backplane.com> In-Reply-To: <200004232014.NAA64138@apollo.backplane.com> MIME-Version: 1.0 Message-Id: <00042315214900.24082@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Matthew Dillon wrote: > :In that case I have a strong objection to the SMP patchset being > :merged to 4.0. I have kernel modules in object format only that > :are working now, which this would break :-(. > : > :Rod Grimes - KD7CAX @ CN85sl - (RWG25) > : rgrimes@gndrsh.dnsmgr.net > > This is a legitimate topic for discussion. > > In general I agree with the concept but I think .0 releases have to > have a bit more flexibility, and that 4.0 in particular (due to the > rules change made for the BSDI merger) has to be even more flexible. > We should be allowed to break kernel module loader compatibility > in between a .0 and a .1 release if it is deemed necessary, but that > it should be avoided (as much as possible) after the .1 release. Rather than break the FreeBSD4 modules over which you have no control, perhaps your arguments should be used to accelerate the 5.0 release and make 4.x a short lived branch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:23:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-202-179-64.dsl.snfc21.pacbell.net [63.202.179.64]) by hub.freebsd.org (Postfix) with ESMTP id 215CB37B9B9; Sun, 23 Apr 2000 13:23:27 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA51633; Sun, 23 Apr 2000 13:30:39 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004232030.NAA51633@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-reply-to: Your message of "Sun, 23 Apr 2000 11:55:08 PDT." <200004231855.LAA63309@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Apr 2000 13:30:39 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I wonder if it makes sense to add a release id to the module header > and have the module loader refuse (unless forced) to load modules that > are out-of-date with the kernel? We actually have a whole module dependancy and versioning system more or less ready to go into -current. It could have gone in for 4.0, but we wouldn't have had time to test it. I would avoid rolling anything half-assed at this point in time. BTW; whilst I think Poul was entirely the wrong person to raise the issue, I agree that you probably want to hang back on MFCing the linux scripting changes for a week or so. This is really just common sense. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:25:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 69D9F37BA50; Sun, 23 Apr 2000 13:25:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64213; Sun, 23 Apr 2000 13:25:30 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 13:25:30 -0700 (PDT) From: Matthew Dillon Message-Id: <200004232025.NAA64213@apollo.backplane.com> To: David Greenman Cc: Poul-Henning Kamp , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <200004232018.NAA06740@implode.root.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> I do not consider the linux scripting patch to be a major infrastructure :> change, I consider it to be a simple bug fix. If you have a functional :> issue with the patch I'm all ears. If you disagree with my assessment of :> the triviality of the linux scripting patch, then I will ask for a :> second opinion from someone who is not quite so jaded in regards to my :> commits... say Jordan or DG. : : I'm sure you're right that the impact is minor. I'm a little uncomfortable :with immediate MFC's, even though I've been guilty of doing that myself at :times in the past. Can we perhaps compromise and allow for a one day delay? :At least that would catch glaring mistakes like mis-applied patches that :happen sometimes even with highly skilled developers who have only the best :intentions. : :-DG : :David Greenman Sure, no problem. I'll tell you what, I'll commit the linux scripting patch to 5.x on wednesday as originally planned, but since the SMP MFC is being moved to friday (at the very least) I will not MFC the scripting patch to 4.x until friday. ( That is, what I really want to do is to do the SMP MFC and the scripting MFC at the same time so people only have to recompile their kernel modules once. It happens to work out well ). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:29:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 92FFD37BA4B; Sun, 23 Apr 2000 13:29:37 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id NAA06779; Sun, 23 Apr 2000 13:25:43 -0700 (PDT) Message-Id: <200004232025.NAA06779@implode.root.com> To: Matthew Dillon Cc: "Rodney W. Grimes" , phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-reply-to: Your message of "Sun, 23 Apr 2000 13:14:21 PDT." <200004232014.NAA64138@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 23 Apr 2000 13:25:43 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >:> There's another good reason to MFC the linux patch on wednesday... >:> that is, to do it at the same time the SMP cleanup is MFC'd, and that >:> is because both patch sets require the linux kernel module to be >:> recompiled and I'd rather not force people to do that twice. >:> >:> The SMP patchset, in fact, requires that all kernel modules be >:> recompiled due to the locks that were removed from the spl*() macros. I wonder if they really must be recompiled. It sounds like that would improve performance, but is seems like gratuitous locking in this area wouldn't necessarily cause things to break. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:31:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 897F137B66B for ; Sun, 23 Apr 2000 13:31:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64273; Sun, 23 Apr 2000 13:31:34 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 13:31:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200004232031.NAA64273@apollo.backplane.com> To: Richard Wackerbarth Cc: freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <200004232014.NAA64138@apollo.backplane.com> <00042315214900.24082@nomad.dataplex.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Sun, 23 Apr 2000, Matthew Dillon wrote: : :> :In that case I have a strong objection to the SMP patchset being :> :merged to 4.0. I have kernel modules in object format only that :> :are working now, which this would break :-(. :> : :> :Rod Grimes - KD7CAX @ CN85sl - (RWG25) :> : rgrimes@gndrsh.dnsmgr.net :> :> This is a legitimate topic for discussion. :> :> In general I agree with the concept but I think .0 releases have to :> have a bit more flexibility, and that 4.0 in particular (due to the :> rules change made for the BSDI merger) has to be even more flexible. :> We should be allowed to break kernel module loader compatibility :> in between a .0 and a .1 release if it is deemed necessary, but that :> it should be avoided (as much as possible) after the .1 release. : :Rather than break the FreeBSD4 modules over which you have no control, :perhaps your arguments should be used to accelerate the 5.0 release :and make 4.x a short lived branch. I don't think this is possible. 4.0 is the most stable release we've ever had, and I am confident that the 4.x series of releases will be the best in FreeBSD's history probably until 5.1 or 5.2. 5.x is going to be seriously torn up. Maybe not as bad as people thought, but still seriously torn up. It's already being torn up. I don't think there is any chance of making 4.x a short-lived branch nor do I think we want to. We should bask in the light of finallly having a good stable, high performance set of 4.x releases. What we have is a war between the customer's need for stability, other customer's need for speed, and the realities that developers face in not wanting to have to rewrite patches in order to MFC them, and wanting to have the opportunity to MFC improvements and bug fixes in the first place. The SMP patch falls somewhere in the middle, and I am aiming it towards the MFC side to make #3 easier. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:35: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id EA44537BA6E; Sun, 23 Apr 2000 13:34:55 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64288; Sun, 23 Apr 2000 13:34:53 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 13:34:53 -0700 (PDT) From: Matthew Dillon Message-Id: <200004232034.NAA64288@apollo.backplane.com> To: David Greenman Cc: "Rodney W. Grimes" , phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <200004232025.NAA06779@implode.root.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :>:> There's another good reason to MFC the linux patch on wednesday... :>:> that is, to do it at the same time the SMP cleanup is MFC'd, and that :>:> is because both patch sets require the linux kernel module to be :>:> recompiled and I'd rather not force people to do that twice. :>:> :>:> The SMP patchset, in fact, requires that all kernel modules be :>:> recompiled due to the locks that were removed from the spl*() macros. : : I wonder if they really must be recompiled. It sounds like that would :improve performance, but is seems like gratuitous locking in this area :wouldn't necessarily cause things to break. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org The cpl, cml, and interrupt lock variables and initialization of such is gone, Kapoof. And the semantics have changed for a few things as well. I haven't actually tested it to see if old modules still load and operate properly because doing the testing properly would take more time then I have to spend. If a KLD doesn't use spl*() calls at all it may be ok. I think we should resign ourselves to recompiling the KLD's, though. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:38:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 3653237BA61; Sun, 23 Apr 2000 13:38:24 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA10804; Sun, 23 Apr 2000 13:39:20 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Matthew Dillon Cc: Poul-Henning Kamp , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: To MFC or not to MFC, that is the question. In-reply-to: Your message of "Sun, 23 Apr 2000 12:30:19 PDT." <200004231930.MAA63599@apollo.backplane.com> Date: Sun, 23 Apr 2000 13:39:20 -0700 Message-ID: <10801.956522360@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Really, then you have a short memory. Why don't we ask Jordan for a > clarification. How about if you let me review the patches in question and I'll render a decision. If you, Matt, could put the SMP and linux stuff into -current first and then give me a day or so to check it out, I'll submit my own opinion on whether or not this is "immediate MFC" material. That covers the operational side of the discussion, and on the procedural side I unfortunately see a lot of arguing about "our policy" for things like this in spite of the fact that there has never really been an absolutely clear-cut mandate about when/where things should be MFC'd. It's a more complex mesh of judgement calls revolving around: o Whether the change is absolutely mandated by security criteria or just-plain-brokenness in -stble. o Whether the change is cosmetic or otherwise minor enough that there's no reason not to Just Do It right away. o How close we are to an impending release in the -stable branch in question. As has been stated frequently in the past, the release engineer would prefer for big changes in -stable to come along early in the game for maximum testing time rather than the day before code freeze starts. Determining where one sits with respect to all three of these merge-justification criteria comes down to a judgement call in each case, not some precise committer's checklist. I also personally don't mind that too much since no checklist can be written to cover all cases or codify the full range of "good judgement", so it ultimately comes down to personal opinion. I see two very big differences of personal opinion on this one and am willing to arbitrate between the two. In the longer-term, this kind of thing should be handled by the architecture group or the conflict-resolution committee depending on whether it's an architectural dispute or a simple clash between personalities or styles. In this case, I'd say it was a job for the CRC if we currently had one. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:42:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 722B337B9B9 for ; Sun, 23 Apr 2000 13:42:14 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Sun, 23 Apr 2000 15:42:03 -0500 From: Richard Wackerbarth To: Matthew Dillon Subject: Re: SMP changes and breaking kld object module compatibility Date: Sun, 23 Apr 2000 15:42:03 -0500 X-Mailer: KMail [version 1.1.40] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042315214900.24082@nomad.dataplex.net> <200004232031.NAA64273@apollo.backplane.com> In-Reply-To: <200004232031.NAA64273@apollo.backplane.com> MIME-Version: 1.0 Message-Id: <00042315420301.24082@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Matthew Dillon wrote: > > :Rather than break the FreeBSD4 modules over which you have no control, > :perhaps your arguments should be used to accelerate the 5.0 release > :and make 4.x a short lived branch. > > I don't think this is possible. 4.0 is the most stable release we've > ever had, and I am confident that the 4.x series of releases will be > the best in FreeBSD's history probably until 5.1 or 5.2. It's all in the name. I don't disagree with your assesment of the code bases. However, I consider your SMP changes VERY destablizing; they BREAK lots of modules :-( I'm sure that we will get over it and have something that settles into a quite solid product. However, we COULD branch FreeBSD5 off of the FreeBSD4 branch rather than the head and call the head branch something else which would get released as FreeBSD6 or FreeBSD 2000 or ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 13:51: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 76F7B37BA6B; Sun, 23 Apr 2000 13:51:01 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA10875; Sun, 23 Apr 2000 13:52:03 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Matthew Dillon Cc: "Rodney W. Grimes" , phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-reply-to: Your message of "Sun, 23 Apr 2000 13:14:21 PDT." <200004232014.NAA64138@apollo.backplane.com> Date: Sun, 23 Apr 2000 13:52:02 -0700 Message-ID: <10872.956523122@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In general I agree with the concept but I think .0 releases have to > have a bit more flexibility, and that 4.0 in particular (due to the > rules change made for the BSDI merger) has to be even more flexible. And this is something I can render an opinion on right away: I disagree. I want it treated as a full -stable branch, not some weaker derivative, and I don't think we'll win [m]any friends in the new-4.0 convert camp if we try to shake things up there, even with it in .0 status and the BSDi situation. The reasoning is quite simple: 4.0 turned out to have, in certain production environments, far less stability problems than 3.4 and that is partially Matt's fault for fixing things like NFS. :-) That in turn led to a lot more early-adoption of 4.0 than expected, and now 4.0 is being treated (and is behaving) like a full-blown -stable release with lots of good reasons to switch to it. The whole dot-zero conservativeness thing was our traditional attempt to put a happy face on situations that sucked (a .0 release being frail and buggy) rather than having that be an actual goal. Now that we've finally managed to shake off the .0 curse in many respects, I'm firmly behind the concept of treating it like any other release. I'm sure that something can be done for the kld compatibility issues so that you can have your SMP cake and eat it too. Just give it a bit more thought. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 14:20:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from pyros.yi.org (dialin26.mediawizards.net [209.63.39.26]) by hub.freebsd.org (Postfix) with ESMTP id 58A0A37BA6A; Sun, 23 Apr 2000 14:20:45 -0700 (PDT) (envelope-from mmuir@es.co.nz) Received: from es.co.nz (pyros.lan [192.168.100.1]) by pyros.lan (Postfix) with ESMTP id 758C78E1; Sun, 23 Apr 2000 14:01:55 -0700 (PDT) Message-ID: <390364C3.242B5F7C@es.co.nz> Date: Sun, 23 Apr 2000 21:01:55 +0000 From: Mike Muir Reply-To: mmuir@es.co.nz X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: Matthew Dillon , Poul-Henning Kamp , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: To MFC or not to MFC, that is the question. References: <10801.956522360@zippy.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Good greif that last one failed to go to stable@ or current@.. time to fix mail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 14:20:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from pyros.yi.org (dialin26.mediawizards.net [209.63.39.26]) by hub.freebsd.org (Postfix) with ESMTP id 569CE37BA68; Sun, 23 Apr 2000 14:20:44 -0700 (PDT) (envelope-from mmuir@es.co.nz) Received: from es.co.nz (pyros.lan [192.168.100.1]) by pyros.lan (Postfix) with ESMTP id 4B22D8DC; Sun, 23 Apr 2000 13:58:46 -0700 (PDT) Message-ID: <39036406.A256278@es.co.nz> Date: Sun, 23 Apr 2000 20:58:46 +0000 From: Mike Muir Reply-To: mmuir@es.co.nz X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: Matthew Dillon , Poul-Henning Kamp , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: To MFC or not to MFC, that is the question. References: <10801.956522360@zippy.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > > Really, then you have a short memory. Why don't we ask Jordan for a > > clarification. > > How about if you let me review the patches in question and I'll render > a decision. > > If you, Matt, could put the SMP and linux stuff into -current first > and then give me a day or so to check it out, I'll submit my own > opinion on whether or not this is "immediate MFC" material. > > That covers the operational side of the discussion, and on the > procedural side I unfortunately see a lot of arguing about "our > policy" for things like this in spite of the fact that there has never > really been an absolutely clear-cut mandate about when/where things > should be MFC'd. It's a more complex mesh of judgement calls > revolving around: > > o Whether the change is absolutely mandated by security criteria > or just-plain-brokenness in -stble. > > o Whether the change is cosmetic or otherwise minor enough that > there's no reason not to Just Do It right away. > > o How close we are to an impending release in the -stable branch > in question. As has been stated frequently in the past, the > release engineer would prefer for big changes in -stable to come > along early in the game for maximum testing time rather than > the day before code freeze starts. > > Determining where one sits with respect to all three of these > merge-justification criteria comes down to a judgement call in each > case, not some precise committer's checklist. I also personally don't > mind that too much since no checklist can be written to cover all > cases or codify the full range of "good judgement", so it ultimately > comes down to personal opinion. I see two very big differences of > personal opinion on this one and am willing to arbitrate between the > two. > > In the longer-term, this kind of thing should be handled by the > architecture group or the conflict-resolution committee depending on > whether it's an architectural dispute or a simple clash between > personalities or styles. In this case, I'd say it was a job for the > CRC if we currently had one. :) I'll be your CRC and say stop yer bickering and discuss this like adults (assuming you both are infact classed as such) which means no cheap shot insults (im sure you both have great memories and excusing that would be your workloads which im sure are right up there) and getting over whatever personal differences either party might have. ok good! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 14:34:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 0D3F737BA5D; Sun, 23 Apr 2000 14:34:18 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id OAA46448; Sun, 23 Apr 2000 14:34:17 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 23 Apr 2000 14:34:17 -0700 (PDT) From: Kris Kennaway To: Leif Neland Cc: Christoph Kukulies , Bill Fumerola , freebsd-current@FreeBSD.ORG Subject: Re: Stale modules (Re: panic in the morning) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Leif Neland wrote: > > make world doesn't build a kernel. Making a kernel doesn't build > > modules. This bit me again the other day when updating, as well - panic at > > boot when loading a stale linux.ko. > > > If making world _and_ kernel doesn't build modules, what _then_? Making them both together. Making world _does_ build modules as I said above, you'll just run into problems if you, say, make your kernel after cvsupping 3 days later. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 14:36:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 7BEB137B549; Sun, 23 Apr 2000 14:36:13 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id OAA46603; Sun, 23 Apr 2000 14:36:13 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 23 Apr 2000 14:36:12 -0700 (PDT) From: Kris Kennaway To: Donn Miller Cc: freebsd-current@FreeBSD.ORG Subject: Re: Stale modules (Re: panic in the morning) In-Reply-To: <3902B1EB.A9E00EAB@cvzoom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Donn Miller wrote: > Which mailing list would be appropriate for discussing kernel modules, > etc.? freebsd-arch. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 15:10:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from pyros.yi.org (dialin26.mediawizards.net [209.63.39.26]) by hub.freebsd.org (Postfix) with ESMTP id D73FD37BA6A; Sun, 23 Apr 2000 15:10:44 -0700 (PDT) (envelope-from mmuir@es.co.nz) Received: from es.co.nz (rock.bsdonline.org [192.168.100.1]) by rock.bsdonline.org (Postfix) with ESMTP id 63D3D8D4; Sun, 23 Apr 2000 12:59:37 -0700 (PDT) Message-ID: <39035629.BC369DD4@es.co.nz> Date: Sun, 23 Apr 2000 19:59:37 +0000 From: Mike Muir Reply-To: mmuir@es.co.nz X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Poul-Henning Kamp , Matthew Dillon , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <200004231922.MAA63538@apollo.backplane.com> <45851.956517875@critter.freebsd.dk> <200004231947.NAA08296@nomad.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > I was under the impression that 4.x hasn't been designated as the stable > branch (yet). That will happen when 4.1 is released, but until that > happens 3.x is still considered the -stable release. That would kinda make sense since cvsuping with tag=RELENG_3 seems to give me FreeBSD 4.0-STABLE (#0: Sat Apr 22 20:59:03 PDT 2000).. But besides that, this whole back and forth dont-do-this-do-that charade is going to get pretty juvenile soon.. I mean we're (matt) already at bad memory insults heh so how bout you both kiss/reevaluate and make up before it gets so bad you try to keep away from each other next time you're both at one of these conventions or whatever.. hmm now theres an uncomfortable situation to be in for both sides. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 15:37: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from pyros.yi.org (dialin29.mediawizards.net [209.63.39.29]) by hub.freebsd.org (Postfix) with ESMTP id E720B37B8EF; Sun, 23 Apr 2000 15:36:55 -0700 (PDT) (envelope-from mmuir@es.co.nz) Received: from es.co.nz (pyros.lan [192.168.100.1]) by pyros.yi.org (Postfix) with ESMTP id C6A183B; Sun, 23 Apr 2000 15:37:26 -0700 (PDT) Message-ID: <39037B26.33C1B62F@es.co.nz> Date: Sun, 23 Apr 2000 22:37:26 +0000 From: Mike Muir Reply-To: mmuir@es.co.nz X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams , Poul-Henning Kamp , Matthew Dillon , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday References: <200004231922.MAA63538@apollo.backplane.com> <45851.956517875@critter.freebsd.dk> <200004231947.NAA08296@nomad.yogotech.com> <39035629.BC369DD4@es.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Muir wrote: > > Nate Williams wrote: > > > I was under the impression that 4.x hasn't been designated as the stable > > branch (yet). That will happen when 4.1 is released, but until that > > happens 3.x is still considered the -stable release. > > That would kinda make sense since cvsuping with tag=RELENG_3 seems to > give me FreeBSD 4.0-STABLE (#0: Sat Apr 22 20:59:03 PDT 2000).. Ok wait im a moron.. been using the stable-supfile instead of the 4.x-stable-supfile.. hmmmmm. mike. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 15:45:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id 497F937B866 for ; Sun, 23 Apr 2000 15:45:14 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (05-065.dial.008.popsite.net [209.69.13.65]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id PAA71817 for ; Sun, 23 Apr 2000 15:45:11 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id DA5A71939; Sun, 23 Apr 2000 18:44:51 -0400 (EDT) Date: Sun, 23 Apr 2000 18:44:51 -0400 From: Will Andrews To: FreeBSD Current Subject: buildworld breakage (netstat/route.c rev 1.43) Message-ID: <20000423184451.U6549@argon.blackdawn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Buildworld on 5.0-CURRENT is breaking here: ===> usr.bin/netstat cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/if.c cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/inet.c cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/inet6.c cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/main.c cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/mbuf.c cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/mroute.c cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/ipx.c cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/route.c /usr/src/usr.bin/netstat/route.c: In function `p_tree': /usr/src/usr.bin/netstat/route.c:284: structure has no member named `rn_b' /usr/src/usr.bin/netstat/route.c:308: structure has no member named `rn_r' /usr/src/usr.bin/netstat/route.c:309: structure has no member named `rn_l' /usr/src/usr.bin/netstat/route.c: In function `p_rtnode': /usr/src/usr.bin/netstat/route.c:321: structure has no member named `rn_b' /usr/src/usr.bin/netstat/route.c:329: structure has no member named `rn_b' /usr/src/usr.bin/netstat/route.c:330: structure has no member named `rn_l' /usr/src/usr.bin/netstat/route.c:330: structure has no member named `rn_r' /usr/src/usr.bin/netstat/route.c:336: structure has no member named `rm_b' [1] + exit 1 make buildworld 2>& 1 | done tee > build.log *** Error code 1 Stop in /usr/src/usr.bin/netstat. *** Error code 1 If Mark or Garrett could fix this ASAP that would be nice. :) -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 15:56:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 8B73137BADD for ; Sun, 23 Apr 2000 15:56:25 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA15133; Sun, 23 Apr 2000 23:55:40 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA00598; Sun, 23 Apr 2000 21:56:13 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200004232056.VAA00598@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: Brian Somers , Dirk Roehrdanz , current@freebsd.org Subject: Re: MAKEDEV warning In-Reply-To: Message from Poul-Henning Kamp of "Sat, 22 Apr 2000 11:42:01 +0200." <38167.956396521@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Apr 2000 21:56:13 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yep, that's the ticket ! Thanks. > Yes, that was an oversight on my part. Please let me know if the > fix I committed solves this issue. > > Poul-Henning > > In message <200004220939.KAA50419@hak.lan.Awfulhak.org>, Brian Somers writes: > >I've got an mfs /tmp too :-] > > > >> Hi, > >> > >> On 0, Ted Sikora wrote: > >> > After building a new kernel yesterday after a cvsup the following > >> > appeared. > >> > > >> > Apr 17 23:07:42 telecast /kernel: WARNING: run /dev/MAKEDEV before > >> > 2000-06-01 to get rid of block devices > >> > I did a MAKEDEV all and the message still persists. > >> > > >> > >> I get this message too whenever I mount a mfs filesystem. > >> The line in /etc/fstab is: > >> /dev/da0s1b /tmp mfs rw,async,-s32768 0 0 > >> > >> The output of "ls -l /dev/*da0s1b" is: > >> crw-r----- 1 root operator 13, 0x00020001 Dec 12 21:09 /dev/da0s1b > >> crw-r----- 1 root operator 13, 0x00020001 Dec 12 21:09 /dev/rda0s1b > >> > >> Regards > >> Dirk [.....] > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 17:37:53 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id D80AC37B7A5; Sun, 23 Apr 2000 17:37:50 -0700 (PDT) From: "Jonathan M. Bresler" To: msmith@freebsd.org Cc: dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-reply-to: <200004232030.NAA51633@mass.cdrom.com> (message from Mike Smith on Sun, 23 Apr 2000 13:30:39 -0700) Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday Message-Id: <20000424003750.D80AC37B7A5@hub.freebsd.org> Date: Sun, 23 Apr 2000 17:37:50 -0700 (PDT) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > BTW; whilst I think Poul was entirely the wrong person to raise the > issue, I agree that you probably want to hang back on MFCing the linux > scripting changes for a week or so. This is really just common sense. > recently i added autoload to a usb related kernel module. very handy to have....just like with ifconfing autoloading ethernet drivers. i did an immediate MFC. i was WRONG. i should not have done that. even though it does strike me as an obivious win to have the autoload. lets let every change sit in -current for a little while before the MFC occurs. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 17:43:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from assaris.sics.se (dyna225-140.nada.kth.se [130.237.225.140]) by hub.freebsd.org (Postfix) with ESMTP id 2D6D137BA29 for ; Sun, 23 Apr 2000 17:43:29 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id CAA06333; Mon, 24 Apr 2000 02:43:29 +0200 (CEST) (envelope-from assar) To: Matthew Dillon Cc: Bruce Evans , attila , freebsd-current@FreeBSD.ORG Subject: Re: __func__ not declared for kernel build (5.0-CURRENT) References: <200004231730.KAA62311@apollo.backplane.com> From: Assar Westerlund Date: 24 Apr 2000 02:43:28 +0200 In-Reply-To: Matthew Dillon's message of "Sun, 23 Apr 2000 10:30:20 -0700 (PDT)" Message-ID: <5lsnwcqqfj.fsf@assaris.sics.se> Lines: 14 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > obviously missing __FUNCTION__ was added by GCC many years ago, but it was > a while before it's use in defines in header (.h) files was dealt with > properly. You mean outside a function? What's the proper way of dealing with that? > I wish these stupid standards committees would just choose > something that people are already using rather then make up new names! The problem is that __func__ and __FUNCTION__ are not the same thing. And thus it makes sense for them not the use same name. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 17:44:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id A779737B55B for ; Sun, 23 Apr 2000 17:44:19 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (05-065.dial.008.popsite.net [209.69.13.65]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id RAA73354; Sun, 23 Apr 2000 17:44:18 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id B81FA1939; Sun, 23 Apr 2000 20:44:03 -0400 (EDT) Date: Sun, 23 Apr 2000 20:44:03 -0400 From: Will Andrews To: Will Andrews Cc: FreeBSD Current Subject: Re: buildworld breakage (netstat/route.c rev 1.43) Message-ID: <20000423204403.D6549@argon.blackdawn.com> References: <20000423184451.U6549@argon.blackdawn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000423184451.U6549@argon.blackdawn.com>; from andrews@TECHNOLOGIST.COM on Sun, Apr 23, 2000 at 06:44:51PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 23, 2000 at 06:44:51PM -0400, Will Andrews wrote: > If Mark or Garrett could fix this ASAP that would be nice. :) Never mind, this was an oversight on my part. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 18: 7:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from matrix.buckhorn.net (matrix.buckhorn.net [208.129.165.68]) by hub.freebsd.org (Postfix) with ESMTP id 1FB9637B88B for ; Sun, 23 Apr 2000 18:07:25 -0700 (PDT) (envelope-from bob@buckhorn.net) Received: from buckhorn.net (nebula.buckhorn.net [208.129.165.66]) by matrix.buckhorn.net (8.9.3/8.9.3) with ESMTP id UAA05528 for ; Sun, 23 Apr 2000 20:06:06 -0500 (CDT) (envelope-from bob@buckhorn.net) Message-ID: <39039E47.EC98F4A4@buckhorn.net> Date: Sun, 23 Apr 2000 20:07:19 -0500 From: Bob Martin X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: PCM and Midi. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know when PCM will support midi? Thanks! Bob -- "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 20:22: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [149.173.1.1]) by hub.freebsd.org (Postfix) with ESMTP id 5A8CF37B568; Sun, 23 Apr 2000 20:22:02 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [149.173.6.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id XAA01410; Sun, 23 Apr 2000 23:21:26 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA16431; Sun, 23 Apr 2000 23:20:46 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.3/8.9.1) id XAA85409; Sun, 23 Apr 2000 23:20:46 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <200004240320.XAA85409@bb01f39.unx.sas.com> Subject: csh/nls problem causing make release failure To: freebsd-current@freebsd.org Date: Sun, 23 Apr 2000 23:20:46 -0400 (EDT) Cc: ache@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, As Poul-Henning has pointed out, make release is broken... ===> bin/csh/nls ===> bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /snap/release/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat install: /snap/release/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat: No such file or directory *** Error code 71 In looking at /usr/src/bin/csh/nls/finnish/Makefile, the install rule appears to have a problem: install: ${INSTALL} ${COPY} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ tcsh.cat ${DESTDIR}/..${NLSDIR}/${DL}/tcsh.cat At the beginning of a make release, the following is executed (I believe this is the failing component): cd ${.CURDIR}/.. && ${MAKE} installworld DESTDIR=${CHROOTDIR} NOMAN=1 where CHROOTDIR is /snap/release in my case thus making DESTDIR the same (/snap/release), and /syv/release in Poul-Henning's. I don't know enough about the nls issues to correctly fix this problem, however, it is apparent that the install rule above is wrong since "/snap/usr/share/..." does not exist and probably shouldn't during a "make release". Could the appropriate folks please take a look at this? I'll be more than happy to test any patchs. Thanks, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 20:35:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailhop1.nyroc.rr.com (mailhop1-1.nyroc.rr.com [24.92.226.166]) by hub.freebsd.org (Postfix) with ESMTP id 7248437BAC3 for ; Sun, 23 Apr 2000 20:35:27 -0700 (PDT) (envelope-from leisner@rochester.rr.com) Received: from mailout1.nyroc.rr.com ([24.92.226.81]) by mailhop1.nyroc.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-59787U250000L250000S0V35) with ESMTP id com; Sun, 23 Apr 2000 23:32:09 -0400 Received: from mail2.nyroc.rr.com ([24.92.226.75]) by mailout1.nyroc.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-59787U250000L250000S0V35) with ESMTP id com; Sun, 23 Apr 2000 23:35:13 -0400 Received: from rochester.rr.com ([24.93.17.24]) by mail2.nyroc.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-53939U80000L80000S0V35) with ESMTP id com; Sun, 23 Apr 2000 23:35:13 -0400 Received: from soyata.home (IDENT:leisner@localhost [127.0.0.1]) by rochester.rr.com (8.9.3/8.8.5) with ESMTP id XAA06306; Sun, 23 Apr 2000 23:35:20 -0400 Message-Id: <200004240335.XAA06306@rochester.rr.com> X-Mailer: exmh version 2.1.0 09/18/1999 Reply-To: leisner@rochester.rr.com To: Assar Westerlund Cc: Matthew Dillon , Bruce Evans , attila , freebsd-current@FreeBSD.ORG, leisner@rochester.rr.com Subject: Re: __func__ not declared for kernel build (5.0-CURRENT) In-reply-to: Your message of "24 Apr 2000 02:43:28 +0200." <5lsnwcqqfj.fsf@assaris.sics.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Apr 2000 23:35:20 -0400 From: "Marty Leisner" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Assar Westerlund writes on 24 Apr 2000 02:43:28 +0200 > Matthew Dillon writes: > > obviously missing __FUNCTION__ was added by GCC many years ago, but it was > > a while before it's use in defines in header (.h) files was dealt with > > properly. > > You mean outside a function? What's the proper way of dealing with that? > > > I wish these stupid standards committees would just choose > > something that people are already using rather then make up new names! > > The problem is that __func__ and __FUNCTION__ are not the same thing. > And thus it makes sense for them not the use same name. > What's different about them? __func__ was defined in aztec C nearly two decades ago...I really looked the appearance of a __func__ pseudomacro -- it made lots of stuff much easier to understand (as opposed to __FILE__/__LINE__) -- but __func__ had to be handled by the translater, not the preprocessor... > /assar > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 21:36:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.forumone.com (orion.forumone.com [207.197.141.10]) by hub.freebsd.org (Postfix) with ESMTP id BF41437B9F9 for ; Sun, 23 Apr 2000 21:36:46 -0700 (PDT) (envelope-from adhir@forumone.com) Received: from orion.forumone.com (orion.forumone.com [207.197.141.10]) by mail.forumone.com (Postfix) with ESMTP id 3D518A904; Mon, 24 Apr 2000 00:36:45 -0400 (EDT) Date: Mon, 24 Apr 2000 00:36:45 -0400 (EDT) From: "Alok K. Dhir" To: Matthew Dillon Cc: freebsd-current@freebsd.org Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <200004232031.NAA64273@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Totally off topic question that I've wondered for some time now - what does MFC stand for? Thanks for humoring my ignorance, and thanks for all your hard work on FreeBSD... :) On Sun, 23 Apr 2000, Matthew Dillon wrote: > Date: Sun, 23 Apr 2000 13:31:34 -0700 (PDT) > From: Matthew Dillon > To: Richard Wackerbarth > Cc: freebsd-current@FreeBSD.ORG > Subject: Re: SMP changes and breaking kld object module compatibility > > > : > :On Sun, 23 Apr 2000, Matthew Dillon wrote: > : > :> :In that case I have a strong objection to the SMP patchset being > :> :merged to 4.0. I have kernel modules in object format only that > :> :are working now, which this would break :-(. > :> : > :> :Rod Grimes - KD7CAX @ CN85sl - (RWG25) > :> : rgrimes@gndrsh.dnsmgr.net > :> > :> This is a legitimate topic for discussion. > :> > :> In general I agree with the concept but I think .0 releases have to > :> have a bit more flexibility, and that 4.0 in particular (due to the > :> rules change made for the BSDI merger) has to be even more flexible. > :> We should be allowed to break kernel module loader compatibility > :> in between a .0 and a .1 release if it is deemed necessary, but that > :> it should be avoided (as much as possible) after the .1 release. > : > :Rather than break the FreeBSD4 modules over which you have no control, > :perhaps your arguments should be used to accelerate the 5.0 release > :and make 4.x a short lived branch. > > I don't think this is possible. 4.0 is the most stable release we've > ever had, and I am confident that the 4.x series of releases will be > the best in FreeBSD's history probably until 5.1 or 5.2. > > 5.x is going to be seriously torn up. Maybe not as bad as people thought, > but still seriously torn up. It's already being torn up. I don't think > there is any chance of making 4.x a short-lived branch nor do I think > we want to. We should bask in the light of finallly having a good stable, > high performance set of 4.x releases. > > What we have is a war between the customer's need for stability, > other customer's need for speed, and the realities that developers > face in not wanting to have to rewrite patches in order to MFC them, > and wanting to have the opportunity to MFC improvements and bug fixes > in the first place. The SMP patch falls somewhere in the middle, and > I am aiming it towards the MFC side to make #3 easier. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 21:55:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id 7903537B505 for ; Sun, 23 Apr 2000 21:55:34 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (05-065.dial.008.popsite.net [209.69.13.65]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id VAA78590; Sun, 23 Apr 2000 21:55:13 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id BA7871939; Mon, 24 Apr 2000 00:54:58 -0400 (EDT) Date: Mon, 24 Apr 2000 00:54:58 -0400 From: Will Andrews To: "Alok K. Dhir" Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000424005458.A90431@argon.blackdawn.com> References: <200004232031.NAA64273@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from adhir@forumone.com on Mon, Apr 24, 2000 at 12:36:45AM -0400 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 12:36:45AM -0400, Alok K. Dhir wrote: > Totally off topic question that I've wondered for some time now - what > does MFC stand for? Merge From CURRENT. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 21:56:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 9420B37B8F7 for ; Sun, 23 Apr 2000 21:56:53 -0700 (PDT) (envelope-from bandix@looksharp.net) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id AAA20805; Mon, 24 Apr 2000 00:57:03 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Mon, 24 Apr 2000 00:57:02 -0400 (EDT) From: "Brandon D. Valentine" To: "Alok K. Dhir" Cc: freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Alok K. Dhir wrote: > >Totally off topic question that I've wondered for some time now - what >does MFC stand for? According to the FAQ section located on the web @ http://www.freebsd.org/FAQ/misc.html#AEN3908 Q: What does 'MFC' mean? A: MFC is an acronym for 'Merged From -CURRENT.' It's used in the CVS logs to denote when a change was migrated from the CURRENT to the STABLE branches. A quick search for MFC right from the freebsd.org main page would have returned this information. Brandon D. Valentine -- bandix@looksharp.net Illegitimi non carborundum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 22:51:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3F9B037BAC6 for ; Sun, 23 Apr 2000 22:51:13 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA66095; Sun, 23 Apr 2000 22:51:08 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 22:51:08 -0700 (PDT) From: Matthew Dillon Message-Id: <200004240551.WAA66095@apollo.backplane.com> To: Assar Westerlund Cc: Bruce Evans , attila , freebsd-current@FreeBSD.ORG Subject: Re: __func__ not declared for kernel build (5.0-CURRENT) References: <200004231730.KAA62311@apollo.backplane.com> <5lsnwcqqfj.fsf@assaris.sics.se> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Matthew Dillon writes: :> obviously missing __FUNCTION__ was added by GCC many years ago, but it was :> a while before it's use in defines in header (.h) files was dealt with :> properly. : :You mean outside a function? What's the proper way of dealing with that? : :> I wish these stupid standards committees would just choose :> something that people are already using rather then make up new names! : :The problem is that __func__ and __FUNCTION__ are not the same thing. :And thus it makes sense for them not the use same name. : :/assar __FUNCTION__ represents the name of the C procedure you are currently in, same as __func__ as far as I can tell. You can define macros that use __FUNCTION__ in header files and then use them in the C code. This works just fine, as of around 6 years ago (before then __FUNCTION__ in gnu C did not properly resolve when used in a macro in a header file). I use __FUNCTION__ all the time to implement ASSERT() macros. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 23: 3:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 10ADE37B747; Sun, 23 Apr 2000 23:03:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA66185; Sun, 23 Apr 2000 23:03:14 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 23:03:14 -0700 (PDT) From: Matthew Dillon Message-Id: <200004240603.XAA66185@apollo.backplane.com> To: "Jordan K. Hubbard" Cc: Poul-Henning Kamp , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: To MFC or not to MFC, that is the question. References: <10801.956522360@zippy.cdrom.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> Really, then you have a short memory. Why don't we ask Jordan for a :> clarification. : :How about if you let me review the patches in question and I'll render :a decision. : :If you, Matt, could put the SMP and linux stuff into -current first :and then give me a day or so to check it out, I'll submit my own :opinion on whether or not this is "immediate MFC" material. The linux patch is the only patch under discussion here in regards to the simultanious commit/MFC issue. The SMP work was committed to current almost a month ago so MFC'ing it now is not really an issue. (besides, if you remember our conversation back then both of us actually did all of our testing of the SMP patch under 4.x rather then 5.x). The linux scripting patch is available, as I already posted, at: http://www.backplane.com/FreeBSD4/ While it has not been committed to -current or -stable yet, it has been up for review for a while (3 weeks) and I have tested extensively while installing oracle and java under linux emulation. And it only effects linux emulation so it isn't as though MFC'ing it will suddenly break FreeBSD even under the worst possible assumptions. As DG said, the linux scripting patch is simply not this big a deal... I don't know what Poul is barking at. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 23: 5: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CB8E237B9BD for ; Sun, 23 Apr 2000 23:05:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA66216; Sun, 23 Apr 2000 23:05:02 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 23:05:02 -0700 (PDT) From: Matthew Dillon Message-Id: <200004240605.XAA66216@apollo.backplane.com> To: Richard Wackerbarth Cc: freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042315214900.24082@nomad.dataplex.net> <200004232031.NAA64273@apollo.backplane.com> <00042315420301.24082@nomad.dataplex.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Sun, 23 Apr 2000, Matthew Dillon wrote: :> :> :Rather than break the FreeBSD4 modules over which you have no control, :> :perhaps your arguments should be used to accelerate the 5.0 release :> :and make 4.x a short lived branch. :> :> I don't think this is possible. 4.0 is the most stable release we've :> ever had, and I am confident that the 4.x series of releases will be :> the best in FreeBSD's history probably until 5.1 or 5.2. : :It's all in the name. I don't disagree with your assesment of the code bases. :However, I consider your SMP changes VERY destablizing; they BREAK :lots of modules :-( Huh? No they don't. They simply require recompiling the modules. If they actually broke the modules I wouldn't be trying to MFC it to -stable. :... :I'm sure that we will get over it and have something that settles into a :quite solid product. : :... :(Richard Wackerbarth ) -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 23:18: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E79D437B9D7; Sun, 23 Apr 2000 23:17:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA66270; Sun, 23 Apr 2000 23:17:51 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 23:17:51 -0700 (PDT) From: Matthew Dillon Message-Id: <200004240617.XAA66270@apollo.backplane.com> To: "Jordan K. Hubbard" Cc: "Rodney W. Grimes" , phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <10872.956523122@zippy.cdrom.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'm sure that something can be done for the kld compatibility issues :so that you can have your SMP cake and eat it too. Just give it a bit :more thought. :) : :- Jordan Thought I have. Time I don't. While I don't particularly see a problem staying compatible with KLD modules that do spl*() calls, It's several day's worth of additional work when we go through the whole review / test / test-again process. I've already gone through this process for what was committed to -current and I have already tested the patches under 4.x. I do not have time to go through it yet again due to having to make additional difficult-to-test changes. If this is an issue I suppose core can vote on whether the SMP cleanup should be MFC'd to 4.x. I've already laid out all the reasons why I think it's a good idea to do. I don't have the 40 man-hours it will take to guarentee compatibility with existing kld's (even if most are probably already compatible) so if you make that a requirement, the result will be no MFC at all. So you guys (core) choose -- do you want 4.x to reap the benefits of further SMP development or not? If you choose no, beware that without this base cleanup there is *NO* chance whatsoever of any further SMP work being MFC'd to 4.x. None. Zilch. It will have diverged too much. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Apr 23 23:57:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id 1F07D37B5E3 for ; Sun, 23 Apr 2000 23:57:16 -0700 (PDT) (envelope-from shocking@prth.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id OAA04415 for ; Mon, 24 Apr 2000 14:54:58 +0800 (WST) Received: from bleep.craftncomp.com (dialin20 [157.147.225.220]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id OAA10000 for ; Mon, 24 Apr 2000 14:57:08 +0800 (WST) Received: from bloop.craftncomp.com (bloop.prth.tensor.pgs.com [202.12.111.1]) by bleep.craftncomp.com (8.9.3/8.9.3) with ESMTP id OAA02936 for ; Mon, 24 Apr 2000 14:56:38 +0800 (WST) (envelope-from shocking@prth.pgs.com) Received: from bloop.craftncomp.com (localhost [127.0.0.1]) by bloop.craftncomp.com (8.9.3/8.9.3) with ESMTP id OAA06520 for ; Mon, 24 Apr 2000 14:56:34 +0800 (WST) (envelope-from shocking@bloop.craftncomp.com) Message-Id: <200004240656.OAA06520@bloop.craftncomp.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: current@freebsd.org Subject: Joystick has stopped working Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Apr 2000 14:56:33 +0800 From: Stephen Hocking Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For sometime now, the analogue joy stick driver hasn't been working - it seems to persistently return totally wild deviations when being read. Also, trying to use it as a kld doersn't seem to work. Has anyone else had similar probs? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 1:18:43 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 542) id BA34637B900; Mon, 24 Apr 2000 01:18:41 -0700 (PDT) Date: Mon, 24 Apr 2000 01:18:41 -0700 From: "Andrey A. Chernov" To: "John W. DeBoskey" Cc: freebsd-current@freebsd.org Subject: Re: csh/nls problem causing make release failure Message-ID: <20000424011841.A67114@freebsd.org> References: <200004240320.XAA85409@bb01f39.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <200004240320.XAA85409@bb01f39.unx.sas.com>; from jwd@unx.sas.com on Sun, Apr 23, 2000 at 11:20:46PM -0400 Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 23, 2000 at 11:20:46PM -0400, John W. DeBoskey wrote: > As Poul-Henning has pointed out, make release is broken... No, he pointed to different problem, 'make distribute' > Could the appropriate folks please take a look at this? I'll be > more than happy to test any patchs. Try now, I just commit what is supposed to fix. -- Andrey A. Chernov http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 2:43:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 1D07637B8E5 for ; Mon, 24 Apr 2000 02:43:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id RAA03547 for ; Mon, 24 Apr 2000 17:43:14 +0800 Received: from jules.elischer.org (reggae-01-187.nv.iinet.net.au [203.59.62.187]) by popserver-02.iinet.net.au (8.9.3/8.9.3) with SMTP id RAA13864 for ; Mon, 24 Apr 2000 17:43:12 +0800 Message-ID: <39041698.15FB7483@elischer.org> Date: Mon, 24 Apr 2000 02:40:40 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: current@FREEBSD.ORG Subject: asm_pci.h,v Holy cow! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My cvsup appeared to be frozen, so I stopped it and looked.. src/sys/dev/isp/asm_pci.c,v is 13MB long! it was just taking a long time.. this seems a little excessive. anyone got any ideas. (13MB on a 40Kbit link is a long time) to make matters worse cvsup appears to be redownloading some very large percentage of this file whenerver there is a change to it. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 2:46: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 5CA0A37B649 for ; Mon, 24 Apr 2000 02:45:55 -0700 (PDT) (envelope-from mb@imp.ch) Received: from mephisto.imp.ch (mb@mephisto.imp.ch [157.161.1.22]) by mail.imp.ch (8.9.3/8.9.3b) with ESMTP id LAA19203; Mon, 24 Apr 2000 11:45:41 +0200 (CEST) Received: from localhost (mb@localhost) by mephisto.imp.ch (8.9.3/8.9.3) with ESMTP id LAA08944; Mon, 24 Apr 2000 11:45:38 +0200 (MES) Date: Mon, 24 Apr 2000 11:45:38 +0200 From: Martin Blapp To: freebsd-current@FreeBSD.ORG Cc: dillon@apollo.backplane.com Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Matt, I really like to see your fix committed to STABLE. It fixes also the bad designed Staroffice 5.2 installation for some part (/usr/sbin/test). Thank you for your work ! Martin Martin Blapp, mb@imp.ch ------------------------------------------------ Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 ------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 2:46:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 1F21B37B9D3 for ; Mon, 24 Apr 2000 02:46:54 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 04:46:44 -0500 From: Richard Wackerbarth To: Matthew Dillon Subject: Re: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 04:46:43 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042315420301.24082@nomad.dataplex.net> <200004240605.XAA66216@apollo.backplane.com> In-Reply-To: <200004240605.XAA66216@apollo.backplane.com> MIME-Version: 1.0 Message-Id: <00042404464300.09955@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Matthew Dillon wrote: > : However, I consider your SMP changes VERY destablizing; they BREAK > : lots of modules :-( > > Huh? No they don't. They simply require recompiling the modules. If > they actually broke the modules I wouldn't be trying to MFC it to > -stable. From the USER's perspective, anything that requires me to as much as reload a module/program that I have already installed "breaks" it. The fact that it is only necessary to recompile it in order to fix it only means that it is easy to fix IF I have the source code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 2:47:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from hun.org (hun.org [216.190.28.252]) by hub.freebsd.org (Postfix) with ESMTP id AD0C937B697 for ; Mon, 24 Apr 2000 02:47:34 -0700 (PDT) (envelope-from attila@hun.org) Received: (from attila@localhost) by hun.org (8.9.3/8.9.2) id JAA82083; Mon, 24 Apr 2000 09:47:31 GMT (envelope-from attila) Date: Mon, 24 Apr 2000 09:47:31 GMT Message-Id: <200004240947.JAA82083@hun.org> From: attila! Organization: hun.org, over 40 years beyond the fringe home for unpenitent hackers and anarcho-cryptophreaks Mailer: FreeBSD 5.0-current with XEmacs V20.4 (see alt.religion.emacs) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit; Content-Disposition: Inline To: freebsd-current@FreeBSD.org Cc: Bruce Evans , Matthew Dillon , Assar Westerlund Subject: Re: __func__ not declared for kernel build (5.0-CURRENT) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG but, in all this, the bottom line is that compilers, until recently, barfed on __func__. to compile the kernel, I substituted the function name in the printf statement... no big deal, but not what was intended, which I presume was to guarantee the correct function name, even if the function name was changed or the code lifted and reused in another function. after a few words in the programmers' universal language and a quick RTFS exercise, the hack was in... on with the show and the new kernel ran just fine and buildworld has done its thing. attila out... -- No, I don't suffer from insanity - I enjoy every minute of it. On Sun, 23 Apr 2000, Matthew Dillon wrote: > :Matthew Dillon writes: > :> obviously missing __FUNCTION__ was added by GCC many years ago, but it was > :> a while before it's use in defines in header (.h) files was dealt with > :> properly. > : > :You mean outside a function? What's the proper way of dealing with that? > : > :> I wish these stupid standards committees would just choose > :> something that people are already using rather then make up new names! > : > :The problem is that __func__ and __FUNCTION__ are not the same thing. > :And thus it makes sense for them not the use same name. > : > :/assar > > __FUNCTION__ represents the name of the C procedure you are currently > in, same as __func__ as far as I can tell. > > You can define macros that use __FUNCTION__ in header files and then > use them in the C code. This works just fine, as of around 6 years > ago (before then __FUNCTION__ in gnu C did not properly resolve when > used in a macro in a header file). > > I use __FUNCTION__ all the time to implement ASSERT() macros. > > -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 3:25:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id CFC5637B58A; Mon, 24 Apr 2000 03:25:33 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 12jg3Y-0002Zv-0X; Mon, 24 Apr 2000 11:25:32 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA04164; Mon, 24 Apr 2000 11:34:47 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 24 Apr 2000 11:30:58 +0100 (BST) From: Doug Rabson To: Matthew Dillon Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday In-Reply-To: <200004231855.LAA63309@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Matthew Dillon wrote: > There's another good reason to MFC the linux patch on wednesday... > that is, to do it at the same time the SMP cleanup is MFC'd, and that > is because both patch sets require the linux kernel module to be > recompiled and I'd rather not force people to do that twice. > > The SMP patchset, in fact, requires that all kernel modules be > recompiled due to the locks that were removed from the spl*() macros. > This is something I would contemplate doing for 4.0->4.1, but not > something I would consider for 4.1 onward. Even though 4.0 is the > most stable .0 release we've ever had, it's still a .0. > > I wonder if it makes sense to add a release id to the module header > and have the module loader refuse (unless forced) to load modules that > are out-of-date with the kernel? This sounds quite reasonable. Perhaps you should commit the linux patch to -current right now and then merge it on Wednesday. That would give plenty of time for any teething problems to show up. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 3:36:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id 790B737B79F; Mon, 24 Apr 2000 03:36:34 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 12jgEC-000Jnf-0K; Mon, 24 Apr 2000 10:36:32 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA04192; Mon, 24 Apr 2000 11:45:43 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 24 Apr 2000 11:41:53 +0100 (BST) From: Doug Rabson To: Matthew Dillon Cc: "Jordan K. Hubbard" , "Rodney W. Grimes" , Poul-Henning Kamp , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <200004240617.XAA66270@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Matthew Dillon wrote: > :I'm sure that something can be done for the kld compatibility issues > :so that you can have your SMP cake and eat it too. Just give it a bit > :more thought. :) > : > :- Jordan > > Thought I have. Time I don't. While I don't particularly see a > problem staying compatible with KLD modules that do spl*() calls, > It's several day's worth of additional work when we go through > the whole review / test / test-again process. I've already gone > through this process for what was committed to -current and I have > already tested the patches under 4.x. I do not have time to go > through it yet again due to having to make additional difficult-to-test > changes. > > If this is an issue I suppose core can vote on whether the SMP > cleanup should be MFC'd to 4.x. I've already laid out all the > reasons why I think it's a good idea to do. I don't have the 40 > man-hours it will take to guarentee compatibility with existing kld's > (even if most are probably already compatible) so if you make that > a requirement, the result will be no MFC at all. > > So you guys (core) choose -- do you want 4.x to reap the benefits of > further SMP development or not? If you choose no, beware that without > this base cleanup there is *NO* chance whatsoever of any further SMP > work being MFC'd to 4.x. None. Zilch. It will have diverged too > much. Personally (i.e. not speaking for core), I really want to preserve both the API and ABI for as many kernel interfaces as possible in the 4.x branch. This does restrict the kinds of work which can be done on 4.x but I'm convinced that this will improve both the percieved ("I recompiled my kernel and now it panics on boot - this sucks") and actual stability of the system. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 4:30:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id EA8A737B95B for ; Mon, 24 Apr 2000 04:30:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id VAA20612; Mon, 24 Apr 2000 21:30:04 +1000 Date: Mon, 24 Apr 2000 21:30:01 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Julian Elischer Cc: current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <39041698.15FB7483@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Julian Elischer wrote: > My cvsup appeared to be frozen, so I stopped it and looked.. > > src/sys/dev/isp/asm_pci.c,v is 13MB long! > it was just taking a long time.. > > this seems a little excessive. I was annoyed by this a few months ago when the file was only 10MB. > anyone got any ideas. (13MB on a 40Kbit link is a long time) Use CTM on slow links :-). > to make matters worse cvsup appears to be redownloading some very large > percentage of this file whenerver there is a change to it. This seems to be inherent in the file format. Binary data is expanded by a factor of 4 due to encoding it as a C array. Even tiny changes in the data ripple through the array and give huge diffs. Uuencoding the data would only expand it by a factor of 1.4 although it would have the same problem with the diffs. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 5:34:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by hub.freebsd.org (Postfix) with ESMTP id 24DAB37B95B for ; Mon, 24 Apr 2000 05:34:28 -0700 (PDT) (envelope-from netchild@leidinger.net) Received: from [62.104.201.2] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.14 #3) id 12ji4H-0001p8-00; Mon, 24 Apr 2000 14:34:25 +0200 Received: from [213.6.57.244] (helo=Magelan.Leidinger.net) by mx1.freenet.de with esmtp (Exim 3.14 #3) id 12ji4G-00038D-00; Mon, 24 Apr 2000 14:34:24 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.9.3/8.9.3) with ESMTP id NAA01320; Mon, 24 Apr 2000 13:25:42 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200004241125.NAA01320@Magelan.Leidinger.net> Date: Mon, 24 Apr 2000 13:25:39 +0200 (CEST) From: Alexander Leidinger Subject: Re: pthread_cond_broadcast() not delivered To: eischen@vigrid.com Cc: current@freebsd.org In-Reply-To: <200004231809.OAA29230@pcnet1.pcnet.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23 Apr, Daniel Eischen wrote: >> (14) netchild@ttyp2% uname -a >> FreeBSD Magelan.Leidinger.net 5.0-CURRENT FreeBSD 5.0-CURRENT #14: >> Fri Apr 21 17:28:37 CEST 2000 root@:/big/usr/src/sys/compile/WORK >> i386 >> >> I've an application which uses pthread_cond_{wait,broadcast}() and >> the debug output gives me the impression that the broadcast did not >> get delivered anymore. >> >> I run this program only occasionally, but with 4-current (last year) >> it worked, and I haven't changed anything mutex-/cond-related in it >> since then. >> >> I've attached a short test-prog (1.7k) which shows the same behavior, >> compile it with "cc -D_THREAD_SAFE -pthread test.c" and run >> "./a.out". > > If you want it to work correctly, you have to make the second thread > release the mutex. Look at it more closely: > > void * > second_thread(void *arg) > { > /* syncronize */ > fprintf(stderr, "Second: lock.\n"); > pthread_mutex_lock(main_mutex); > > fprintf(stderr, "Second: broadcast.\n"); > pthread_cond_broadcast(main_cond); > > fprintf(stderr, "Second: unlock.\n"); > pthread_mutex_lock(main_mutex); > ^^^^^^^^^^^^^^^^^^ [...] Yes, sorry, a flaw in my test-prog. And yes, the test-prog works now, but my app didn't. I've verified every lock/unlock with the corresponding fprintf(), it's consistent: ---snip--- [prefill buffer 0-14 and start Output-thread] Decode: (1) lock buffer. Decode: (2) lock buffer 15. Decode: before cond_wait. Output: (1) lock buffer. Output: before broadcast. Output: after broadcast. Output: (2) lock buffer 0. Output: (3) unlock buffer. Output: write buffer 0. Output: (5) unlock buffer 0 Output: (6) lock buffer. Output: (2) lock buffer 1. Output: (3) unlock buffer. Output: write buffer 1. Output: (5) unlock buffer 1 Output: (6) lock buffer. Output: (2) lock buffer 2. Output: (3) unlock buffer. Output: write buffer 2. Output: (5) unlock buffer 2 [... buffer 3-13] Output: (6) lock buffer. Output: (2) lock buffer 14. Output: (3) unlock buffer. Output: write buffer 14. Output: (5) unlock buffer 14 Output: (6) lock buffer. Output: (2) lock buffer 15. [deadlock] ---snip--- (after buf 15 it has to start with buf 0 again). The corresponding code (Decode-thread): ---snip--- #if 1 fprintf(stderr, "Decode: (1) lock buffer.\n"); #endif pthread_mutex_lock(output->mutex); /* [create output thread] */ #if 1 fprintf(stderr, "Decode: (2) lock buffer %d.\n", which_buffer); #endif pthread_mutex_lock(output->buffer[which_buffer].mutex); #if 1 fprintf(stderr, "Decode: before cond_wait.\n"); #endif pthread_cond_wait(&output->output_startet, output->mutex); #if 1 fprintf(stderr, "Decode: (3) unlock buffer.\n"); #endif pthread_mutex_unlock(output->mutex); ---snip--- and (Output-thread): ---snip--- #if 1 fprintf(stderr, "Output: (1) lock buffer.\n"); #endif pthread_mutex_lock(output->mutex); /* we are in sync, awake it */ #if 1 fprintf(stderr, "Output: before broadcast.\n"); #endif ret = pthread_cond_broadcast(&output->output_startet); #if 1 fprintf(stderr, "Output: after broadcast.\n"); #endif while((output->num_bytes == 0) || (output->num_bytes > bytes_written)) { #if 1 fprintf(stderr, "Output: (2) lock buffer %d.\n", which_buffer); #endif pthread_mutex_lock(output->buffer[which_buffer].mutex); #if 1 fprintf(stderr, "Output: (3) unlock buffer.\n"); #endif pthread_mutex_unlock(output->mutex); ---snip--- Everything looks fine here. And it worked a while ago. The only code-change is in the "Output: write buffer %d"-part. I'm now under the impression that the output part locks/unlocks output->mutex very fast and the Decode-thread isn't able to get the lock on it (after a little bit of restarting the app: sometimes it works, so it seems to be timing related). I replace the "Output: (2) lock buffer %d"-part with a trylock, usleep() a little bit if it returns EBUSY and have a look how it works. Sorry to have bothered the list with it, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander+Home @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 6:20:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from put.worldonline.nl (relay-2.worldonline.nl [195.241.48.138]) by hub.freebsd.org (Postfix) with ESMTP id D91BB37BAFA for ; Mon, 24 Apr 2000 06:20:48 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (vp227-230.worldonline.nl [195.241.227.230]) by put.worldonline.nl (8.9.3 (WOL 1.2)/8.9.3) with ESMTP id PAA14543; Mon, 24 Apr 2000 15:20:31 +0200 (MET DST) Message-ID: <39044A19.F6F4E479@vangelderen.org> Date: Mon, 24 Apr 2000 09:20:25 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Wackerbarth Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042315420301.24082@nomad.dataplex.net> <200004240605.XAA66216@apollo.backplane.com> <00042404464300.09955@nomad.dataplex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Wackerbarth wrote: > > On Mon, 24 Apr 2000, Matthew Dillon wrote: > > : However, I consider your SMP changes VERY destablizing; they BREAK > > : lots of modules :-( > > > > Huh? No they don't. They simply require recompiling the modules. If > > they actually broke the modules I wouldn't be trying to MFC it to > > -stable. > > >From the USER's perspective, anything that requires me to as much as reload > a module/program that I have already installed "breaks" it. > The fact that it is only necessary to recompile it in order to fix it only > means that it is easy to fix IF I have the source code. I don't think it was ever recommended that you upgrade your kernel without upgrading and rebuilding the modules (better still, world) at the same time. So this wouldn't really have an adverse effect, would it? Cheers, Jeroen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 6:40:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.pwahec.org (mail.pwahec.org [208.164.136.32]) by hub.freebsd.org (Postfix) with ESMTP id 5DB1737BA29 for ; Mon, 24 Apr 2000 06:40:54 -0700 (PDT) (envelope-from rsmall@pwahec.org) Received: from technogeek [208.129.166.68] by mail.pwahec.org (SMTPD32-5.05) id AEE41DC000AA; Mon, 24 Apr 2000 08:40:52 -0500 From: "Robert Small" To: Subject: Buildworld not working Date: Mon, 24 Apr 2000 08:40:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_012B_01BFADC8.CCA73D80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-MS-TNEF-Correlator: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_012B_01BFADC8.CCA73D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I've been trying to do a buildworld since Friday, after doing a cvsup, and no matter how many times I try, I keep getting: ===> librsausa cp /usr/src/secure/lib/librsausa/../libcrypto/opensslconf-i386.h openssl/opensslconf.h mkdir: openssl: File exists *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Any ideas? Thanks Robert Small ------=_NextPart_000_012B_01BFADC8.CCA73D80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjQNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHBAAYAAgAKAAAAAEAJAEB A5AGAAAGAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAFwAAAEJ1aWxkd29ybGQgbm90IHdvcmtpbmcAAAIBcQABAAAAFgAAAAG/rfK1OwsnbpUVQRHU rasAUASuZqMAAAIBHQwBAAAAFwAAAFNNVFA6UlNNQUxMQFBXQUhFQy5PUkcAAAsAAQ4AAAAAQAAG DgD4AJbyrb8BAgEKDgEAAAAYAAAAAAAAAGparZpgBNMRvdUAYAi9RxvCgAAACwAfDgEAAAACAQkQ AQAAAKQBAACgAQAAfQIAAExaRnX+rqFvAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBj aArAc7BldDAgBxMCgH0KgZJ2CJB3awuAZDQMYA5jAFALAwu1IEkndghlIGIJ4SB0cnlFC4BnFGBv IGQU8GFlFBB1AxBkdwWwFZAgKQCQbmMUAEYFEGRh/HksFTABgASQFQEUohVAYGN2c3VwFtESgCCe bhTwAMACQBchaG8H4K0DgXkKogqAdAdzSRRiixbQGmBrCeBwIGcRMFsaAA8gOhmkGaQ9HIA+kCBs aWIREGF1HRCTGaQN8CAvHTByLx4QzmMeMAWQCHBlLxzRHuKxHQQvLi4e4gUAeQUwsG8vb3AJ8AQQ bAWgAG5mLWkzODYuPGggIKUgmiGgGaRta7BkaXI6IcYj0EYDEGkUAGV4BAB0ELAZsyrxJZAgRXID YAXABaABAPYgEuMKgDEkwCXiJT8mQv8OUCavJ78ozynfKu8r/y0PFRvoQRmAIBaQZWFzyj8bylQQ 8G5rJSUZpN8IABQgACAGAADAbAlQGbMFEeEANMALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAA AAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYA AAAAUoUAACdqAQAeAAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwAMgAgg BgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAA2ACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAA AAsAFoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAXgAggBgAAAAAAwAAAAAAAAEYAAAAA EYUAAAAAAAADABmACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AKIAIIAYAAAAAAMAAAAAA AABGAAAAADaFAAABAAAAAQAAAAAAAAAeACmACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEA AAAAAAAAHgAqgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsAMoAIIAYAAAAA AMAAAAAAAABGAAAAAIKFAAABAAAAAgH4DwEAAAAQAAAAalqtmmAE0xG91QBgCL1HGwIB+g8BAAAA EAAAAGparZpgBNMRvdUAYAi9RxsCAfsPAQAAAJAAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNU UFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5OVFxQcm9maWxlc1xwd2FoZWNc TG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xtYWlsYm94 LnBzdAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAPE5EQkJMTk5GR0tES0tGQ0hDSEJQR0VG Q0NQQUEucnNtYWxsQHB3YWhlYy5vcmc+AAAAAAMABhC6La4OAwAHEE8BAAADABAQAAAAAAMAERAA AAAAHgAIEAEAAABlAAAASVZFQkVFTlRSWUlOR1RPRE9BQlVJTERXT1JMRFNJTkNFRlJJREFZLEFG VEVSRE9JTkdBQ1ZTVVAsQU5ETk9NQVRURVJIT1dNQU5ZVElNRVNJVFJZLElLRUVQR0VUVElORzo9 PQAAAADePg== ------=_NextPart_000_012B_01BFADC8.CCA73D80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 7: 3: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id D3F3037B6BC for ; Mon, 24 Apr 2000 07:02:57 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 09:02:55 -0500 From: Richard Wackerbarth To: "Jeroen C. van Gelderen" Subject: Re: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 09:02:53 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042404464300.09955@nomad.dataplex.net> <39044A19.F6F4E479@vangelderen.org> In-Reply-To: <39044A19.F6F4E479@vangelderen.org> MIME-Version: 1.0 Message-Id: <00042409025301.09317@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Jeroen C. van Gelderen wrote: > I don't think it was ever recommended that you upgrade your kernel > without upgrading and rebuilding the modules (better still, world) at > the same time. So this wouldn't really have an adverse effect, would it? Such a policy is totally unacceptable for "released" systems. Pre-release, I can accept it because the interfaces are still being tested and redesigned as needed. However, once a system is released, the users MUST have the ability to upgrade parts of the system without rebuilding everything. In fact, the user may be unable to rebuild parts of the system because he lacks the resources, be they hardware or source code. In particular, I, as a user, need to be able to purchase proprietary code and expect to be able to run it on a system. I further expect to be able to upgrade the kernel or shared libraries within the same release series and still use the same binary of the proprietary program. If this were not the case, we could argue that there is no need for the "linux compatability modes. Every Linux binary could just be recompiled into the FreeBSD format. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 7:10: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id 888FA37BAC2 for ; Mon, 24 Apr 2000 07:10:00 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac8.wam.umd.edu (root@rac8.wam.umd.edu [128.8.10.148]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA05698; Mon, 24 Apr 2000 10:09:06 -0400 (EDT) Received: from rac8.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac8.wam.umd.edu (8.9.3/8.9.3) with SMTP id KAA14076; Mon, 24 Apr 2000 10:09:22 -0400 (EDT) Received: from localhost (culverk@localhost) by rac8.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA14072; Mon, 24 Apr 2000 10:09:22 -0400 (EDT) X-Authentication-Warning: rac8.wam.umd.edu: culverk owned process doing -bs Date: Mon, 24 Apr 2000 10:09:21 -0400 (EDT) From: Kenneth Wayne Culver To: "Jeroen C. van Gelderen" Cc: Richard Wackerbarth , Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <39044A19.F6F4E479@vangelderen.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Richard Wackerbarth wrote: > > > > On Mon, 24 Apr 2000, Matthew Dillon wrote: > > > : However, I consider your SMP changes VERY destablizing; they BREAK > > > : lots of modules :-( > > > > > > Huh? No they don't. They simply require recompiling the modules. If > > > they actually broke the modules I wouldn't be trying to MFC it to > > > -stable. > > > > >From the USER's perspective, anything that requires me to as much as reload > > a module/program that I have already installed "breaks" it. > > The fact that it is only necessary to recompile it in order to fix it only > > means that it is easy to fix IF I have the source code. > > I don't think it was ever recommended that you upgrade your kernel > without upgrading and rebuilding the modules (better still, world) at > the same time. So this wouldn't really have an adverse effect, would it? > I believe that it depends on what changes were made since the last recompile, although it is good practice to at least recompile the modules when the kernel is recompiled. ================================================================= | Kenneth Culver | FreeBSD: The best OS around. | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 7:20:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from diwanh.stu.rpi.edu (diwanh.stu.rpi.edu [128.113.151.72]) by hub.freebsd.org (Postfix) with ESMTP id 9BDDC37BB0A for ; Mon, 24 Apr 2000 07:20:15 -0700 (PDT) (envelope-from hdiwan@diwanh.stu.rpi.edu) Received: (from hdiwan@localhost) by diwanh.stu.rpi.edu (8.9.3/8.9.3) id KAA12430 for freebsd-current@FreeBSD.ORG; Mon, 24 Apr 2000 10:20:12 -0400 (EDT) (envelope-from hdiwan) Date: Mon, 24 Apr 2000 10:20:12 -0400 From: Hasan Diwan To: freebsd-current@FreeBSD.ORG Subject: Re: Buildworld not working Message-ID: <20000424102012.B12143@diwanh.stu.rpi.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" X-Mailer: Mutt 1.0i In-Reply-To: ; from rsmall@pwahec.org on Mon, Apr 24, 2000 at 08:40:52AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Robert: as root: # rm -rf /usr/include/openssl /usr/obj=20 * Robert Small (rsmall@pwahec.org) [000424 10:08]: > I've been trying to do a buildworld since Friday, after doing a cvsup, and > no matter how many > times I try, I keep getting: >=20 > =3D=3D=3D> librsausa > cp /usr/src/secure/lib/librsausa/../libcrypto/opensslconf-i386.h > openssl/opensslconf.h > mkdir: openssl: File exists > Any ideas? >=20 --=20 Hasan Diwan [hdiwan@pobox.com] :) Rensselaer Polytechnic Institute=20 Computer Science Department http://hdwork.dhs.org/~hdiwan=20 --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBOQRYHPitTU38wbMJAQFqZwP+MtK1Bx7ZWYebJJEGNjaqmGIdNydbfvA6 SnA8CmDajcbJHdHXPnu4zxyx9X9+S4fncwiWwCelxG0rUl0+3xrsBEAYit2Z4z07 LiwSZbzS7bQEF1WYn2OTJ8gkBHmzKT+Np+KO8rX74iiLfJQUhJsBGq1bBbHVMHQE S1fnBKK0r1g= =FPrW -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 7:27:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id B571337BB2D for ; Mon, 24 Apr 2000 07:27:08 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 09:27:05 -0500 From: Richard Wackerbarth To: Kenneth Wayne Culver Subject: Re: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 09:27:04 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00042409270400.09338@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote: > > I don't think it was ever recommended that you upgrade your kernel > > without upgrading and rebuilding the modules (better still, world) at > > the same time. So this wouldn't really have an adverse effect, would it? > > I believe that it depends on what changes were made since the last > recompile, although it is good practice to at least recompile the modules > when the kernel is recompiled. On a released system, I may not have the sources to recompile the module. It might be a proprietary module that I got with the hardware, for example. That is why STABLE INTERFACES are so IMPORTANT to USERS. "Current" is a sandbox. Lower expectations are part of that game. But released systems are stone houses, not sandcastles. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 7:39:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from buzz.slic.com (eagle.slic.com [216.73.13.5]) by hub.freebsd.org (Postfix) with SMTP id B2E5237BB0A for ; Mon, 24 Apr 2000 07:39:39 -0700 (PDT) (envelope-from jontow@voodoo.minix.cx) Received: (qmail 248 invoked from network); 24 Apr 2000 14:49:45 -0000 Received: from unknown (HELO voodoo.minix.cx) (postfix@216.73.11.10) by eagle.slic.com with SMTP; 24 Apr 2000 14:49:45 -0000 Received: by voodoo.minix.cx (Postfix, from userid 1000) id 9AC4E2685; Mon, 24 Apr 2000 09:36:54 -0500 (EST) Date: Mon, 24 Apr 2000 09:36:54 -0500 From: Jonathan Towne To: Stephen Hocking Cc: freebsd-current@freebsd.org Subject: Re: Joystick has stopped working Message-ID: <20000424093653.A23873@minix.cx> Mail-Followup-To: Stephen Hocking , freebsd-current@freebsd.org References: <200004240656.OAA06520@bloop.craftncomp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004240656.OAA06520@bloop.craftncomp.com>; from shocking@prth.pgs.com on Mon, Apr 24, 2000 at 02:56:33PM +0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 02:56:33PM +0800, Stephen Hocking scribbled: # For sometime now, the analogue joy stick driver hasn't been working - it seems # to persistently return totally wild deviations when being read. Also, trying # to use it as a kld doersn't seem to work. Has anyone else had similar probs? I have the exact same problem..both under 5.0-CURRENT and 3.3-RELEASE.. but I've only got access to the -CURRENT machine now. An example of those evil values that it returns can be had via the perl one-liner in the joy(4) manpage.. www% perl -e 'open(JOY,"/dev/joy0")||die;while(1){sysread(JOY,$x,16); @j=unpack("iiii",$x);print "@j\n";sleep(1);}' -2147483648 -2147483648 0 0 -2147483648 -2147483648 0 0 -2147483648 -2147483648 0 0 -2147483648 -2147483648 0 0 ... etc etc The module even fails to load here, so I can't try that, and this happens with and without a joystick attached.. if you get a solution to this problem, please clue me in on it :) - Jonathan Towne To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 7:45:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from PLUTO.forumone.com (host04.forumone.com [207.197.235.4]) by hub.freebsd.org (Postfix) with ESMTP id BF17E37BAFA for ; Mon, 24 Apr 2000 07:45:14 -0700 (PDT) (envelope-from adhir@forumone.com) Received: by PLUTO.forumone.com with Internet Mail Service (5.5.2650.21) id <2GYQATFY>; Mon, 24 Apr 2000 10:45:07 -0400 Message-ID: From: Alok Dhir To: 'Richard Wackerbarth' , 'Matthew Dillon' Cc: "'freebsd-current@FreeBSD.ORG'" Subject: RE: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 10:45:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG SMP is a significant area of weakness for 4.0 and begs for improvement. I for one am thrilled at the progress Matt's made in this area and am itching to incorporate the changes into my 4.0 development servers (my production servers are still at 3.4-STABLE pending 4.1). If recompiling bothers you so much, we can have make a tarball distribution of the new module binaries. There - problem solved. People are going to have to recompile their kernels also, in order to get the SMP changes. Why is it such a stretch to require recompiling the kernel modules as well? My 2 cents... > -----Original Message----- > From: owner-freebsd-current@FreeBSD.ORG > [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Richard > Wackerbarth > Sent: Monday, April 24, 2000 5:47 AM > To: Matthew Dillon > Cc: freebsd-current@FreeBSD.ORG > Subject: Re: SMP changes and breaking kld object module compatibility > > > On Mon, 24 Apr 2000, Matthew Dillon wrote: > > : However, I consider your SMP changes VERY destablizing; they BREAK > > : lots of modules :-( > > > > Huh? No they don't. They simply require recompiling > the modules. If > > they actually broke the modules I wouldn't be trying to > MFC it to > > -stable. > > >From the USER's perspective, anything that requires me to as > much as reload > a module/program that I have already installed "breaks" it. > The fact that it is only necessary to recompile it in order > to fix it only > means that it is easy to fix IF I have the source code. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8: 6:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id C7FEF37BB28 for ; Mon, 24 Apr 2000 08:06:50 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p10-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.75]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA11416; Tue, 25 Apr 2000 00:06:22 +0900 (JST) Message-ID: <39046359.6B09960B@newsguy.com> Date: Tue, 25 Apr 2000 00:08:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: "Brandon D. Valentine" Cc: "Alok K. Dhir" , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brandon D. Valentine" wrote: > > On Mon, 24 Apr 2000, Alok K. Dhir wrote: > > > > >Totally off topic question that I've wondered for some time now - what > >does MFC stand for? > > According to the FAQ section located on the web @ > http://www.freebsd.org/FAQ/misc.html#AEN3908 > > Q: What does 'MFC' mean? > > A: MFC is an acronym for 'Merged From -CURRENT.' It's used in the CVS > logs to denote when a change was migrated from the CURRENT to the STABLE > branches. > > A quick search for MFC right from the freebsd.org main page would have > returned this information. And me, all this time thinking it was Mitigate Freaking Cronies! ;-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org dcs@there.is.no.such.thing.as.a.bsdconspiracy.net GPL certainly doesn't meet Janis Joplin's definition of freedom: "Freedom is just another word for nothing left to lose." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:13:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id C2F1D37B635 for ; Mon, 24 Apr 2000 08:13:15 -0700 (PDT) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id EA83B2435BF; Mon, 24 Apr 2000 10:13:14 -0500 (CDT) Date: Mon, 24 Apr 2000 10:13:14 -0500 From: "Jacques A . Vidrine" To: Richard Wackerbarth Cc: freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000424101314.A76089@spawn.nectar.com> References: <00042409270400.09338@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <00042409270400.09338@nomad.dataplex.net>; from rkw@dataplex.net on Mon, Apr 24, 2000 at 09:27:04AM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote: > On a released system, I may not have the sources to recompile the module. > It might be a proprietary module that I got with the hardware, for example. How real is this? What modules are we talking about? The last time I queried on `-stable' for users of third-party modules, only one was revealed. Are all modules effected, or only those that use certain interfaces? > That is why STABLE INTERFACES are so IMPORTANT to USERS. Agreed. -- Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:15:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from picalon.gun.de (picalon.gun.de [192.109.159.1]) by hub.freebsd.org (Postfix) with ESMTP id B64F337BB32 for ; Mon, 24 Apr 2000 08:15:20 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by picalon.gun.de (8.9.3/8.9.3) id RAA18675 for current@FreeBSD.ORG; Mon, 24 Apr 2000 17:15:16 +0200 (MET DST) >Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id QAA78762 for current@FreeBSD.ORG; Mon, 24 Apr 2000 16:56:07 +0200 (CEST) (envelope-from andreas) Date: Mon, 24 Apr 2000 16:56:07 +0200 From: Andreas Klemm To: current@FreeBSD.ORG Subject: apsfilter doesn't work anymore under current for remote print jobs Message-ID: <20000424165607.A76467@titan.klemm.gtn.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0.1i X-Operating-System: FreeBSD 5.0-CURRENT SMP X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Somehting must have changed with permissions in the last weeks. The owner of a print sessions control file are different when printing over network compared to a local print job. The lineprinter input filter doesn't have permissions to grep through the control file during runtime. Precise problem descr in the PR I submitted last recently. Sorry, didn't get a number back ... -- Andreas Klemm http://people.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 533 and songs from our band - http://people.freebsd.org/~andreas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:15:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id AE80637BAFE for ; Mon, 24 Apr 2000 08:15:50 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime.exit.com [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id IAA80054; Mon, 24 Apr 2000 08:15:43 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.3) id IAA12990; Mon, 24 Apr 2000 08:15:39 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200004241515.IAA12990@realtime.exit.com> Subject: Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesdayy In-Reply-To: from Martin Blapp at "Apr 24, 2000 11:45:38 am" To: Martin Blapp Date: Mon, 24 Apr 2000 08:15:39 -0700 (PDT) Cc: freebsd-current@FreeBSD.ORG, dillon@apollo.backplane.com Reply-To: frank@exit.com Organization: Exit Consulting X-Copyright0: Copyright 2000 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Blapp wrote: > I really like to see your fix committed to STABLE. It fixes also the > bad designed Staroffice 5.2 installation for some part (/usr/sbin/test). ...as well as the WordPerfect 2000 for Linux installation. Basically, it sounds like it makes Linux emulation really complete. Although I do agree that there should be a knob to turn this thing on and/or off. -- Frank Mayhar frank@exit.com http://www.exit.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:31:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1AFE037B596 for ; Mon, 24 Apr 2000 08:31:46 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p10-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.75]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA20131; Tue, 25 Apr 2000 00:31:32 +0900 (JST) Message-ID: <3904693F.ED9C5FA6@newsguy.com> Date: Tue, 25 Apr 2000 00:33:19 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Alok Dhir Cc: "'Richard Wackerbarth'" , "'Matthew Dillon'" , "'freebsd-current@FreeBSD.ORG'" Subject: Re: SMP changes and breaking kld object module compatibility References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alok Dhir wrote: > > SMP is a significant area of weakness for 4.0 and begs for improvement. I > for one am thrilled at the progress Matt's made in this area and am itching > to incorporate the changes into my 4.0 development servers (my production > servers are still at 3.4-STABLE pending 4.1). > > If recompiling bothers you so much, we can have make a tarball distribution > of the new module binaries. There - problem solved. > > People are going to have to recompile their kernels also, in order to get > the SMP changes. Why is it such a stretch to require recompiling the kernel > modules as well? Because if we do not provide a STABLE ABI, we WON'T get third-party (binary only) kernel modules. I'm very divided in this issue. 4.x has just started, and would be seriously impaired if no further improvements to it's SMP get in. On the other hand, if we can't garantee third party vendors a stable ABI, we won't get third party vendors. Alas... Dillon, how much of SMP improvements will be getting back-ported without further breaks in ABI, specially as BSDI code starts to trickle in? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org dcs@there.is.no.such.thing.as.a.bsdconspiracy.net GPL certainly doesn't meet Janis Joplin's definition of freedom: "Freedom is just another word for nothing left to lose." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:33: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 0BED437B635 for ; Mon, 24 Apr 2000 08:33:01 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac3.wam.umd.edu (root@rac3.wam.umd.edu [128.8.10.143]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id LAA08762; Mon, 24 Apr 2000 11:32:31 -0400 (EDT) Received: from rac3.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac3.wam.umd.edu (8.9.3/8.9.3) with SMTP id LAA29905; Mon, 24 Apr 2000 11:32:26 -0400 (EDT) Received: from localhost (culverk@localhost) by rac3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id LAA29901; Mon, 24 Apr 2000 11:32:26 -0400 (EDT) X-Authentication-Warning: rac3.wam.umd.edu: culverk owned process doing -bs Date: Mon, 24 Apr 2000 11:32:26 -0400 (EDT) From: Kenneth Wayne Culver To: Richard Wackerbarth Cc: freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <00042409270400.09338@nomad.dataplex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote: > > > > I don't think it was ever recommended that you upgrade your kernel > > > without upgrading and rebuilding the modules (better still, world) at > > > the same time. So this wouldn't really have an adverse effect, would it? > > > > I believe that it depends on what changes were made since the last > > recompile, although it is good practice to at least recompile the modules > > when the kernel is recompiled. > > On a released system, I may not have the sources to recompile the module. > It might be a proprietary module that I got with the hardware, for example. > That is why STABLE INTERFACES are so IMPORTANT to USERS. Yeah, I understand that. I was talking about -current. ================================================================= | Kenneth Culver | FreeBSD: The best OS around. | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:33:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id 0A83B37BB0A for ; Mon, 24 Apr 2000 08:33:33 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id JAA04715 for ; Mon, 24 Apr 2000 09:33:29 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200004241533.JAA04715@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Apr 2000 09:33:29 -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > So you guys (core) choose -- do you want 4.x to reap the benefits of > further SMP development or not? If you choose no, beware that without > this base cleanup there is *NO* chance whatsoever of any further SMP > work being MFC'd to 4.x. None. Zilch. It will have diverged too > much. As the original author of the cil/cml code I can say I was glad to see that Matt had finally put it to rest. It was a desperate hack made in an attempt to pinch a little more performance out of the paradigm without dealing with the whole spl() problem set. I would have done it myself if life hadn't taken me down a path where I have too little time for these things... I've been playing with test buildworlds on my server and have concluded that we are currently kernel (big giant lock?) bound. In my tests 3 CPUs actually complete buildworld faster than 4. The major solutions to SMP in the future will come from: 1: pushdown of the BGL into the read/write routines. 2: kernel threads. 3: replacement of spl() with mutex() type protection of data regions. I am guessing that little of the above will be MFC'd into 4.0. So the issue of the current SMP patch set should be based on its merits alone. I would agree that they in themselves are worthy of MFCing. Lets just not kid ourselves about major future improvements of SMP in 4.0, the biggies I enumerate above just won't happen there. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:33:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2F89337BB5A for ; Mon, 24 Apr 2000 08:33:50 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA03902; Mon, 24 Apr 2000 08:33:04 -0700 Date: Mon, 24 Apr 2000 08:33:46 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Julian Elischer Cc: current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <39041698.15FB7483@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, this needs to be fixed. I have an open bug about this with respect to making the f/w a loadable module as well. I'll probably split it into several pieces so that each f/w update is smaller. I could probably make it binary and compress is (each f/w module is an array of 16 bit shorts), but that has it's onw problems. You should note, btw, that my link isn't all *that* faster than yours (I have 144Kbit DSL). Sorry about the large enchilada. On Mon, 24 Apr 2000, Julian Elischer wrote: > My cvsup appeared to be frozen, so I stopped it and looked.. > > src/sys/dev/isp/asm_pci.c,v is 13MB long! > it was just taking a long time.. > > this seems a little excessive. > > anyone got any ideas. (13MB on a 40Kbit link is a long time) > > to make matters worse cvsup appears to be redownloading some very large > percentage of this file whenerver there is a change to it. > > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Perth > v > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:36:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 20B7237BB63 for ; Mon, 24 Apr 2000 08:36:23 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA33905; Mon, 24 Apr 2000 11:36:11 -0400 (EDT) (envelope-from wollman) Date: Mon, 24 Apr 2000 11:36:11 -0400 (EDT) From: Garrett Wollman Message-Id: <200004241536.LAA33905@khavrinen.lcs.mit.edu> To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: References: <39041698.15FB7483@elischer.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > This seems to be inherent in the file format. Binary data is expanded > by a factor of 4 due to encoding it as a C array. Even tiny changes > in the data ripple through the array and give huge diffs. Uuencoding > the data would only expand it by a factor of 1.4 although it would > have the same problem with the diffs. I've been thinking about this recently myself. We want to maintain the ability to examine historical versions of the code, but actual diffs from one version to another are, in this context, meaningless. I'd like to suggest a new hierarchy /usr/firmware, which sits along-side /usr/src and /usr/ports in our distribution mechanism, but which does not use RCS files to store version information. Rather, the version information is encoded in the pathname, and files are stored and transferred as binary objects. It might look something like this: /usr/firmware/ gronk/ (this is the gronk driver) 3.57.OA.bin (where 3.57.OA is vendor's version) plugh/ 42.69/ model1.bin model2.bin model3.bin -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:47:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 04E9A37BA12 for ; Mon, 24 Apr 2000 08:47:29 -0700 (PDT) (envelope-from julian@elischer.org) Received: from gothic.iinet.net.au (gothic.iinet.net.au [203.59.24.252]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id XAA29443; Mon, 24 Apr 2000 23:47:25 +0800 Received: from jules.elischer.org (reggae-01-179.nv.iinet.net.au [203.59.62.179]) by gothic.iinet.net.au (8.8.5/8.8.5) with SMTP id XAA04926; Mon, 24 Apr 2000 23:47:22 +0800 Message-ID: <39046BF1.1CFBAE39@elischer.org> Date: Mon, 24 Apr 2000 08:44:49 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Garrett Wollman Cc: Bruce Evans , current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! References: <39041698.15FB7483@elischer.org> <200004241536.LAA33905@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman wrote: > > < said: > > > This seems to be inherent in the file format. Binary data is expanded > > by a factor of 4 due to encoding it as a C array. Even tiny changes > > in the data ripple through the array and give huge diffs. Uuencoding > > the data would only expand it by a factor of 1.4 although it would > > have the same problem with the diffs. > > I've been thinking about this recently myself. We want to maintain > the ability to examine historical versions of the code, but actual > diffs from one version to another are, in this context, meaningless. > > I'd like to suggest a new hierarchy /usr/firmware, which sits > along-side /usr/src and /usr/ports in our distribution mechanism, but > which does not use RCS files to store version information. Rather, > the version information is encoded in the pathname, and files are > stored and transferred as binary objects. It might look something > like this: > > /usr/firmware/ > gronk/ (this is the gronk driver) > 3.57.OA.bin (where 3.57.OA is vendor's version) > plugh/ > 42.69/ > model1.bin > model2.bin > model3.bin > > -GAWollman This seems well thought out and I certainly agree that we don't need DIFFs of firmware. I wonder if we can somehow "cheat time" and get that 13MB file out of the source tree and retro-actively tag the new scheme so that we don't have to carry it around forever :-) -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 8:57:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id A107737BB08 for ; Mon, 24 Apr 2000 08:57:36 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime.exit.com [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id IAA80392; Mon, 24 Apr 2000 08:57:31 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.3) id IAA13657; Mon, 24 Apr 2000 08:57:30 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200004241557.IAA13657@realtime.exit.com> Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <00042409270400.09338@nomad.dataplex.net> from Richard Wackerbarth at "Apr 24, 2000 09:27:04 am" To: Richard Wackerbarth Date: Mon, 24 Apr 2000 08:57:30 -0700 (PDT) Cc: Kenneth Wayne Culver , freebsd-current@FreeBSD.ORG Reply-To: frank@exit.com Organization: Exit Consulting X-Copyright0: Copyright 2000 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Wackerbarth wrote: > On a released system, I may not have the sources to recompile the module. > It might be a proprietary module that I got with the hardware, for example. > That is why STABLE INTERFACES are so IMPORTANT to USERS. > > "Current" is a sandbox. Lower expectations are part of that game. > But released systems are stone houses, not sandcastles. On the _other_ hand: 1. 4.0 hasn't been out long enough for there to be any significant support for it in proprietary systems. It takes more lead time than this. 2. Significant enhancements are often worth the price in needing to rebuild modules. The SMP fixes are quite significant and, IMHO, are very worth the possible short-term instability induced by them. (Although it looks like they're quite stable.) Consider me a customer that is very interested in these fixes even though my bread-and-butter system will need to be rebuilt. 3. Any proprietary module that depends so heavily upon kernel internals is, IMNSHO, broken by definition. If one is writing a proprietary module, particularly for an open-source system, one should write to the lowest common denominator and _not_ to internal interfaces that could change out from under you at any moment. 4. No system, released or otherwise, is a "stone house." At best it's a wooden house (to use your terminology), since defect fixes might require changes to internal interfaces. I know, I do this for a living. 5. The SMP stuff is about _internal_ interfaces, not external ones. External interfaces are the ones that are fixed in any OS, not the internal ones. Otherwise, how do we make progress? The Linux ABI, btw (to refer to your previous message on the subject), is a set of _external_ interfaces, not internal ones. Number six is probably better unsaid. -- Frank Mayhar frank@exit.com http://www.exit.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 9: 7:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7BE2337BB13 for ; Mon, 24 Apr 2000 09:07:21 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA04030; Mon, 24 Apr 2000 09:06:26 -0700 Date: Mon, 24 Apr 2000 09:07:08 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Garrett Wollman Cc: Bruce Evans , current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <200004241536.LAA33905@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is probably an okay idea, except how would you include such files? I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with /usr/src/sys/dev/firmware/{isp, esh, ...}? On Mon, 24 Apr 2000, Garrett Wollman wrote: > < said: > > > This seems to be inherent in the file format. Binary data is expanded > > by a factor of 4 due to encoding it as a C array. Even tiny changes > > in the data ripple through the array and give huge diffs. Uuencoding > > the data would only expand it by a factor of 1.4 although it would > > have the same problem with the diffs. > > I've been thinking about this recently myself. We want to maintain > the ability to examine historical versions of the code, but actual > diffs from one version to another are, in this context, meaningless. > > I'd like to suggest a new hierarchy /usr/firmware, which sits > along-side /usr/src and /usr/ports in our distribution mechanism, but > which does not use RCS files to store version information. Rather, > the version information is encoded in the pathname, and files are > stored and transferred as binary objects. It might look something > like this: > > /usr/firmware/ > gronk/ (this is the gronk driver) > 3.57.OA.bin (where 3.57.OA is vendor's version) > plugh/ > 42.69/ > model1.bin > model2.bin > model3.bin > > -GAWollman > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 9: 9:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 3497B37B596 for ; Mon, 24 Apr 2000 09:09:35 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id JAA11108; Mon, 24 Apr 2000 09:09:11 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200004241609.JAA11108@gndrsh.dnsmgr.net> Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000424101314.A76089@spawn.nectar.com> from "Jacques A . Vidrine" at "Apr 24, 2000 10:13:14 am" To: n@nectar.com (Jacques A . Vidrine) Date: Mon, 24 Apr 2000 09:09:10 -0700 (PDT) Cc: rkw@dataplex.net (Richard Wackerbarth), freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote: > > On a released system, I may not have the sources to recompile the module. > > It might be a proprietary module that I got with the hardware, for example. > > How real is this? What modules are we talking about? The last time > I queried on `-stable' for users of third-party modules, only one was > revealed. Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules so every vendor that has ever tried to use them has been bitten by the fact that they have to maintain N version for each branch of FreeBSD??? > Are all modules effected, or only those that use certain interfaces? Given that this is a change in splxxx() I suspect that it breaks most modules, but probably not all modules. A quick grep -l spl * | wc vs ls | wc shows 77 out of 100, not exact due to probable false hits on spl, but it gets us the ball park, significant is what is says. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 9:19:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-202-179-64.dsl.snfc21.pacbell.net [63.202.179.64]) by hub.freebsd.org (Postfix) with ESMTP id D077637BB95 for ; Mon, 24 Apr 2000 09:19:37 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id JAA59977; Mon, 24 Apr 2000 09:26:44 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004241626.JAA59977@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: frank@exit.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-reply-to: Your message of "Mon, 24 Apr 2000 08:57:30 PDT." <200004241557.IAA13657@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Apr 2000 09:26:44 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On the _other_ hand: > > 1. 4.0 hasn't been out long enough for there to be any significant support > for it in proprietary systems. It takes more lead time than this. Unfortunately, many vendors will simply install from the 4.0-RELEASE CD and build their modules there. > 3. Any proprietary module that depends so heavily upon kernel internals is, > IMNSHO, broken by definition. If one is writing a proprietary module, > particularly for an open-source system, one should write to the lowest > common denominator and _not_ to internal interfaces that could change > out from under you at any moment. Er. spl() is a public interface. > 5. The SMP stuff is about _internal_ interfaces, not external ones. External > interfaces are the ones that are fixed in any OS, not the internal ones. > Otherwise, how do we make progress? The Linux ABI, btw (to refer to your > previous message on the subject), is a set of _external_ interfaces, not > internal ones. See above. Steve Passe actually argued quite eloquently against his own decision; the "real work" that actually depends heavily on this foundation is almost certainly never going to come back to the 4.x branch. Since these changes don't actually bring any real improvements in and of themselves, there's little point in merging them for their own sake. The _only_ reason to bring these changes back is if we're contemplating massive changes in 4.x's SMP support, and if we're willing to live with the significant compatibility churn this is going to cause. Nobody yet has suggested that this is the case, and I do not believe that it is. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10: 0:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 68EFF37BA1C for ; Mon, 24 Apr 2000 10:00:36 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70763; Mon, 24 Apr 2000 10:00:24 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Apr 2000 10:00:24 -0700 (PDT) From: Matthew Dillon Message-Id: <200004241700.KAA70763@apollo.backplane.com> To: "Jacques A . Vidrine" Cc: Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <00042409270400.09338@nomad.dataplex.net> <20000424101314.A76089@spawn.nectar.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote: :> On a released system, I may not have the sources to recompile the module. :> It might be a proprietary module that I got with the hardware, for example. : :How real is this? What modules are we talking about? The last time :I queried on `-stable' for users of third-party modules, only one was :revealed. : :Are all modules effected, or only those that use certain interfaces? : :> That is why STABLE INTERFACES are so IMPORTANT to USERS. : :Agreed. :-- :Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org Many kernel interfaces are macros. So while the API stays the same, the actual implementation winds up buried in the module code. If the implementation has to change (even though the API does not), those modules must be recompiled. This is an unfortunate fact of life when it comes to kernel loadable modules and is true of both Linux and FreeBSD. I've done a quick audit of the spl code and I think I'm actually wrong there... it looks like the SPL code is in fact implemented as a procedure ( I remembered it being a macro but it actually isn't from the point of view of modules that use it). So I think we're safe in this particular case. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10: 3:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F2C3B37B7ED for ; Mon, 24 Apr 2000 10:03:32 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70812; Mon, 24 Apr 2000 10:03:26 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Apr 2000 10:03:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200004241703.KAA70812@apollo.backplane.com> To: "Daniel C. Sobral" Cc: Alok Dhir , "'Richard Wackerbarth'" , "'freebsd-current@FreeBSD.ORG'" Subject: Re: SMP changes and breaking kld object module compatibility References: <3904693F.ED9C5FA6@newsguy.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Because if we do not provide a STABLE ABI, we WON'T get third-party :(binary only) kernel modules. : :I'm very divided in this issue. 4.x has just started, and would be :seriously impaired if no further improvements to it's SMP get in. On :the other hand, if we can't garantee third party vendors a stable ABI, :we won't get third party vendors. : :Alas... Dillon, how much of SMP improvements will be getting back-ported :without further breaks in ABI, specially as BSDI code starts to trickle :in? : :-- :Daniel C. Sobral (8-DCS) Most of the SMP innards are invisible to the user and even invisible (for the most part) to KLD's. For example, making the VM subsystem and network stack MP-safe can probably be done without any external visibility. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10: 8: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id 970A637B5F1; Mon, 24 Apr 2000 10:07:58 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA27091; Mon, 24 Apr 2000 10:07:36 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <39047F57.61D37EC4@gorean.org> Date: Mon, 24 Apr 2000 10:07:35 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0422 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: "Jordan K. Hubbard" , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <10872.956523122@zippy.cdrom.com> <200004240617.XAA66270@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > So you guys (core) choose -- do you want 4.x to reap the benefits of > further SMP development or not? If you choose no, beware that without > this base cleanup there is *NO* chance whatsoever of any further SMP > work being MFC'd to 4.x. None. Zilch. It will have diverged too > much. I think that we can find a middle ground on this issue. Jordan made an excellent point in that this ".0" release has had more early adopters than any previous first release on a new branch. Therefore we want to take extra care to maintain the "-stable" perception of the 4.0-Stable branch. At the same time, Matt is correct in saying that the base of the SMP improvements needs to go into 4.0 now. The PR ramifications alone would be disastrous if the only place the SMP improvements were available was 5.0-Current. That would simply reinforce the perception that FreeBSD is nothing more than a toy for the developers. On the third hand (so to speak) is the fact that we really would like to be able to present a stable external interface to encourage third party developers to develop to the 4.x branch. So, my suggested compromise is this. Do the MFC now, with the caveat that this will be the only external interface change in 4.x-Stable. Architect out whatever changes have to happen, and make sure that the best guess as to what the interface should be gets committed, then stick to it, no matter how painful it is. It's still early enough to get away with this, but we can only "sell it" once, so let's get it right this time. I've got a fleet of SMP boxes at work, and given the coming instability of -Current I'd really like to stick with 4.0-Stable if I can, and in fact I've already made plans that relied on the work Matt's already done being MFC'ed as previously announced. I could probably justify the development time to track -Current if the performance gains were large enough, and in fact I'll probably put a machine or two on it to try and make a contribution to testing, etc. But speaking as a sysadmin the advantages of being able to rely on well tested changes that get MFC'ed on a regular basis for the majority of my machines would be a huge win. Doug -- Excess on occasion is exhilarating. It prevents moderation from acquiring the deadening effect of a habit. -- W. Somerset Maugham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10:19:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 180FD37BB7D for ; Mon, 24 Apr 2000 10:19:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70893; Mon, 24 Apr 2000 10:19:33 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Apr 2000 10:19:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200004241719.KAA70893@apollo.backplane.com> To: Steve Passe Cc: current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <200004241533.JAA04715@Ilsa.StevesCafe.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :As the original author of the cil/cml code I can say I was glad to see that :Matt :had finally put it to rest. It was a desperate hack made in an attempt to pinch :a little more performance out of the paradigm without dealing with the whole :spl() problem set. I would have done it myself if life hadn't taken me down a :path where I have too little time for these things... : :I've been playing with test buildworlds on my server and have concluded that :we are currently kernel (big giant lock?) bound. In my tests 3 CPUs actually :complete buildworld faster than 4. The major solutions to SMP in the future :will come from: : : 1: pushdown of the BGL into the read/write routines. : 2: kernel threads. : 3: replacement of spl() with mutex() type protection of data regions. : :I am guessing that little of the above will be MFC'd into 4.0. So the issue :of the current SMP patch set should be based on its merits alone. I would :agree that they in themselves are worthy of MFCing. Lets just not kid :ourselves about major future improvements of SMP in 4.0, the biggies I :enumerate above just won't happen there. : :-- :Steve Passe | powered by :smp@csn.net | Symmetric MultiProcessor FreeBSD This is my feeling too. I think there is a very good chance that we would be able to MFC SMP work for the Network stack and VM subsystem, for example. The SMP work under 4.x and 5.x wound up getting stalled in part because there were three or four different versions of each core assembly module in #ifdef's to handle all the different options combinations, and it got to the point where I think only three or four people really knew what was going on in there. From an algorithmic and testing point of view, what the cml and cil changes taught us is that segregating the spin locks doesn't improve performance because programs tend to repeat the use of a particular entry point over and over again (like calling read() or write()), and thus wind up competing for the same spin lock anyway. Basically it told us that region-based locks don't produce significant performance improvements and we have to get rid of the high level locks entirely to make things reasonably efficient. The network stack and VM system are a particularly good fit to this because locking can occur at a much finer grain. vm_page_t/vm_object lookups can almost run MP-safe now with only the addition of a shared lock at the vm_object and VM page cache level to allow lookups. Pages are already individually locked and that mechanism need not change. There are a bunch of areas where the VM system is running at splvm() in order to be able to lookup pages without busying them which would have to change, but that isn't a huge deal. The network stack is equally easy to make MP-safe. In this case we have a shared lock to lookup sockets for host/port combinations and then fine-grained exclusive locks within those sockets. Route table and other high level operations could in fact remain BGL'd without interfering with the network stack because the network stack *already* caches route table lookups. The KISS principle applies to SMP big-time. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10:25:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id B071037BB6F for ; Mon, 24 Apr 2000 10:25:14 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 12:25:09 -0500 From: Richard Wackerbarth To: frank@exit.com Subject: Re: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 12:25:08 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: <200004241557.IAA13657@realtime.exit.com> In-Reply-To: <200004241557.IAA13657@realtime.exit.com> MIME-Version: 1.0 Message-Id: <00042412250801.09373@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Frank Mayhar wrote: > 1. 4.0 hasn't been out long enough for there to be any significant support > for it in proprietary systems. It takes more lead time than this. So make the change and release it as FreeBSD5. Save the big changes for something called FreeBSd6 or FreeBSD2000, or ... The vendors can simply say "we don't support" FreeBSD4. The confusion factor for users is real. This module works with FreeBSD4 kernels, but only those after April 26, 2000 just doesn't "sell". > 2. Significant enhancements are often worth the price I'm not against "progress". It's just how it gets packaged. >> 3. Any proprietary module that depends so heavily upon kernel internals is, > IMNSHO, broken by definition. If one is writing a proprietary module, > particularly for an open-source system, one should write to the lowest > common denominator and _not_ to internal interfaces that could change > out from under you at any moment. As I understand it, it's not a fundamental change to the interface that "bites". A simple recompile will "fix" most modules. Every module that exchanges information with the kernel depends on its interfaces. > 4. No system, released or otherwise, is a "stone house." At best it's a > wooden house (to use your terminology), since defect fixes might require > changes to internal interfaces. I know, I do this for a living. I did too. Only we were never so casual about changing interfaces after a release. > 5. The SMP stuff is about _internal_ interfaces, not external ones. Internal vs External is administrative. Any time one organization provides one piece and another provides the other, the interface is, by definition, external. Loadable kernel modules can come for multiple sources. Therefore the interface to them is external. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10:26:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 15C2537B8D8 for ; Mon, 24 Apr 2000 10:26:56 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA34251; Mon, 24 Apr 2000 13:26:52 -0400 (EDT) (envelope-from wollman) Date: Mon, 24 Apr 2000 13:26:52 -0400 (EDT) From: Garrett Wollman Message-Id: <200004241726.NAA34251@khavrinen.lcs.mit.edu> To: mjacob@feral.com Cc: current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: References: <200004241536.LAA33905@khavrinen.lcs.mit.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > This is probably an okay idea, except how would you include such files? > I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with > /usr/src/sys/dev/firmware/{isp, esh, ...}? The fact that said directory is under CVS control, which is what I'm suggesting we get away from. The files can be compiled into the kernel very easily using `file2c', or simply loaded directly by the boot loader. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10:37:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7F50A37B5F1 for ; Mon, 24 Apr 2000 10:37:39 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA04458; Mon, 24 Apr 2000 10:36:41 -0700 Date: Mon, 24 Apr 2000 10:37:24 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <200004241726.NAA34251@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > < said: > > > This is probably an okay idea, except how would you include such files? > > I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with > > /usr/src/sys/dev/firmware/{isp, esh, ...}? > > The fact that said directory is under CVS control, which is what I'm > suggesting we get away from. Umm, then I sure don't get what you're wanting to do. > > The files can be compiled into the kernel very easily using `file2c', > or simply loaded directly by the boot loader. > I put in maybe 40-80 hours testing per f/w upgrade. There has to be some assurance that what you load is correct. CVS does give some assurance of strong versioning. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10:45:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 56C5C37B982 for ; Mon, 24 Apr 2000 10:45:38 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA71123; Mon, 24 Apr 2000 10:45:38 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Apr 2000 10:45:38 -0700 (PDT) From: Matthew Dillon Message-Id: <200004241745.KAA71123@apollo.backplane.com> To: Matthew Dillon Cc: "Jacques A . Vidrine" , Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <00042409270400.09338@nomad.dataplex.net> <20000424101314.A76089@spawn.nectar.com> <200004241700.KAA70763@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After further review I don't think there are any compatibility problems with the spl*() mechanisms. But I must still caution that due to the extensive nature of the cleanup, despite being mostly internal to the kernel, there could very well be other things that we have overlooked which might still cause problems with third party modules that aren't recompiled. The real answer has changed from "There will be problems" to "There may be problems". -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10:53:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D27E937B715 for ; Mon, 24 Apr 2000 10:53:45 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e3OIMYf29946; Mon, 24 Apr 2000 11:22:34 -0700 (PDT) Date: Mon, 24 Apr 2000 11:22:34 -0700 From: Alfred Perlstein To: Matthew Dillon Cc: "Jacques A . Vidrine" , Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000424112234.A24816@fw.wintelcom.net> References: <00042409270400.09338@nomad.dataplex.net> <20000424101314.A76089@spawn.nectar.com> <200004241700.KAA70763@apollo.backplane.com> <200004241745.KAA71123@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004241745.KAA71123@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Apr 24, 2000 at 10:45:38AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Dillon [000424 11:15] wrote: > After further review I don't think there are any compatibility problems > with the spl*() mechanisms. > > But I must still caution that due to the extensive nature of the > cleanup, despite being mostly internal to the kernel, there could > very well be other things that we have overlooked which might still cause > problems with third party modules that aren't recompiled. The real answer > has changed from "There will be problems" to "There may be problems". If spl is actually a function and not a macro we should be fine. I think as a whole we need to evaluate the use of macros, they're one of the major problems with changes like this and several people have come forward over time with strong numbers showing that the code bloat causes that comes with overuse of macros causes problems with the I cache where inlining really doesn't pay off. Most archs nowadays have pretty good support for leaf functions or have cheap calls instructions. Just food for thought. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 10:59:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 3C8E637BAED for ; Mon, 24 Apr 2000 10:58:53 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 12:58:49 -0500 From: Richard Wackerbarth To: Alfred Perlstein Subject: Re: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 12:58:49 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: <200004241745.KAA71123@apollo.backplane.com> <20000424112234.A24816@fw.wintelcom.net> In-Reply-To: <20000424112234.A24816@fw.wintelcom.net> MIME-Version: 1.0 Message-Id: <00042412584901.09404@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Alfred Perlstein wrote: > I think as a whole we need to evaluate the use of macros, they're > one of the major problems with changes like this and several people > have come forward over time with strong numbers showing that the > code bloat causes that comes with overuse of macros causes problems > with the I cache where inlining really doesn't pay off. Most archs > nowadays have pretty good support for leaf functions or have cheap > calls instructions. Macros CAN generate function calls :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 11:43:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 4CAB037B72F for ; Mon, 24 Apr 2000 11:43:23 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@c04-194.006.popsite.net [216.126.137.194]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA36017; Mon, 24 Apr 2000 11:43:20 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id LAA12776; Mon, 24 Apr 2000 11:43:17 -0700 (PDT) (envelope-from obrien) Date: Mon, 24 Apr 2000 11:43:17 -0700 From: "David O'Brien" To: Robert Small Cc: freebsd-current@FreeBSD.ORG Subject: Re: Buildworld not working Message-ID: <20000424114317.C12417@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from rsmall@pwahec.org on Mon, Apr 24, 2000 at 08:40:52AM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 08:40:52AM -0500, Robert Small wrote: > I've been trying to do a buildworld since Friday, after doing a cvsup, and > no matter how many > times I try, I keep getting: Please try: cd /usr/src make cleandir && make cleandir and try again. Let me know the outcome -- good or bad. *If* the outcome is "good". Please do a second ``make buildworld'' w/o doing anything else. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 11:44: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id A53BC37B666 for ; Mon, 24 Apr 2000 11:43:58 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 13:43:45 -0500 From: Richard Wackerbarth To: Julian Elischer Subject: Re: asm_pci.h,v Holy cow! Date: Mon, 24 Apr 2000 13:43:44 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: current@FreeBSD.ORG References: <39041698.15FB7483@elischer.org> <200004241536.LAA33905@khavrinen.lcs.mit.edu> <39046BF1.1CFBAE39@elischer.org> In-Reply-To: <39046BF1.1CFBAE39@elischer.org> MIME-Version: 1.0 Message-Id: <00042413373504.09404@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Julian Elischer wrote: > This seems well thought out and I certainly agree that we don't need > DIFFs of firmware. > I wonder if we can somehow "cheat time" and get that 13MB file out of > the source tree and retro-actively tag the new scheme so > that we don't have to carry it around forever :-) It looks like a port, Smells like a port, and tastes like a port. It must be a ..... merlot ? Seriously, perhaps we should consider putting optional pieces of the kernel (eventually much of it, I hope) into a ports style structure. This structure can already take care of most of the problems like this one because it has multiple mechanisms whereas the source tree has only one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 11:44:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 6D01F37B8D8 for ; Mon, 24 Apr 2000 11:44:43 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id C23661C4A; Mon, 24 Apr 2000 14:44:41 -0400 (EDT) Date: Mon, 24 Apr 2000 14:44:41 -0400 From: Bill Fumerola To: Richard Wackerbarth Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000424144441.W397@jade.chc-chimes.com> References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042315420301.24082@nomad.dataplex.net> <200004240605.XAA66216@apollo.backplane.com> <00042404464300.09955@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00042404464300.09955@nomad.dataplex.net>; from rkw@dataplex.net on Mon, Apr 24, 2000 at 04:46:43AM -0500 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote: > >From the USER's perspective, anything that requires me to as much as reload > a module/program that I have already installed "breaks" it. > The fact that it is only necessary to recompile it in order to fix it only > means that it is easy to fix IF I have the source code. No-one forces you to upgrade you systems. Partial upgrades are something that are nice when they work, but understood when they don't. We don't accept bug reports (typically) when a person hasn't upgraded their world, kernel, and modules. I don't understand why we're accepting preemptive bitching. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 11:45:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 9C00537B931 for ; Mon, 24 Apr 2000 11:45:52 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@c04-194.006.popsite.net [216.126.137.194]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA36036; Mon, 24 Apr 2000 11:45:48 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id LAA12818; Mon, 24 Apr 2000 11:45:42 -0700 (PDT) (envelope-from obrien) Date: Mon, 24 Apr 2000 11:45:41 -0700 From: "David O'Brien" To: Sergey Osokin Cc: current@FreeBSD.org Subject: Re: make buildworld failed... Message-ID: <20000424114541.D12417@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20000422010524.A16369@freebsd.org.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000422010524.A16369@freebsd.org.ru>; from osa@freebsd.org.ru on Sat, Apr 22, 2000 at 01:05:24AM +0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 22, 2000 at 01:05:24AM +0400, Sergey Osokin wrote: > Hello! > After CVSup i tryed to rebuild my 5.0... Are you using "-j" with your makes? Please try: cd /usr/src make cleandir && make cleandir and try again. Let me know the outcome -- good or bad. *If* the outcome is "good". Please do a second ``make buildworld'' w/o doing anything else. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 11:48:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 9946437BB6F; Mon, 24 Apr 2000 11:48:23 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@c04-194.006.popsite.net [216.126.137.194]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA36048; Mon, 24 Apr 2000 11:48:21 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id LAA12844; Mon, 24 Apr 2000 11:48:19 -0700 (PDT) (envelope-from obrien) Date: Mon, 24 Apr 2000 11:48:18 -0700 From: "David O'Brien" To: Kris Kennaway Cc: current@FreeBSD.org Subject: Re: OpenSSL asm optimizations Message-ID: <20000424114818.F12417@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from kris@FreeBSD.org on Fri, Apr 21, 2000 at 07:28:28PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 21, 2000 at 07:28:28PM -0700, Kris Kennaway wrote: > patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to > "i586" or "i686" (both are actually identical at present) and rebuild. Please also support "k5" and "k6". -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 11:55: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 2B21537BB8D; Mon, 24 Apr 2000 11:55:00 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA14088; Mon, 24 Apr 2000 11:55:57 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Matthew Dillon Cc: "Rodney W. Grimes" , phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-reply-to: Your message of "Sun, 23 Apr 2000 23:17:51 PDT." <200004240617.XAA66270@apollo.backplane.com> Date: Mon, 24 Apr 2000 11:55:57 -0700 Message-ID: <14085.956602557@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So you guys (core) choose -- do you want 4.x to reap the benefits of > further SMP development or not? I've read all the feedback on this thread and now feel that it would be worthwhile to simply bring the SMP changes in on Wednesday. As others have pointed out, we don't have enough 3rd party 4.0 klds yet (I'd have a hard time even saying "any") to make this a real problem so let's just go for it. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 11:56:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id E9E9437B85F for ; Mon, 24 Apr 2000 11:56:51 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA14103; Mon, 24 Apr 2000 11:57:44 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Rodney W. Grimes" Cc: n@nectar.com (Jacques A . Vidrine), rkw@dataplex.net (Richard Wackerbarth), freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-reply-to: Your message of "Mon, 24 Apr 2000 09:09:10 PDT." <200004241609.JAA11108@gndrsh.dnsmgr.net> Date: Mon, 24 Apr 2000 11:57:44 -0700 Message-ID: <14100.956602664@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules > so every vendor that has ever tried to use them has been bitten by the > fact that they have to maintain N version for each branch of FreeBSD??? Can you list some specific examples? I'm not trying to be a wise-ass, I'm trying to figure out which vendors are using KLDs in general since I've still yet to actually bump into a real-life example of this kind of breakage in the field. I'm not saying that it's never happened, I'm simply saying that I've not seen it and would like some details on such incidents - company name and module type will do fine. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 12: 0:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay02.chello.nl (relay02.chello.nl [212.83.68.146]) by hub.freebsd.org (Postfix) with ESMTP id 210A337BB9F for ; Mon, 24 Apr 2000 12:00:16 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay02.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 99c8f334c649856e3f2cdadc4054e412) with ESMTP id <20000424190006.ZTMJ22628.relay02@chello.nl>; Mon, 24 Apr 2000 21:00:06 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id VAA37178; Mon, 24 Apr 2000 21:00:10 +0200 (CEST) (envelope-from wkb) Date: Mon, 24 Apr 2000 21:00:10 +0200 From: Wilko Bulte To: Richard Wackerbarth Cc: Julian Elischer , current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! Message-ID: <20000424210010.A37127@yedi.wbnet> Reply-To: wc.bulte@chello.nl References: <39041698.15FB7483@elischer.org> <200004241536.LAA33905@khavrinen.lcs.mit.edu> <39046BF1.1CFBAE39@elischer.org> <00042413373504.09404@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <00042413373504.09404@nomad.dataplex.net>; from rkw@dataplex.net on Mon, Apr 24, 2000 at 01:43:44PM -0500 X-OS: FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 01:43:44PM -0500, Richard Wackerbarth wrote: > On Mon, 24 Apr 2000, Julian Elischer wrote: > > > This seems well thought out and I certainly agree that we don't need > > DIFFs of firmware. > > I wonder if we can somehow "cheat time" and get that 13MB file out of > > the source tree and retro-actively tag the new scheme so > > that we don't have to carry it around forever :-) > > It looks like a port, > Smells like a port, > and tastes like a port. > It must be a ..... > > merlot ? > > Seriously, perhaps we should consider putting optional pieces of the kernel Firmware for a SCSI adapter is not optional. At least not on some of the Alpha machines that download out-of-date firmware from their SRMs so depend on the driver to load them with something up-to-date. -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 12: 2:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id E16D537B7E5; Mon, 24 Apr 2000 12:02:20 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id MAA80062; Mon, 24 Apr 2000 12:02:20 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 24 Apr 2000 12:02:20 -0700 (PDT) From: Kris Kennaway To: "David O'Brien" Cc: current@FreeBSD.org Subject: Re: OpenSSL asm optimizations In-Reply-To: <20000424114818.F12417@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, David O'Brien wrote: > On Fri, Apr 21, 2000 at 07:28:28PM -0700, Kris Kennaway wrote: > > patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to > > "i586" or "i686" (both are actually identical at present) and rebuild. > > Please also support "k5" and "k6". Actually it raises the question I was going to frame of how to specify the set of CPU revisions which are compatible. For example, k5 and k6 want i586 optimizations as a fallback (if no k5/6 native optimizations available), k6 wants k5, i586 wants i486 etc. The easiest way I can think of is to specify MACHINE_CPU as a list: e.g. for a k6 it might be "k6 k5 i586 i486 i386" specifying that any of those optimizations should be used. It would be best to make it an ordered list, i.e. in order of preference, but I'll have to think about the implementation implications. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 12: 2:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id DD16537B931 for ; Mon, 24 Apr 2000 12:02:36 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 14:02:28 -0500 From: Richard Wackerbarth To: Bill Fumerola Subject: Re: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 14:02:28 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042404464300.09955@nomad.dataplex.net> <20000424144441.W397@jade.chc-chimes.com> In-Reply-To: <20000424144441.W397@jade.chc-chimes.com> Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <00042414022801.09427@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, you wrote: > On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote: > > >From the USER's perspective, anything that requires me to as much as > > > reload > > > > a module/program that I have already installed "breaks" it. > > The fact that it is only necessary to recompile it in order to fix it > > only means that it is easy to fix IF I have the source code. > > No-one forces you to upgrade you systems. Partial upgrades are something > that are nice when they work, but understood when they don't. > > We don't accept bug reports (typically) when a person hasn't upgraded their > world, kernel, and modules. I don't understand why we're accepting > preemptive bitching. That is also partly why you are also lacking the respect and support of a wider audience. If you act like FreeBSD is just a "developer's sandbox", that's what it will be. If you want it to be something greater than that, you must consider what you are doing to third party developers and end users. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 12: 7:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from PLUTO.forumone.com (host04.forumone.com [207.197.235.4]) by hub.freebsd.org (Postfix) with ESMTP id 7DF6A37BBA8 for ; Mon, 24 Apr 2000 12:07:07 -0700 (PDT) (envelope-from adhir@forumone.com) Received: by PLUTO.forumone.com with Internet Mail Service (5.5.2650.21) id <2GYQATG5>; Mon, 24 Apr 2000 15:07:05 -0400 Message-ID: From: Alok Dhir To: 'Bill Fumerola' , 'Richard Wackerbarth' Cc: 'Matthew Dillon' , "'freebsd-current@FreeBSD.ORG'" Subject: RE: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 15:06:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > No-one forces you to upgrade you systems. Partial upgrades > are something that are > nice when they work, but understood when they don't. > > We don't accept bug reports (typically) when a person hasn't > upgraded their world, > kernel, and modules. I don't understand why we're accepting > preemptive bitching. Very well said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 12: 7:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id CFF8037B7E5 for ; Mon, 24 Apr 2000 12:07:26 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 14:07:22 -0500 From: Richard Wackerbarth To: wc.bulte@chello.nl Subject: Re: asm_pci.h,v Holy cow! Date: Mon, 24 Apr 2000 14:07:22 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: <39041698.15FB7483@elischer.org> <00042413373504.09404@nomad.dataplex.net> <20000424210010.A37127@yedi.wbnet> In-Reply-To: <20000424210010.A37127@yedi.wbnet> Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <00042414072202.09427@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, you wrote: > > Seriously, perhaps we should consider putting optional pieces of the > > kernel > > Firmware for a SCSI adapter is not optional. At least not on some of the > Alpha machines that download out-of-date firmware from their SRMs so depend > on the driver to load them with something up-to-date. Sure it is. I certainly have a fine system without any SCSI adapter. The whole move toward loadable modules is to make the kernel into a "cafeteria" rather than a "blue plate". That firmware is a required part of a particular driver is not in dispute. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 12: 7:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 7E77C37BB1B for ; Mon, 24 Apr 2000 12:07:35 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 088C41C4A; Mon, 24 Apr 2000 15:07:35 -0400 (EDT) Date: Mon, 24 Apr 2000 15:07:35 -0400 From: Bill Fumerola To: Richard Wackerbarth Cc: current@freebsd.org Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000424150734.Y397@jade.chc-chimes.com> References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042404464300.09955@nomad.dataplex.net> <20000424144441.W397@jade.chc-chimes.com> <00042414022801.09427@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00042414022801.09427@nomad.dataplex.net>; from rkw@dataplex.net on Mon, Apr 24, 2000 at 02:02:28PM -0500 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote: > That is also partly why you are also lacking the respect and support of a > wider audience. If you act like FreeBSD is just a "developer's sandbox", > that's what it will be. If you want it to be something greater than that, you > must consider what you are doing to third party developers and end users. Developers and early adopters are the ones tracking -STABLE. Users are installing binary snapshots and releases. No-one in their right mind would release a module for "4.0-STABLE sometime between april and may". They release for 4.0-RELEASE or 4.1-RELEASE, this would not cause problems for those people. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 12: 9:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from PLUTO.forumone.com (host04.forumone.com [207.197.235.4]) by hub.freebsd.org (Postfix) with ESMTP id F2D2437BBAD for ; Mon, 24 Apr 2000 12:09:06 -0700 (PDT) (envelope-from adhir@forumone.com) Received: by PLUTO.forumone.com with Internet Mail Service (5.5.2650.21) id <2GYQATG7>; Mon, 24 Apr 2000 15:09:06 -0400 Message-ID: From: Alok Dhir To: "'Jordan K. Hubbard'" , "'Rodney W. Grimes'" Cc: "'Jacques A . Vidrine'" , 'Richard Wackerbarth' , "'freebsd-current@FreeBSD.ORG'" Subject: RE: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 15:09:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One (relatively minor) example is Open Sound System... http://www.opensound.com/freebsd.html Al > -----Original Message----- > From: owner-freebsd-current@FreeBSD.ORG > [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Jordan > K. Hubbard > Sent: Monday, April 24, 2000 2:58 PM > To: Rodney W. Grimes > Cc: Jacques A . Vidrine; Richard Wackerbarth; > freebsd-current@FreeBSD.ORG > Subject: Re: SMP changes and breaking kld object module compatibility > > > > Gee, is that perhaps because FreeBSD keeps breaking the ABI > to modules > > so every vendor that has ever tried to use them has been > bitten by the > > fact that they have to maintain N version for each branch > of FreeBSD??? > > Can you list some specific examples? I'm not trying to be a wise-ass, > I'm trying to figure out which vendors are using KLDs in general since > I've still yet to actually bump into a real-life example of this kind > of breakage in the field. I'm not saying that it's never happened, > I'm simply saying that I've not seen it and would like some details on > such incidents - company name and module type will do fine. > > - Jordan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 12:19:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144]) by hub.freebsd.org (Postfix) with ESMTP id AA1B437B8E8 for ; Mon, 24 Apr 2000 12:19:29 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay01.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 99c8f334c649856e3f2cdadc4054e412) with ESMTP id <20000424191937.GNQS5152.relay01@chello.nl>; Mon, 24 Apr 2000 21:19:37 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id VAA37394; Mon, 24 Apr 2000 21:19:27 +0200 (CEST) (envelope-from wkb) Date: Mon, 24 Apr 2000 21:19:26 +0200 From: Wilko Bulte To: Richard Wackerbarth Cc: wc.bulte@chello.nl, current@freebsd.org Subject: Re: asm_pci.h,v Holy cow! Message-ID: <20000424211926.B37284@yedi.wbnet> Reply-To: wc.bulte@chello.nl References: <39041698.15FB7483@elischer.org> <00042413373504.09404@nomad.dataplex.net> <20000424210010.A37127@yedi.wbnet> <00042414072202.09427@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <00042414072202.09427@nomad.dataplex.net>; from rkw@dataplex.net on Mon, Apr 24, 2000 at 02:07:22PM -0500 X-OS: FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 02:07:22PM -0500, Richard Wackerbarth wrote: > On Mon, 24 Apr 2000, you wrote: > > > > Seriously, perhaps we should consider putting optional pieces of the > > > kernel > > > > Firmware for a SCSI adapter is not optional. At least not on some of the > > Alpha machines that download out-of-date firmware from their SRMs so depend > > on the driver to load them with something up-to-date. > > Sure it is. I certainly have a fine system without any SCSI adapter. > > The whole move toward loadable modules is to make the kernel into a > "cafeteria" rather than a "blue plate". > > That firmware is a required part of a particular driver is not in dispute. People were writing "port", not "module". For the isp firmware it is in some cases a mandatory part, in some cases a optional part of the driver. Matt can tell you more ;-) -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 13:13: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id D2DF737BBA2; Mon, 24 Apr 2000 13:12:54 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA13091; Mon, 24 Apr 2000 16:12:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id QAA24935; Mon, 24 Apr 2000 16:12:25 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 24 Apr 2000 16:12:24 -0400 (EDT) To: "Jordan K. Hubbard" Cc: Matthew Dillon , "Rodney W. Grimes" , phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <14085.956602557@zippy.cdrom.com> References: <200004240617.XAA66270@apollo.backplane.com> <14085.956602557@zippy.cdrom.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14596.39482.793985.323658@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan K. Hubbard writes: > > So you guys (core) choose -- do you want 4.x to reap the benefits of > > further SMP development or not? > > I've read all the feedback on this thread and now feel that it would > be worthwhile to simply bring the SMP changes in on Wednesday. As others > have pointed out, we don't have enough 3rd party 4.0 klds yet (I'd have > a hard time even saying "any") to make this a real problem so let's > just go for it. Are there any 3rd party NIC klds yet? If we're going to be having a module flag day, I'm thinking that it might be a good time to MFC Jonathan Lemon's checksum offloading code. Doing this would require changing MSIZE to 256, which in turn would require recompiling any module using mbufs (all NICs, network filesystems, etc). Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 13:19:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 817F337BBCE; Mon, 24 Apr 2000 13:19:29 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA14569; Mon, 24 Apr 2000 13:20:16 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Andrew Gallatin Cc: Matthew Dillon , "Rodney W. Grimes" , phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-reply-to: Your message of "Mon, 24 Apr 2000 16:12:24 EDT." <14596.39482.793985.323658@grasshopper.cs.duke.edu> Date: Mon, 24 Apr 2000 13:20:16 -0700 Message-ID: <14566.956607616@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Are there any 3rd party NIC klds yet? NTMK. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 13:51:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.targetnet.com (mail.targetnet.com [207.245.246.3]) by hub.freebsd.org (Postfix) with ESMTP id 110A037BBB4 for ; Mon, 24 Apr 2000 13:51:30 -0700 (PDT) (envelope-from james@targetnet.com) Received: from james by mail.targetnet.com with local (Exim 3.02 #1) id 12jppJ-000LPQ-00 for current@freebsd.org; Mon, 24 Apr 2000 16:51:29 -0400 Date: Mon, 24 Apr 2000 16:51:29 -0400 From: James FitzGibbon To: current@freebsd.org Subject: rndcontrol with > 16 interrupts Message-ID: <20000424165128.G8994@targetnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i Organization: Targetnet.com Inc. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are there any plans to allow rndcontrol to accept greater than 16 interrupts on SMP machines ? On my ASUS XG-DLS board, all the interesting interrupts that I want to use to stir the entropy pool are greater than 16. Examination of sys/i386/i386/mem.c on RELENG_3, RELENG_4 and HEAD all have this comment and code snippet: /* * XXX the data is 16-bit due to a historical botch, so we use * magic 16's instead of ICU_LEN and can't support 24 interrupts * under SMP. */ intr = *(int16_t *)data; if (cmd != MEM_RETURNIRQ && (intr < 0 || intr >= 16)) return (EINVAL); I don't exactly understand what ICU_LEN refers to or if there are technical reasons that we can't support 24 interrupts, but the present situation leaves me with a powerful machine that can't take advantage of /dev/random at all (the pool has so little to feed off of that reads of even small amounts of data block). Can anyone shed some light ? TIA. -- j. James FitzGibbon james@targetnet.com Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 13:52:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AF53637BBE9 for ; Mon, 24 Apr 2000 13:52:31 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA05195; Mon, 24 Apr 2000 13:51:36 -0700 Date: Mon, 24 Apr 2000 13:52:20 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: wc.bulte@chello.nl Cc: Richard Wackerbarth , current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <20000424211926.B37284@yedi.wbnet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Matt can tell you more ;-) People don't really want to know more. They just don't want what I provide support for to impact them. I'll bet if I sum up all the other kernel mathoms like netgraph, and so on, that *I* never use, it'd be less than this f/w...:-) But this isn't the point. The point is to cause less cvsup turbulence for all and sundry. I think I can do enough of this by just splitting the file apart to keep everyone happy. Or happy enough. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 14: 4: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 3453C37BBDD for ; Mon, 24 Apr 2000 14:03:57 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id OAA11668; Mon, 24 Apr 2000 14:03:41 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200004242103.OAA11668@gndrsh.dnsmgr.net> Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <14100.956602664@zippy.cdrom.com> from "Jordan K. Hubbard" at "Apr 24, 2000 11:57:44 am" To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Mon, 24 Apr 2000 14:03:41 -0700 (PDT) Cc: n@nectar.com (Jacques A . Vidrine), rkw@dataplex.net (Richard Wackerbarth), freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules > > so every vendor that has ever tried to use them has been bitten by the > > fact that they have to maintain N version for each branch of FreeBSD??? > > Can you list some specific examples? I'm not trying to be a wise-ass, > I'm trying to figure out which vendors are using KLDs in general since > I've still yet to actually bump into a real-life example of this kind > of breakage in the field. I'm not saying that it's never happened, > I'm simply saying that I've not seen it and would like some details on > such incidents - company name and module type will do fine. I have never been able to keep our ET Inc based routers any where near up to date as far as kernels go, no, they don't use kld's, they use .o's, but it is caused by the same set of problems. I do know from interacting with Dennis at ET Inc that the changes in the interfaces of the FreeBSD kernel have kept him from even trying to be very up to date with driver code. I also have a kld from a source I can't say, to support hardware I can't tell about... (No, this is not a straw man, it's called NDA red tape :-(). -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 14:15:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 69EFB37BC0C for ; Mon, 24 Apr 2000 14:15:06 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id OAA11696; Mon, 24 Apr 2000 14:14:50 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200004242114.OAA11696@gndrsh.dnsmgr.net> Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000424150734.Y397@jade.chc-chimes.com> from Bill Fumerola at "Apr 24, 2000 03:07:35 pm" To: billf@chc-chimes.com (Bill Fumerola) Date: Mon, 24 Apr 2000 14:14:50 -0700 (PDT) Cc: rkw@dataplex.net (Richard Wackerbarth), current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote: > > > That is also partly why you are also lacking the respect and support of a > > wider audience. If you act like FreeBSD is just a "developer's sandbox", > > that's what it will be. If you want it to be something greater than that, you > > must consider what you are doing to third party developers and end users. > > Developers and early adopters are the ones tracking -STABLE. Users are > installing binary snapshots and releases. Some users do install snapshots and/or releases. Snap shots occur on a regular basis and are affected by this change in API. > No-one in their right mind would release a module for "4.0-STABLE sometime > between april and may". They release for 4.0-RELEASE or 4.1-RELEASE, > this would not cause problems for those people. Ahh.. the problem occurs with user Z running snap 4.0-stable 4/30 when trying to use vendor X module for 4.0-release. Get it?? -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 14:19:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id B56A837BBED for ; Mon, 24 Apr 2000 14:19:09 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 8635A1C4A; Mon, 24 Apr 2000 17:19:08 -0400 (EDT) Date: Mon, 24 Apr 2000 17:19:08 -0400 From: Bill Fumerola To: "Rodney W. Grimes" Cc: Richard Wackerbarth , current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000424171908.D397@jade.chc-chimes.com> References: <20000424150734.Y397@jade.chc-chimes.com> <200004242114.OAA11696@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200004242114.OAA11696@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Mon, Apr 24, 2000 at 02:14:50PM -0700 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 02:14:50PM -0700, Rodney W. Grimes wrote: > > Developers and early adopters are the ones tracking -STABLE. Users are > > installing binary snapshots and releases. > > Some users do install snapshots and/or releases. Snap shots occur on a > regular basis and are affected by this change in API. If they use the module from the same snapshot/release, it's not a problem. > > No-one in their right mind would release a module for "4.0-STABLE sometime > > between april and may". They release for 4.0-RELEASE or 4.1-RELEASE, > > this would not cause problems for those people. > > Ahh.. the problem occurs with user Z running snap 4.0-stable 4/30 when trying > to use vendor X module for 4.0-release. Get it?? When the requirements for software are "FooBaz Version 1.2" that means "FooBaz Version 1.2". If the vendor markets software as "FreeBSD version 4.0 or later", that's their problem. The entire point is that somewhere the user has decided to upgrade their system, and they need to know what the consequences are before taking the plunge. If they upgrade their system half-ass (kernel, but not modules) they are digging their own grave. If they have 3rd party modules, they need to understand that those modules may not work if you're tracking changes. That's life. I don't expect my 3rd party voodoo 3000 drivers for Win98 to work in Win2000 either. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 14:29:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id D634D37BC41 for ; Mon, 24 Apr 2000 14:29:29 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 16:29:23 -0500 From: Richard Wackerbarth To: "Rodney W. Grimes" Subject: Re: SMP changes and breaking kld object module compatibility Date: Mon, 24 Apr 2000 16:29:22 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: <200004242114.OAA11696@gndrsh.dnsmgr.net> In-Reply-To: <200004242114.OAA11696@gndrsh.dnsmgr.net> Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <00042416292202.09469@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, you wrote: > > On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote: > > > That is also partly why you are also lacking the respect and support of > > > a wider audience. If you act like FreeBSD is just a "developer's > > > sandbox", that's what it will be. If you want it to be something > > > greater than that, you must consider what you are doing to third party > > > developers and end users. > > > > Developers and early adopters are the ones tracking -STABLE. Users are > > installing binary snapshots and releases. > > Some users do install snapshots and/or releases. Snap shots occur on a > regular basis and are affected by this change in API. > > > No-one in their right mind would release a module for "4.0-STABLE > > sometime between april and may". They release for 4.0-RELEASE or > > 4.1-RELEASE, this would not cause problems for those people. > > Ahh.. the problem occurs with user Z running snap 4.0-stable 4/30 when > trying to use vendor X module for 4.0-release. Get it?? I certainly do. Your "attribute deamon" left out one level of identification. There are two problems here: 1) How often do the interfaces change? IMHO, too often. These sandboxers have no concept of third party issues. 2) How do we identify the version of the interface? Even if we ignore the number of "different interfaces", being able to readily recognize which one a customer has is important. Maybe the developers need to be sentenced to a tour on the customer service lines. It might open their eyes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 15: 2:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id A3CF837BBB4; Mon, 24 Apr 2000 15:02:34 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id PAA11779; Mon, 24 Apr 2000 15:01:34 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200004242201.PAA11779@gndrsh.dnsmgr.net> Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <14566.956607616@zippy.cdrom.com> from "Jordan K. Hubbard" at "Apr 24, 2000 01:20:16 pm" To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Mon, 24 Apr 2000 15:01:34 -0700 (PDT) Cc: gallatin@cs.duke.edu (Andrew Gallatin), dillon@apollo.backplane.com (Matthew Dillon), phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG {First one bounced by hub with ``out of memory'' error... second attempt} > > Are there any 3rd party NIC klds yet? > > NTMK. It's not quite a kld, but ET Inc's modules are distributed as a .o. Also I know of work underway to support some of the fancier SDL WanNic cards that would have to be kld's or .o's as well, due to NDA on parts of the code used to develope them. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 15: 4:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from Kharma.Nextshift.Net (kharma.nextshift.net [216.200.15.16]) by hub.freebsd.org (Postfix) with ESMTP id E065437BC22 for ; Mon, 24 Apr 2000 15:04:28 -0700 (PDT) (envelope-from eric@clickrebates.com) Received: from clickrebates.com (eric@monitor.clickrebates.com [208.184.135.57]) by Kharma.Nextshift.Net (8.9.3/8.9.0) with ESMTP id PAA24078 for ; Mon, 24 Apr 2000 15:04:01 -0700 (PDT) Message-ID: <3904C4F4.A0278A76@clickrebates.com> Date: Mon, 24 Apr 2000 15:04:36 -0700 From: Eric Sabban X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: kernel build broken... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG during the mkdep, I get: ../../kern/kern_linker.c:49: linker_if.h: No such file or directory ../../kern/link_aout.c:45: linker_if.h: No such file or directory ../../kern/link_elf.c:55: linker_if.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/compile/MONITOR. And the compile fails. I can't find linker_if.h anywhere. -eric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 16:55: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B92EA37B72B for ; Mon, 24 Apr 2000 16:54:56 -0700 (PDT) (envelope-from ambrisko@whistle.com) Received: from whistle.com (crab.whistle.com [207.76.205.112]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id QAA51133 for ; Mon, 24 Apr 2000 16:04:11 -0700 (PDT) Received: (from ambrisko@localhost) by whistle.com (8.9.3/8.9.1) id QAA34694 for freebsd-current@freebsd.org; Mon, 24 Apr 2000 16:04:01 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200004242304.QAA34694@whistle.com> Subject: tcsh bug To: freebsd-current@freebsd.org Date: Mon, 24 Apr 2000 16:04:00 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Not to create another argument but tcsh does not appear to be csh :-( With -current as of the weekend. I now have tcsh as the root shell. I noticed something "strange", my history only displays the time, for example dual# history 1 13:42 2 13:42 3 13:42 4 13:42 5 13:42 6 13:43 7 13:43 8 13:43 9 13:43 10 13:43 11 15:35 12 15:35 13 15:36 14 15:37 15 15:37 16 15:39 17 15:39 18 15:39 ... etc ... However, history does work with ! for example on the same machine right after the above history command: dual# !ech echo $SHELL /bin/csh dual# After I did a "make world" I also did a "make distribution" in /usr/src/etc to make sure I had default files. Here is the results of env: dual# env DISPLAY=770z.whistle.com:0.0 PRINTER=lp TERM=xterm PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin MAIL=/var/mail/root BLOCKSIZE=K FTP_PASSIVE_MODE=YES SHELL=/bin/csh HOME=/root LOGNAME=root USER=root HOSTTYPE=FreeBSD VENDOR=intel OSTYPE=FreeBSD MACHTYPE=i386 SHLVL=1 PWD=/root GROUP=wheel HOST=dual REMOTEHOST=192.168.1.30 EDITOR=vi PAGER=more dual# Here is the results from set: dual# set _ env addsuffix argv () cwd /root dirstack /root echo_style bsd edit filec gid 0 group wheel history 100 home /root loginsh mail /var/mail/root owd path (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin /root/bin) prompt dual# prompt2 %R? prompt3 CORRECT>%R (y|n|e|a)? shell /bin/csh shlvl 1 status 0 tcsh 6.09.01 term xterm tty ttyp0 uid 0 user root version tcsh 6.09.01 (Astron) 2000-01-14 (i386-intel-FreeBSD) options 8b,nls,dl,al,sm,rh,color dual# This is from the root login. Please help ... I have trouble remembering what I type and the way I use history is to cut'n'paste via X. It's works and I don't have to remember various things that change when I'm forced to change shell so please no philosophy lessons. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 17:55:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from rtp.tfd.com (rtp.tfd.com [198.79.53.206]) by hub.freebsd.org (Postfix) with ESMTP id 4E29937B85F for ; Mon, 24 Apr 2000 17:54:22 -0700 (PDT) (envelope-from kent@chapel-hill.tfd.com) Received: from chapel-hill.tfd.com (chapel-hill.tfd.com [10.20.0.40]) by rtp.tfd.com (8.9.3/8.9.3) with ESMTP id UAA11554 for ; Mon, 24 Apr 2000 20:40:20 -0400 (EDT) Received: (from kent@localhost) by chapel-hill.tfd.com (8.9.3/8.9.3) id UAA03338 for current@freebsd.org; Mon, 24 Apr 2000 20:39:37 -0400 (EDT) (envelope-from kent) Date: Mon, 24 Apr 2000 20:39:37 -0400 (EDT) From: Kent Hauser Message-Id: <200004250039.UAA03338@chapel-hill.tfd.com> To: current@freebsd.org Subject: current status of pcm ?? Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I've been unable to get audio (mp3 & cdplay) to work on my desktop with a SBLive card or on my laptop (TP 600E). I would *really* like to have IPSec and a working audio cd player on my laptop. I this supposed to work, or am I swimming upstream. Thanks all. Kent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 18:45:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id C855537B66C for ; Mon, 24 Apr 2000 18:45:04 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id UAA35820 for ; Mon, 24 Apr 2000 20:15:46 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Mon, 24 Apr 2000 20:15:45 -0400 (EDT) From: Chuck Robey To: FreeBSD-current@freebsd.org Subject: Archive pruning Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I want to suggest that, once a year, we go thru the cvs archive, and prune away all history more than 3 (or maybe 2, maybe 4) years old. This could be done without too much pain, I think, in a script. The purpose is to put some kind of cap on growth of the FreeBSD source archive. While folks do sometimes go hunting for hugely old materials in the tree, I normally couldn't care less (when browsing) about history that old. Do we really need 5 year old history? ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 18:45:41 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id D944E37B7A0; Mon, 24 Apr 2000 18:45:39 -0700 (PDT) From: "Jonathan M. Bresler" To: dillon@apollo.backplane.com Cc: smp@csn.net, current@FreeBSD.ORG In-reply-to: <200004241719.KAA70893@apollo.backplane.com> (message from Matthew Dillon on Mon, 24 Apr 2000 10:19:33 -0700 (PDT)) Subject: Re: SMP changes and breaking kld object module compatibility Message-Id: <20000425014539.D944E37B7A0@hub.freebsd.org> Date: Mon, 24 Apr 2000 18:45:39 -0700 (PDT) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The network stack is equally easy to make MP-safe. In this case we > have a shared lock to lookup sockets for host/port combinations and > then fine-grained exclusive locks within those sockets. Route table > and other high level operations could in fact remain BGL'd without > interfering with the network stack because the network stack *already* > caches route table lookups. > might it be fair to summarize this as: you locks on data rather than locks on code. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 18:50:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 71B0537B66C for ; Mon, 24 Apr 2000 18:50:40 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (trang.cdrom.com [204.216.28.153]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id SAA38074; Mon, 24 Apr 2000 18:47:29 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id SAA06632; Mon, 24 Apr 2000 18:46:59 -0700 (PDT) (envelope-from obrien) Date: Mon, 24 Apr 2000 18:46:58 -0700 From: "David O'Brien" To: Doug Ambrisko Cc: freebsd-current@freebsd.org Subject: Re: tcsh bug Message-ID: <20000424184658.A6327@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200004242304.QAA34694@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004242304.QAA34694@whistle.com>; from ambrisko@whistle.com on Mon, Apr 24, 2000 at 04:04:00PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 04:04:00PM -0700, Doug Ambrisko wrote: > With -current as of the weekend. I now have tcsh as the root shell. > I noticed something "strange", my history only displays the time, for example Known problem. Will be fixed in a few days. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 18:51:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2611B37BC5C for ; Mon, 24 Apr 2000 18:51:20 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA06192; Mon, 24 Apr 2000 18:46:50 -0700 Date: Mon, 24 Apr 2000 18:47:35 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Chuck Robey Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Chuck Robey wrote: > I want to bring up a suggestion. I just want a little bit of argument on > it ... and if you're violently opposed, just say so, that's fine. > > I want to suggest that, once a year, we go thru the cvs archive, and prune > away all history more than 3 (or maybe 2, maybe 4) years old. This could > be done without too much pain, I think, in a script. The purpose is to > put some kind of cap on growth of the FreeBSD source archive. While folks > do sometimes go hunting for hugely old materials in the tree, I normally > couldn't care less (when browsing) about history that old. > > Do we really need 5 year old history? Yes, to avoid Santayana's curse. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 18:51:57 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 4AC4237BCB9; Mon, 24 Apr 2000 18:51:51 -0700 (PDT) Date: Mon, 24 Apr 2000 18:51:51 -0700 From: David O'Brien To: Chuck Robey Cc: FreeBSD-current@freebsd.org Subject: Re: Archive pruning Message-ID: <20000424185151.A36672@hub.freebsd.org> Reply-To: obrien@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Chuck Robey on Mon, Apr 24, 2000 at 08:15:45PM -0400 X-Operating-System: FreeBSD 3.4-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote: > I want to bring up a suggestion. I just want a little bit of argument on > it ... and if you're violently opposed, just say so, that's fine. I'm "violently opposed". :-) > While folks do sometimes go hunting for hugely old materials in the > tree, I've often traced files back to the begining of FreeBSD time (and then continued in the CSRG SCCS tree). I've done this numerious times, especially the contributed sources like GCC and GNU grep. > Do we really need 5 year old history? Yes. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:11:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 6F85E37BC4E for ; Mon, 24 Apr 2000 19:11:37 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id WAA59169; Mon, 24 Apr 2000 22:07:02 -0400 (EDT) Date: Mon, 24 Apr 2000 22:07:02 -0400 (EDT) From: "Matthew N. Dodd" To: Bill Fumerola Cc: "Rodney W. Grimes" , Richard Wackerbarth , current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000424171908.D397@jade.chc-chimes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Bill Fumerola wrote: > The entire point is that somewhere the user has decided to upgrade > their system, and they need to know what the consequences are before > taking the plunge. If they upgrade their system half-ass (kernel, but > not modules) they are digging their own grave. More to the point, until the module versioning and dependency stuff hits the tree, KLD modules remain a useful novelty. I wouldn't consider them to be at all appropriate for production systems right now. The only reliable way to insure that a given module works with a given kernel is to build them from the same source tree at the same time. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:16: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id EC52337B71A for ; Mon, 24 Apr 2000 19:15:57 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime.exit.com [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id TAA84763; Mon, 24 Apr 2000 19:11:32 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.3) id TAA01087; Mon, 24 Apr 2000 19:11:31 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200004250211.TAA01087@realtime.exit.com> Subject: Re: Archive pruning In-Reply-To: from Chuck Robey at "Apr 24, 2000 08:15:45 pm" To: Chuck Robey Date: Mon, 24 Apr 2000 19:11:31 -0700 (PDT) Cc: FreeBSD-current@FreeBSD.ORG Reply-To: frank@exit.com Organization: Exit Consulting X-Copyright0: Copyright 2000 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > I want to bring up a suggestion. I just want a little bit of argument on > it ... and if you're violently opposed, just say so, that's fine. Okay: "so." :-) > Do we really need 5 year old history? Well, unfortunately (and I speak from painful experience), yes. You never know what history is going to be needed to understand _this_ particular change introduced in _this_ six-year-old revision in code that hasn't been touched since, and that either needs to be changed to fit a new way of doing things or that has a bug in a path that has apparently never been taken, ever before. Hell, some of _my_ code (in my current project) is six years old, and I have only a dim memory of having written it, much less why I wrote it that way in the first place. (Somewhere floating around at a certain university is code I wrote long ago that would be approaching drinking age were it a human being. _It_ probably needs history, too, and doesn't have it. Fortunately, that's Not My Problem. :-) The more history, unfortunately for the disk space needs of all of us keeping copies of the repository, the better. -- Frank Mayhar frank@exit.com http://www.exit.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:17:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 737DB37B71A; Mon, 24 Apr 2000 19:17:29 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id WAA05076; Mon, 24 Apr 2000 22:06:43 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Mon, 24 Apr 2000 22:06:42 -0400 (EDT) From: Chuck Robey To: "David O'Brien" Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <20000424185151.A36672@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, David O'Brien wrote: > On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote: > > I want to bring up a suggestion. I just want a little bit of argument on > > it ... and if you're violently opposed, just say so, that's fine. > > I'm "violently opposed". :-) > > > While folks do sometimes go hunting for hugely old materials in the > > tree, > > I've often traced files back to the begining of FreeBSD time (and then > continued in the CSRG SCCS tree). I've done this numerious times, > especially the contributed sources like GCC and GNU grep. > > > Do we really need 5 year old history? > > Yes. OK. Thanks, I wanted some opinions, and I guess I have enough to satisfy me. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:21:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E658537B68A for ; Mon, 24 Apr 2000 19:21:16 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e3P2k0K18203; Mon, 24 Apr 2000 19:46:00 -0700 (PDT) Date: Mon, 24 Apr 2000 19:46:00 -0700 From: Alfred Perlstein To: Chuck Robey Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000424194600.A14712@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from chuckr@picnic.mat.net on Mon, Apr 24, 2000 at 08:15:45PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Chuck Robey [000424 19:15] wrote: > I want to bring up a suggestion. I just want a little bit of argument on > it ... and if you're violently opposed, just say so, that's fine. > > I want to suggest that, once a year, we go thru the cvs archive, and prune > away all history more than 3 (or maybe 2, maybe 4) years old. This could > be done without too much pain, I think, in a script. The purpose is to > put some kind of cap on growth of the FreeBSD source archive. While folks > do sometimes go hunting for hugely old materials in the tree, I normally > couldn't care less (when browsing) about history that old. > > Do we really need 5 year old history? Yes. However, I would really like to see a pruned REPO available that carried perhaps the last 3 years of history, perhaps one running off the freebsd cluster. If it became popular enough several of the cvsup mirrors could adopt it. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:29:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id EAA7637B545; Mon, 24 Apr 2000 19:29:43 -0700 (PDT) (envelope-from ambrisko@whistle.com) Received: from whistle.com (crab.whistle.com [207.76.205.112]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA55946; Mon, 24 Apr 2000 19:05:14 -0700 (PDT) Received: (from ambrisko@localhost) by whistle.com (8.9.3/8.9.1) id TAA26824; Mon, 24 Apr 2000 19:05:06 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200004250205.TAA26824@whistle.com> Subject: Re: tcsh bug In-Reply-To: <20000424184658.A6327@dragon.nuxi.com> from "David O'Brien" at "Apr 24, 2000 06:46:58 pm" To: obrien@freebsd.org Date: Mon, 24 Apr 2000 19:05:06 -0700 (PDT) Cc: Doug Ambrisko , freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien writes: | On Mon, Apr 24, 2000 at 04:04:00PM -0700, Doug Ambrisko wrote: | > With -current as of the weekend. I now have tcsh as the root shell. | > I noticed something "strange", my history only displays the time, for example | | Known problem. Will be fixed in a few days. Thanks, let me know when it should be okay. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:31: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id C6FE337B737 for ; Mon, 24 Apr 2000 19:31:00 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: Network Richmond, LLC. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id VAA48134; Mon, 24 Apr 2000 21:07:20 -0400 (EDT) Date: Mon, 24 Apr 2000 21:07:20 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: Kent Hauser Cc: current@freebsd.org Subject: Re: current status of pcm ?? In-Reply-To: <200004250039.UAA03338@chapel-hill.tfd.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Kent Hauser wrote: > > Hi all, > > I've been unable to get audio (mp3 & cdplay) to work on my desktop > with a SBLive card or on my laptop (TP 600E). I would *really* like > to have IPSec and a working audio cd player on my laptop. I this > supposed to work, or am I swimming upstream. > > Thanks all. > Kent > > Search the mailing list archives for "emu10k1" and you'll find a HOWTO for using the (experimental) emu10k1 drivers, which provide support for the SBLive card and others, with 4.0. Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:35:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 1557437BC33 for ; Mon, 24 Apr 2000 19:35:08 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 20:59:48 -0500 From: Richard Wackerbarth To: Chuck Robey Subject: Re: Archive pruning Date: Mon, 24 Apr 2000 20:59:46 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: In-Reply-To: Cc: FreeBSD-current@FreeBSD.ORG MIME-Version: 1.0 Message-Id: <00042420594601.09767@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Chuck Robey wrote: > I want to bring up a suggestion. I just want a little bit of argument on > it ... and if you're violently opposed, just say so, that's fine. > > I want to suggest that, once a year, we go thru the cvs archive, and prune > away all history more than 3 (or maybe 2, maybe 4) years old. This could > be done without too much pain, I think, in a script. The purpose is to > put some kind of cap on growth of the FreeBSD source archive. While folks > do sometimes go hunting for hugely old materials in the tree, I normally > couldn't care less (when browsing) about history that old. > > Do we really need 5 year old history? a) yes, we need the history. b) do we need it "online everywhere"? I think the answer is "no". However the sandbox engineers think differently. c) I've brought this up more than once. Do "they" care? ??? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:35:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 3B5D237BEC0; Mon, 24 Apr 2000 19:35:11 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 21:07:04 -0500 From: Richard Wackerbarth To: obrien@FreeBSD.ORG Subject: Re: Archive pruning Date: Mon, 24 Apr 2000 21:07:03 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: <20000424185151.A36672@hub.freebsd.org> In-Reply-To: <20000424185151.A36672@hub.freebsd.org> Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <00042421070302.09767@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, you wrote: > On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote: > > I want to bring up a suggestion. I just want a little bit of argument on > > it ... and if you're violently opposed, just say so, that's fine. > > I'm "violently opposed". :-) > > > While folks do sometimes go hunting for hugely old materials in the > > tree, > > I've often traced files back to the begining of FreeBSD time (and then > continued in the CSRG SCCS tree). I've done this numerious times, > especially the contributed sources like GCC and GNU grep. > > > Do we really need 5 year old history? > > Yes. I don't disagree that we need to maintain the history. I do, however, question the policy that REQUIRES EVERYONE to maintain that much history. The CPU's use L1, L2, MM, HD cache hierarchies. The public libraries have a few months issues of a periodical in each branch library. They also have years of them in the main archives. FreeBSD developers know a better way to manage information??? :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:38:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id DC22C37BD09; Mon, 24 Apr 2000 19:38:50 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id WAA37098; Mon, 24 Apr 2000 22:38:43 -0400 (EDT) (envelope-from wollman) Date: Mon, 24 Apr 2000 22:38:43 -0400 (EDT) From: Garrett Wollman Message-Id: <200004250238.WAA37098@khavrinen.lcs.mit.edu> To: Chuck Robey Cc: "David O'Brien" , FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: References: <20000424185151.A36672@hub.freebsd.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > OK. Thanks, I wanted some opinions, and I guess I have enough to satisfy > me. I'd like to add that it can be particularly important when legal questions arise. Should some submarine patent cover parts of FreeBSD's practice, it will turn out to be extremely important to be able to document (through the revision history) precisely when the technique under question appeared. Similarly, when Berkeley was defending the USL suit, they needed to make use of the revision history to document their reimplementation process. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:38:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 4BB7E37BBB4 for ; Mon, 24 Apr 2000 19:38:55 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id WAA59179; Mon, 24 Apr 2000 22:07:51 -0400 (EDT) Date: Mon, 24 Apr 2000 22:07:51 -0400 (EDT) From: "Matthew N. Dodd" To: Chuck Robey Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Chuck Robey wrote: > Do we really need 5 year old history? Yes. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:44: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 5B81A37B737 for ; Mon, 24 Apr 2000 19:44:02 -0700 (PDT) (envelope-from bandix@looksharp.net) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id WAA30227; Mon, 24 Apr 2000 22:44:16 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Mon, 24 Apr 2000 22:44:16 -0400 (EDT) From: "Brandon D. Valentine" To: Kenneth Wayne Culver Cc: "Jeroen C. van Gelderen" , Richard Wackerbarth , Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote: >I believe that it depends on what changes were made since the last >recompile, although it is good practice to at least recompile the modules >when the kernel is recompiled. In my opinion the best way to handle things like this is to add a modules target to the kernel Makefile which would call src/sys/modules/Makefile and allow users who would perhaps never venture into src/sys except when heading straight for src/sys/i386/conf to easily update their modules. It makes little sense to have modules under src/sys and in the src-sys collection if the only time they are routinely rebuilt is through a complete make world. Isn't the idea of having a seperate Makefile for src/sys so that *all* kernel level code can be recompiled and/or updated without the user having to possess all of src or knowledge of the world process? I know I'm not the first person to raise the issue, but I don't think I should be the last either. I think it's a sound architectual decision and 100% inline with FreeBSD's commitment to accomodate users of all skill levels. Brandon D. Valentine -- bandix@looksharp.net Illegitimi non carborundum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:53:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by hub.freebsd.org (Postfix) with ESMTP id 0929537BD8F for ; Mon, 24 Apr 2000 19:53:33 -0700 (PDT) (envelope-from nate@nomad.yogotech.com) Received: from nomad.yogotech.com (mvdhcp141236.americas.nokia.com [172.18.141.236]) by mgw-x1.nokia.com (8.9.3/8.9.3) with ESMTP id FAA07024; Tue, 25 Apr 2000 05:53:29 +0300 (EETDST) X-Authentication-Warning: mgw-x1.nokia.com: Host mvdhcp141236.americas.nokia.com [172.18.141.236] claimed to be nomad.yogotech.com Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id UAA09084; Mon, 24 Apr 2000 20:53:26 -0600 (MDT) (envelope-from nate) Date: Mon, 24 Apr 2000 20:53:26 -0600 (MDT) Message-Id: <200004250253.UAA09084@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chuck Robey Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I want to bring up a suggestion. I just want a little bit of argument on > it ... and if you're violently opposed, just say so, that's fine. > > I want to suggest that, once a year, we go thru the cvs archive, and prune > away all history more than 3 (or maybe 2, maybe 4) years old. I'm violently opposed to removing it completely. The only thing I wouldn't be violently opposed to would be removing 'Attic' files (truly unused file), and having them stored away somewhere in the tree for archival purposes. As far as removing old revisions from files, I'm even more violently opposed to this. > This could > be done without too much pain, I think, in a script. The purpose is to > put some kind of cap on growth of the FreeBSD source archive. While folks > do sometimes go hunting for hugely old materials in the tree, I normally > couldn't care less (when browsing) about history that old. I quite often browse the source code in the tree, in particular I look through the network code at how it's been modified over the years. Also, I often-times go through the history. > Do we really need 5 year old history? Need? As far as needs go, we don't need anything but the most recent versions. This is how Linux was developed for years, and it's a nightmare. The revisions take up very little space, and anyone capable and willing to look through the history shouldn't mind having to see the history of the file. Heck, that's one of the big upsides to using source-code control. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:53:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 4F3B437BD0F for ; Mon, 24 Apr 2000 19:53:36 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id EFF241C65; Mon, 24 Apr 2000 22:53:35 -0400 (EDT) Date: Mon, 24 Apr 2000 22:53:35 -0400 From: Bill Fumerola To: Richard Wackerbarth Cc: Chuck Robey , FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000424225335.F397@jade.chc-chimes.com> References: <00042420594601.09767@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00042420594601.09767@nomad.dataplex.net>; from rkw@dataplex.net on Mon, Apr 24, 2000 at 08:59:46PM -0500 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 08:59:46PM -0500, Richard Wackerbarth wrote: > > Do we really need 5 year old history? > a) yes, we need the history. > b) do we need it "online everywhere"? > I think the answer is "no". However the sandbox engineers think differently. > c) I've brought this up more than once. Do "they" care? Normally "we" stop caring when we see your name in the From: header. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 19:54:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id EDB8D37BFAE for ; Mon, 24 Apr 2000 19:54:48 -0700 (PDT) (envelope-from bandix@looksharp.net) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id WAA30335; Mon, 24 Apr 2000 22:55:05 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Mon, 24 Apr 2000 22:55:05 -0400 (EDT) From: "Brandon D. Valentine" To: "Daniel C. Sobral" Cc: Alok Dhir , "'Richard Wackerbarth'" , "'Matthew Dillon'" , "'freebsd-current@FreeBSD.ORG'" Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <3904693F.ED9C5FA6@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Daniel C. Sobral wrote: >Because if we do not provide a STABLE ABI, we WON'T get third-party >(binary only) kernel modules. > >I'm very divided in this issue. 4.x has just started, and would be >seriously impaired if no further improvements to it's SMP get in. On >the other hand, if we can't garantee third party vendors a stable ABI, >we won't get third party vendors. The number one excuse large third party server vendors use to justify use of NT over Linux on their high end SMP systems is the poor performance of Linux SMP. This is a tremendous opportunity for FreeBSD to take market share. People are seeing the virtues of free, open source operating systems in the server farm and providing top notch SMP support in FreeBSD will help to see that we make further inroads that the Linux guys do. If the BSDi code assists us in improving SMP performance and if the corporate backing helps our PR image, then we could be in for a fun ride. This is the time to start thinking in terms of "What can we do better?" or we're going to lose the battle. Sure, those changes could go into 5.x and be released when RELENG_5 is branched a year from now. But in this business, a year is 6 months too late. Think about that before you object to what appear to be vast improvements in the performance of the RELENG_4 branch while it is just getting off the ground. Brandon D. Valentine -- bandix@looksharp.net Illegitimi non carborundum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 20: 9:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 6242937BD0E for ; Mon, 24 Apr 2000 20:09:27 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Mon, 24 Apr 2000 22:09:14 -0500 From: Richard Wackerbarth To: Garrett Wollman Subject: Re: Archive pruning Date: Mon, 24 Apr 2000 22:09:14 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: <20000424185151.A36672@hub.freebsd.org> <200004250238.WAA37098@khavrinen.lcs.mit.edu> In-Reply-To: <200004250238.WAA37098@khavrinen.lcs.mit.edu> Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <00042422091401.16303@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, you wrote: > I'd like to add that it can be particularly important when legal > questions arise. You confuse the argument for SOME complete repositories with the necessity that ALL (or at each most) repositories be so extensive. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 20:21:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from chai.torrentnet.com (chai.torrentnet.com [198.78.51.73]) by hub.freebsd.org (Postfix) with ESMTP id A3F0637B509 for ; Mon, 24 Apr 2000 20:21:21 -0700 (PDT) (envelope-from bakul@torrentnet.com) Received: from chai.torrentnet.com (localhost [127.0.0.1]) by chai.torrentnet.com (8.8.8/8.8.5) with ESMTP id XAA29758; Mon, 24 Apr 2000 23:21:11 -0400 (EDT) Message-Id: <200004250321.XAA29758@chai.torrentnet.com> To: Chuck Robey Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-reply-to: Your message of "Mon, 24 Apr 2000 20:15:45 EDT." Date: Mon, 24 Apr 2000 23:21:11 -0400 From: Bakul Shah Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Do we really need 5 year old history? That really depends on your point of view. "Those who cannot remember the past are condemned to repeat it" -- Santayana "The only thing we learn from history is that we learn nothing from history." -- Hegel I am with Hegel in the very long term but what is the rush about pruning? Set a cron job to ask this in the year 2037! In the short term it is valuable to trace back the genesis of various features/bugs. With cvs annotate you can even find out who put in a feature or bug and bug that person about it (as I was just this past week about something I had written over four years back). The networking code is so convoluted that having all the history (which we don't) can be very valuable in unravelling all the development strands. -- bakul PS: Of course, having a complete history is not the same as reading and remembering it all but at least you have a chance.... What is missing is a tool that to easily browse through old revisions (tkdiff is nice but not enough). If such a tool were available there would be many source code historians! PPS: We should have a complete history *somewhere*. You are of course free to extend cvsup to prune so that *you* don't have to keep it all. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 20:38:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id D3CF337BCDF for ; Mon, 24 Apr 2000 20:37:54 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id XAA10863; Mon, 24 Apr 2000 23:36:11 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Mon, 24 Apr 2000 23:36:10 -0400 (EDT) From: Chuck Robey To: Bakul Shah Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <200004250321.XAA29758@chai.torrentnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Bakul Shah wrote: > > Do we really need 5 year old history? > > That really depends on your point of view. > > "Those who cannot remember the past are condemned to repeat it" > -- Santayana > > "The only thing we learn from history is that we learn nothing from history." > -- Hegel > > I am with Hegel in the very long term but what is the rush > about pruning? Set a cron job to ask this in the year 2037! > In the short term it is valuable to trace back the genesis of > various features/bugs. With cvs annotate you can even find > out who put in a feature or bug and bug that person about it > (as I was just this past week about something I had written > over four years back). The networking code is so convoluted > that having all the history (which we don't) can be very > valuable in unravelling all the development strands. Well, I wasn't talking about a harsh pruning, but I haven't seen much support for the idea, so maybe it better drop. The idea came when I was making room for vmware ... boy, I wish that the new generation of 18G Ultra160 disks would come out already ... the only reasonably priced one is the Seagate, but it could be aptly nicknamed the "data furnace" from just how hot it runs. I need more disk! ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 20:49:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0298037BCA3 for ; Mon, 24 Apr 2000 20:49:25 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id XAA37420; Mon, 24 Apr 2000 23:49:16 -0400 (EDT) (envelope-from wollman) Date: Mon, 24 Apr 2000 23:49:16 -0400 (EDT) From: Garrett Wollman Message-Id: <200004250349.XAA37420@khavrinen.lcs.mit.edu> To: Richard Wackerbarth Cc: current@freebsd.org Subject: Re: Archive pruning In-Reply-To: <00042422091401.16303@nomad.dataplex.net> References: <20000424185151.A36672@hub.freebsd.org> <200004250238.WAA37098@khavrinen.lcs.mit.edu> <00042422091401.16303@nomad.dataplex.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > You confuse the argument for SOME complete repositories with > the necessity that ALL (or at each most) repositories be so extensive. You're welcome to remove whatever history you like from your personal copy. It's not worth the effort to the project as a whole to save a small amount of disk space. The CVS tree is currently 843 Mbytes, complete. Storage cost (even if you buy SCSI disks) is about $16. With cheap disks, that's about $6. The time it took me to do the research for this paragraph is worth more than that! -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 21:10:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by hub.freebsd.org (Postfix) with ESMTP id F08C537B513 for ; Mon, 24 Apr 2000 21:10:53 -0700 (PDT) (envelope-from atrens@nortelnetworks.com) Received: from zmers013 by smtprtp.ntcom.nortel.net; Tue, 25 Apr 2000 00:07:40 -0400 Received: from hcarp00g.ca.nortel.com by zmers013; Tue, 25 Apr 2000 00:07:21 -0400 Received: from hcarp00g.ca.nortel.com (hcarp00g.ca.nortel.com [47.196.31.114]) by hcarp00g.ca.nortel.com (8.9.3/8.7.3) with ESMTP id AAA03829 for ; Tue, 25 Apr 2000 00:09:22 -0400 (EDT) Date: Tue, 25 Apr 2000 00:09:22 -0400 (EDT) From: "Andrew Atrens" X-Sender: atrens@hcarp00g.ca.nortel.com Reply-To: "Andrew Atrens" To: current@freebsd.org Subject: apm halts my system during start up. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The message says it all - my system does the equivalent of a 'halt -p' upon launching `apm' during boot up - ... acd0: CD-RW at ata0-master using PIO3 acd1: CDROM at ata0-slave using UDMA33 Waiting 2 seconds for SCSI devices to settle pass0 at ahc0 bus 0 target 6 lun 0 pass0: < scanner 636EL 1.40> Fixed Scanner SCSI-2 device pass0: 3.300MB/s transfers Mounting root from ufs:/dev/ad0a ed0: starting DAD for fe80:0001::0240:05ff:fe59:30f0 ed0: DAD complete for fe80:0001::0240:05ff:fe59:30f0 - no duplicates found restarted Waiting (max 60 seconds) for system process `bufdaemon' to stop... stopped Waiting (max 60 seconds) for system process `syncer' to stop... ... Since I'm not using apm for anything in particular, I just took it out of the loop, so to speak. Here's a full startup (sans apm) - Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Mon Apr 24 10:33:38 EDT 2000 atrens@churchill:/usr/local/src/cvs/sys/compile/CHURCHILL Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (604.23-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x621 Stepping = 1 Features=0x183f9ff AMD Features=0xc0400000 real memory = 201261056 (196544K bytes) avail memory = 191688704 (187196K bytes) Preloaded elf kernel "kernel" at 0xc03cf000. VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc0352497 (1000117) VESA: 3dfx Interactive, Inc. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: <3Dfx Voodoo 3 graphics accelerator> at 5.0 irq 11 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 chip1: at device 4.4 on pci0 atapci1: port 0xcc00-0xcc3f,0xd000-0xd003,0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07 mem 0xeffe0000-0xefffffff irq 11 at device 13.0 on pci0 ata2: at 0xdc00 on atapci1 ahc0: port 0xc400-0xc4ff mem 0xeffcf000-0xeffcffff irq 10 at device 14.0 on pci0 ahc0: aic7850 Single Channel A, SCSI Id=7, 3/255 SCBs ahc0: Host Adapter Bios disabled. Using default SCSI device parameters ed0: port 0xc000-0xc01f irq 9 at device 15.0 on pci0 ed0: supplying EUI64: 00:40:05:ff:fe:59:30:f0 ed0: address 00:40:05:59:30:f0, type NE2000 (16 bit) pcm0: port 0xbc00-0xbc3f irq 5 at device 16.0 on pci0 fdc0: 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 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 5 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port unknown0: at iomem 0-0x9fbff,0x9fc00-0x9ffff,0xf0000-0xfffff,0x100000-0xbfeffff,0xbff0000-0xbff7fff,0xbff8000-0xbffffff,0xffff0000-0xffffffff on isa0 unknown: can't assign resources unknown1: at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown2: at port 0x40-0x43 irq 0 on isa0 unknown3: at port 0x70-0x71 irq 8 on isa0 unknown: can't assign resources unknown4: at port 0x61 on isa0 unknown5: at port 0xf0-0xff irq 13 on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown6: at port 0x22,0x72-0x75,0x294-0x297,0x400-0x40f,0x4d0-0x4d1,0xcf8-0xcff,0x800-0x87f on isa0 unknown: can't assign resources IPsec: Initialized Security Association Processing. ad0: 13072MB [26559/16/63] at ata2-master using UDMA66 ad1: 8063MB [16383/16/63] at ata2-slave using UDMA66 acd0: CD-RW at ata0-master using PIO3 acd1: CDROM at ata0-slave using UDMA33 Waiting 2 seconds for SCSI devices to settle pass0 at ahc0 bus 0 target 6 lun 0 pass0: < scanner 636EL 1.40> Fixed Scanner SCSI-2 device pass0: 3.300MB/s transfers Mounting root from ufs:/dev/ad0a ed0: starting DAD for fe80:0001::0240:05ff:fe59:30f0 ed0: DAD complete for fe80:0001::0240:05ff:fe59:30f0 - no duplicates found /dev/vmmon: Module vmmon: registered with major=200 minor=0 tag=$Name: build-438 $ /dev/vmmon: Module vmmon: initialized vmnet1: not multicast capable, IPv6 not enabled -- +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Berkeley had what we called "copycenter", which is "take it down to the copy center and make as many copies as you want". -- Kirk McKusick +-- --+ Bill Gates is a white Persian cat and a monocle away from becoming another James Bond villain. "No Mr Bond, I expect you to upgrade." -- Dennis Miller +-- --+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 21:15: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from blues.jpj.net (blues.jpj.net [204.97.17.146]) by hub.freebsd.org (Postfix) with ESMTP id 41F8D37B512 for ; Mon, 24 Apr 2000 21:14:59 -0700 (PDT) (envelope-from trevor@jpj.net) Received: from localhost (trevor@localhost) by blues.jpj.net (right/backatcha) with ESMTP id e3P4Etn01244; Tue, 25 Apr 2000 00:14:55 -0400 (EDT) Date: Tue, 25 Apr 2000 00:14:55 -0400 (EDT) From: Trevor Johnson To: Eric Sabban Cc: current@FreeBSD.ORG Subject: Re: kernel build broken... In-Reply-To: <3904C4F4.A0278A76@clickrebates.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > during the mkdep, I get: > > ../../kern/kern_linker.c:49: linker_if.h: No such file or directory > ../../kern/link_aout.c:45: linker_if.h: No such file or directory > ../../kern/link_elf.c:55: linker_if.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/src/sys/compile/MONITOR. > > > And the compile fails. I can't find linker_if.h anywhere. Hi, Eric. I noticed that too, but it's fixed now (for me anyway). I see this in the commit logs: obrien 2000/04/24 16:08:25 PDT Modified files: sys/conf files Log: Add linker_if.m to the mix. Revision Changes Path 1.359 +2 -1 src/sys/conf/files -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 21:38:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C74EA37B7FA for ; Mon, 24 Apr 2000 21:38:06 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id OAA30767; Tue, 25 Apr 2000 14:37:26 +1000 Date: Tue, 25 Apr 2000 14:37:23 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: "Rodney W. Grimes" Cc: "Jacques A . Vidrine" , Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <200004241609.JAA11108@gndrsh.dnsmgr.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Rodney W. Grimes wrote: > > On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote: > > Are all modules effected, or only those that use certain interfaces? > > Given that this is a change in splxxx() I suspect that it breaks > most modules, but probably not all modules. A quick grep -l spl * | wc Given that this is a change in the splxxx() implementation, it breaks zero modules. splxxx() was changed from an inline function to an ordinary function when SMP development started, to give the same ABI for the SMP case as for the non-SMP case. This gives the same ABI for different SMP implementations as a side effect. I've thought of bringing back some of the spl inlines. The module ABI problem can be handled in the same way as in -- use ordinary functions for modules. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 21:41:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgw00.execpc.com (mailgw00.execpc.com [169.207.1.78]) by hub.freebsd.org (Postfix) with ESMTP id D93A037B5B0; Mon, 24 Apr 2000 21:41:51 -0700 (PDT) (envelope-from hamilton@pobox.com) Received: from woodstock.monkey.net (ferengal-1-103.mdm.mke.execpc.com [169.207.128.103]) by mailgw00.execpc.com (8.9.1) id XAA26523; Mon, 24 Apr 2000 23:41:42 -0500 Received: from pobox.com (localhost [127.0.0.1]) by woodstock.monkey.net (Postfix) with ESMTP id 066A7156; Mon, 24 Apr 2000 23:44:15 -0500 (CDT) X-Mailer: exmh version 2.1.1 10/16/1999 To: Richard Wackerbarth Cc: obrien@freebsd.org, current@freebsd.org Subject: Re: Archive pruning In-reply-to: Your message of "Mon, 24 Apr 2000 21:07:03 CDT." <00042421070302.09767@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Apr 2000 23:44:14 -0500 From: Jon Hamilton Message-Id: <20000425044415.066A7156@woodstock.monkey.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <00042421070302.09767@nomad.dataplex.net>, Richard Wackerbarth wrote } > > Do we really need 5 year old history? } > } > Yes. } I don't disagree that we need to maintain the history. } } I do, however, question the policy that REQUIRES EVERYONE to maintain that } much history. I've been following this thread at some distance for a while, and I don't understand your definition of ``everyone''. Aside from developers, who do you feel is a good candidate to track the entire CVS repository, rather than using CVSUP or some other method to get only the tree they are interested in? I'm not trying to be snide; it's possible that I'm missing some element of your argument, but I think using the term ``everyone'' is overstating the case considerably. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 21:56:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.115.5]) by hub.freebsd.org (Postfix) with ESMTP id 4D54337BC45 for ; Mon, 24 Apr 2000 21:56:48 -0700 (PDT) (envelope-from matey@cis.ohio-state.edu) Received: from alpha.cis.ohio-state.edu (matey@alpha.cis.ohio-state.edu [164.107.112.15]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id AAA03479 for ; Tue, 25 Apr 2000 00:56:47 -0400 (EDT) Received: (from matey@localhost) by alpha.cis.ohio-state.edu (8.9.1/8.9.1) id AAA05808 for freebsd-current@freebsd.org; Tue, 25 Apr 2000 00:57:08 -0400 (EDT) Date: Tue, 25 Apr 2000 00:56:37 -0400 From: Alexander Matey To: freebsd-current@freebsd.org Subject: buildworld broken Message-ID: <20000425005637.A45146@cis.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Cvsupped 2 hours ago: ... ===> sys/modules/syscons/fire @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/syscons/fire/.. -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/syscons/fire/fire_saver.c /usr/src/sys/modules/syscons/fire/fire_saver.c:44: machine/random.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/syscons/fire. *** Error code 1 Stop in /usr/src/sys/modules/syscons. *** Error code 1 Did this break it? : obrien 2000/04/24 10:30:08 PDT Modified files: sys/conf files files.i386 sys/dev/syscons syscons.c sys/i386/i386 machdep.c mem.c sys/i386/isa/pcvt pcvt_hdr.h sys/i4b/layer2 i4b_tei.c sys/i4b/layer4 i4b_l4mgmt.c sys/kern kern_random.c sys/net if_spppsubr.c sys/netipx ipx_input.c Removed files: sys/i386/isa random_machdep.c sys/i386/include random.h Log: * Use sys/sys/random.h rather than a i386 specific one. * There was nothing that should be machine dependant about i386/isa/random_machdep.c, so it is now sys/kern/kern_random.c. -- lx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 22: 7:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id C51AA37BD97; Mon, 24 Apr 2000 22:07:27 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id OAA29803; Tue, 25 Apr 2000 14:36:41 +0930 (CST) Date: Tue, 25 Apr 2000 14:36:41 +0930 From: Greg Lehey To: Doug Rabson Cc: FreeBSD Committers , FreeBSD current users Subject: Re: Remote serial gdb is broken in -CURRENT. Message-ID: <20000425143641.J26934@freebie.lemis.com> References: <20000423154307.L4675@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote: > On Sun, 23 Apr 2000, Greg Lehey wrote: > >> In the last few days, my remote serial gdb has almost completely >> stopped working. Previously I had (almost) no trouble at 38400 bps; >> now I can barely get a response at all at 9600 bps. Does anybody have >> an idea where this could be coming from? > > I noticed this too but I have no idea why. I also had to move back to > 9600. I've found the problem and fixed it. It's been broken all along, but for some reason it got worse lately. Basically, what happened was that the getpacket function, which does polled I/O, wasn't locking out interrupts, and something was interrupting long enough for characters to get lost. Since sometimes several consecutive characters got lost, it seems likely that either something locks out interrupts for an inappropriately long time, or the sio interrupt routines steal them. Anyway, it works nicely at 115200 bps now. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 22:11:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id DC26C37BC4F for ; Mon, 24 Apr 2000 22:11:40 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id BAA61446; Tue, 25 Apr 2000 01:11:17 -0400 (EDT) Date: Tue, 25 Apr 2000 01:11:17 -0400 (EDT) From: "Matthew N. Dodd" To: Nate Williams Cc: Chuck Robey , FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <200004250253.UAA09084@nomad.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Nate Williams wrote: > I'm violently opposed to removing it completely. The only thing I > wouldn't be violently opposed to would be removing 'Attic' files (truly > unused file), and having them stored away somewhere in the tree for > archival purposes. You realize that its possible to setup your local repo to drop these right? (Attic files that is.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 22:12: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id C661937BC31 for ; Mon, 24 Apr 2000 22:12:05 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.13 #1) id 12jxde-00031Z-00; Tue, 25 Apr 2000 12:11:58 +0700 Date: Tue, 25 Apr 2000 12:11:58 +0700 (ALMST) From: Boris Popov To: Alexander Matey Cc: freebsd-current@freebsd.org Subject: Re: buildworld broken In-Reply-To: <20000425005637.A45146@cis.ohio-state.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Alexander Matey wrote: > Cvsupped 2 hours ago: > > ... > ===> sys/modules/syscons/fire > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > rm -f .depend > mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/syscons/fire/.. -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/syscons/fire/fire_saver.c > /usr/src/sys/modules/syscons/fire/fire_saver.c:44: machine/random.h: No such file or directory > mkdep: compile failed > *** Error code 1 I've stepped on it too and fix is just committed. -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 22:16:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 3ABED37B7FA for ; Mon, 24 Apr 2000 22:16:05 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.13 #1) id 12jxgY-00031w-00; Tue, 25 Apr 2000 12:14:58 +0700 Date: Tue, 25 Apr 2000 12:14:58 +0700 (ALMST) From: Boris Popov To: Bruce Evans Cc: "Rodney W. Grimes" , "Jacques A . Vidrine" , Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Bruce Evans wrote: > > Given that this is a change in splxxx() I suspect that it breaks > > most modules, but probably not all modules. A quick grep -l spl * | wc > > Given that this is a change in the splxxx() implementation, it breaks > zero modules. > > splxxx() was changed from an inline function to an ordinary function > when SMP development started, to give the same ABI for the SMP case as > for the non-SMP case. This gives the same ABI for different SMP > implementations as a side effect. simple_lock* functions has breakage too. They defined as macros for non-SMP case and as functions for SMP. -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 22:20:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id EA45837BC9E for ; Mon, 24 Apr 2000 22:20:31 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac7.wam.umd.edu (root@rac7.wam.umd.edu [128.8.10.147]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id BAA12059; Tue, 25 Apr 2000 01:20:20 -0400 (EDT) Received: from rac7.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac7.wam.umd.edu (8.9.3/8.9.3) with SMTP id BAA09053; Tue, 25 Apr 2000 01:20:16 -0400 (EDT) Received: from localhost (culverk@localhost) by rac7.wam.umd.edu (8.9.3/8.9.3) with ESMTP id BAA09049; Tue, 25 Apr 2000 01:20:15 -0400 (EDT) X-Authentication-Warning: rac7.wam.umd.edu: culverk owned process doing -bs Date: Tue, 25 Apr 2000 01:20:15 -0400 (EDT) From: Kenneth Wayne Culver To: "Brandon D. Valentine" Cc: "Jeroen C. van Gelderen" , Richard Wackerbarth , Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Personally, I don't think that's a bad idea, I never had trouble going to /usr/src/sys/modules and doing a make depend then make then make install, but I guess it'd be nicer if everything just compiled when I built my kernel, and better yet, it would be nice to have it make the "modules.old" directory somewhere. ================================================================= | Kenneth Culver | FreeBSD: The best OS around. | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Mon, 24 Apr 2000, Brandon D. Valentine wrote: > On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote: > > >I believe that it depends on what changes were made since the last > >recompile, although it is good practice to at least recompile the modules > >when the kernel is recompiled. > > In my opinion the best way to handle things like this is to add a > modules target to the kernel Makefile which would call > src/sys/modules/Makefile and allow users who would perhaps never venture > into src/sys except when heading straight for src/sys/i386/conf to > easily update their modules. It makes little sense to have modules > under src/sys and in the src-sys collection if the only time they are > routinely rebuilt is through a complete make world. Isn't the idea of > having a seperate Makefile for src/sys so that *all* kernel level code > can be recompiled and/or updated without the user having to possess all > of src or knowledge of the world process? I know I'm not the first > person to raise the issue, but I don't think I should be the last > either. I think it's a sound architectual decision and 100% inline with > FreeBSD's commitment to accomodate users of all skill levels. > > Brandon D. Valentine > -- > bandix@looksharp.net Illegitimi non carborundum. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 22:25:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.115.5]) by hub.freebsd.org (Postfix) with ESMTP id E1EBC37BC4F for ; Mon, 24 Apr 2000 22:25:37 -0700 (PDT) (envelope-from matey@cis.ohio-state.edu) Received: from epsilon.cis.ohio-state.edu (matey@epsilon.cis.ohio-state.edu [164.107.112.10]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id BAA04512; Tue, 25 Apr 2000 01:25:37 -0400 (EDT) Received: (from matey@localhost) by epsilon.cis.ohio-state.edu (8.9.1/8.9.1) id BAA09581; Tue, 25 Apr 2000 01:25:36 -0400 (EDT) Date: Tue, 25 Apr 2000 01:25:28 -0400 From: Alexander Matey To: Boris Popov Cc: freebsd-current@FreeBSD.ORG Subject: Re: buildworld broken Message-ID: <20000425012528.A94902@cis.ohio-state.edu> References: <20000425005637.A45146@cis.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from bp@butya.kz on Tue, Apr 25, 2000 at 12:11:58PM +0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, On Tue, Apr 25, 2000 at 12:11:58PM +0700, Boris Popov wrote: > > mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/syscons/fire/.. -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/syscons/fire/fire_saver.c > > /usr/src/sys/modules/syscons/fire/fire_saver.c:44: machine/random.h: No such file or directory > > mkdep: compile failed > > *** Error code 1 > > I've stepped on it too and fix is just committed. Yeah, I saw your commit. Thanks. > -- > Boris Popov -- lx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 23:11:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id D993437B92A for ; Mon, 24 Apr 2000 23:11:25 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id AAA08176 for ; Tue, 25 Apr 2000 00:11:24 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200004250611.AAA08176@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Apr 2000 00:11:24 -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I said: > I am guessing that little of the above will be MFC'd into 4.0. So the issue > of the current SMP patch set should be based on its merits alone. I would > agree that they in themselves are worthy of MFCing. Lets just not kid Mike Smith replied: > Steve Passe actually argued quite eloquently against his own decision; > the "real work" that actually depends heavily on this foundation is > almost certainly never going to come back to the 4.x branch. Since these > changes don't actually bring any real improvements in and of themselves, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > there's little point in merging them for their own sake. I based my opinion on the belief that they did indeed bring in a performance benefit (I think I remember the value of 7% being tossed around). I took those numbers on face value, if correct I stand by my "decision". I didn't run any tests with code pre-Matts-changes, so I can't confirm or deny them. My "decision" is also based purely on the technical merits of the exercise, I have to admit I never thought much about the issues of stable ABI. Coming from where I do, I readily admit I am a poor judge of this issue... For my post-Matts-changes tests check out: http://www.freebsd.org/~fsmp/SMP/rbenches.html -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Apr 24 23:37:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from jason.argos.org (a1-3b058.neo.rr.com [24.93.181.58]) by hub.freebsd.org (Postfix) with ESMTP id 2B8D737BCAC; Mon, 24 Apr 2000 23:37:05 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id CAA09320; Tue, 25 Apr 2000 02:36:59 -0400 Date: Tue, 25 Apr 2000 02:36:59 -0400 (EDT) From: Mike Nowlin To: "Jordan K. Hubbard" Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, adoyle@viewsnet.com Subject: Re: To MFC or not to MFC, that is the question. In-Reply-To: <10801.956522360@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > personalities or styles. In this case, I'd say it was a job for the > CRC if we currently had one. :) Does that make it a "CRC Check"? :) (Good old redundant-terminology Cyclical-Reduncancy-Check Checks.....) mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 0: 2:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id B712837BCE5 for ; Tue, 25 Apr 2000 00:02:10 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id AAA34099; Tue, 25 Apr 2000 00:02:07 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <390542EF.D8852A94@gorean.org> Date: Tue, 25 Apr 2000 00:02:07 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0422 i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Wackerbarth Cc: current@freebsd.org Subject: Re: Archive pruning References: <20000424185151.A36672@hub.freebsd.org> <200004250238.WAA37098@khavrinen.lcs.mit.edu> <00042422091401.16303@nomad.dataplex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Wackerbarth wrote: > > On Mon, 24 Apr 2000, you wrote: > > > I'd like to add that it can be particularly important when legal > > questions arise. > > You confuse the argument for SOME complete repositories with > the necessity that ALL (or at each most) repositories be so extensive. Well I know I'm confused. I missed the part where someone held a gun to your head and told you that you had to maintain a CVS repository. I know that the first thing I do when considering a major FreeBSD project is to go look at the history to make sure I don't make the same mistakes that have been made in the past. Having a partial history doesn't help me at all. I could comment further, but I don't see the point, especially given that the maintainer of the file that started this discussion both agrees that steps can be taken to lessen its impact on the repository, and has agreed to do so. Doug -- Excess on occasion is exhilarating. It prevents moderation from acquiring the deadening effect of a habit. -- W. Somerset Maugham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 0:10:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id A080A37BC98; Tue, 25 Apr 2000 00:10:48 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id AAA34139; Tue, 25 Apr 2000 00:10:42 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <390544F2.EE685476@gorean.org> Date: Tue, 25 Apr 2000 00:10:42 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0422 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jon Hamilton Cc: obrien@freebsd.org, current@freebsd.org Subject: Re: Archive pruning References: <20000425044415.066A7156@woodstock.monkey.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jon Hamilton wrote: > I've been following this thread at some distance for a while, and I > don't understand your definition of ``everyone''. Aside from developers, > who do you feel is a good candidate to track the entire CVS repository, rather > than using CVSUP or some other method to get only the tree they are > interested in? This is a good question, and deserves a good answer. From my experience, you should maintain a cvs repo if you find that you have lots of local changes to your checked out sources that you would like to maintain, where "lots" gets defined as enough to justify the cost of maintaining the repo as opposed to the cost of re-patching your tree after each cvsup (or other methods). This is of course begging the obvious answer of, if you're developing for FreeBSD there is no substitute. Personally, I keep a fairly complete cvs repo, and use it for my source trees. However, I just switched my ports collections over to use cvsup, and learned how to set up my own cvsupd in the process just for fun. The reason being that an update to the ports tree takes about 40 - 50 minutes with cvs, and 8 - 10 with cvsup on my systems. I don't have enough local changes in my ports tree to justify the expense of time and inconvenience that the checked out ports tree was costing me. If I want to submit a patch to the ports tree I can just check out a working copy and make my patch from that. I hope this is useful information for you. What it boils down to is, if you're just using the FreeBSD sources as they come, and/or you rarely if ever generate a patch for submission to the project there's no point in using cvs, cvsup is faster and easier. Doug -- Excess on occasion is exhilarating. It prevents moderation from acquiring the deadening effect of a habit. -- W. Somerset Maugham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 0:47:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from solaris.matti.ee (solaris.matti.ee [194.126.98.135]) by hub.freebsd.org (Postfix) with ESMTP id 6F0C637BCD5 for ; Tue, 25 Apr 2000 00:47:12 -0700 (PDT) (envelope-from vallo@matti.ee) Received: from myhakas.matti.ee (myhakas.matti.ee [194.126.114.87]) by solaris.matti.ee (Postfix) with ESMTP id 9D4CD2CE79; Tue, 25 Apr 2000 09:47:08 +0200 (EET) Received: by myhakas.matti.ee (Postfix, from userid 1000) id CBF941C574E; Tue, 25 Apr 2000 09:47:09 +0200 (EET) Date: Tue, 25 Apr 2000 09:47:09 +0200 From: Vallo Kallaste To: "Brandon D. Valentine" Cc: freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000425094709.A5210@myhakas.matti.ee> Reply-To: vallo@matti.ee References: <3904693F.ED9C5FA6@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from bandix@looksharp.net on Mon, Apr 24, 2000 at 10:55:05PM -0400 Organization: =?UTF-8?Q?AS_Matti_B=C3=BCrootehnika?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 10:55:05PM -0400, "Brandon D. Valentine" wrote: > The number one excuse large third party server vendors use to justify > use of NT over Linux on their high end SMP systems is the poor > performance of Linux SMP. This is a tremendous opportunity for FreeBSD > to take market share. People are seeing the virtues of free, open > source operating systems in the server farm and providing top notch SMP > support in FreeBSD will help to see that we make further inroads that > the Linux guys do. If the BSDi code assists us in improving SMP > performance and if the corporate backing helps our PR image, then we > could be in for a fun ride. This is the time to start thinking in terms > of "What can we do better?" or we're going to lose the battle. Sure, > those changes could go into 5.x and be released when RELENG_5 is > branched a year from now. But in this business, a year is 6 months too > late. Think about that before you object to what appear to be vast > improvements in the performance of the RELENG_4 branch while it is just > getting off the ground. Fair enough, but as somebody (Greg Lehey if I recall) said it was taken about 5 years for Sun to develop fine SMP support and we can't expect to be faster. FreeBSD is quite behind of Linux on the SMP issues currently, Linux is somewhat behind of NT and NT, I believe, is still behind of Solaris for SMP. Actually, I don't know, because my Solaris 8 CD is still on the way :( -- Vallo Kallaste vallo@matti.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 1: 2: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from hayseed.net (hayseed.net [207.181.249.194]) by hub.freebsd.org (Postfix) with ESMTP id 4FC4037B820 for ; Tue, 25 Apr 2000 01:01:59 -0700 (PDT) (envelope-from cnielsen@pobox.com) Received: from localhost (localhost [127.0.0.1]) by hayseed.net (8.9.3/8.9.3) with ESMTP id XAA28386; Mon, 24 Apr 2000 23:56:50 -0700 Date: Mon, 24 Apr 2000 23:56:50 -0700 (PDT) From: Christopher Nielsen X-Sender: enkhyl@hayseed.net Reply-To: cnielsen@pobox.com To: Vallo Kallaste Cc: "Brandon D. Valentine" , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000425094709.A5210@myhakas.matti.ee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Vallo Kallaste wrote: > Fair enough, but as somebody (Greg Lehey if I recall) said it was taken > about 5 years for Sun to develop fine SMP support and we can't expect to > be faster. FreeBSD is quite behind of Linux on the SMP issues currently, > Linux is somewhat behind of NT and NT, I believe, is still behind of > Solaris for SMP. Actually, I don't know, because my Solaris 8 CD is > still on the way :( Solaris is far and away better at SMP than NT. I haven't seen NT running on 64-cpu machines, and I certainly haven't seen it scaling very nearly linearly to ~20 CPUs (diminishing returns start to take effect around 22 cpus). Solaris has had this since at least 2.6 (when I last evaluated this) with 2.[78] adding greater stability and more features. -- Christopher Nielsen (enkhyl|cnielsen)@pobox.com Enkhyl on IRC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 1: 2: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from lmail.actcom.co.il (lmail.actcom.co.il [192.114.47.13]) by hub.freebsd.org (Postfix) with ESMTP id 7A08F37BD06 for ; Tue, 25 Apr 2000 01:02:03 -0700 (PDT) (envelope-from tale@cybertel.co.il) Received: from tale (i0-29.haifa6.actcom.co.il [192.114.82.178]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id LAA29634 for ; Tue, 25 Apr 2000 11:02:31 +0300 From: "Tal S Eilon" To: Subject: Slow Dell PowerEdge 1300 with FreeBSD 3.4 Date: Tue, 25 Apr 2000 10:59:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I Just installed my Dell PowerEdge 1300 P-III/500 + 512MB RAM + 8Gb UW-SCSI Drive but I my system is VERY slow. It took me close to 15min to compile tcsh-6.09.00. Did anyone experienced anything like that before? Tal S. Eilon Unix System Adminisrator Cybertel Ltd. -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 1:12:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id 9C1AA37BCAC for ; Tue, 25 Apr 2000 01:12:45 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 6627 invoked from network); 25 Apr 2000 08:12:44 -0000 Received: from lc210.cvzoom.net (208.226.154.210) by ns.cvzoom.net with SMTP; 25 Apr 2000 08:12:44 -0000 Date: Tue, 25 Apr 2000 04:12:44 -0400 (EDT) From: Donn Miller To: Tal S Eilon Cc: freebsd-current@freebsd.org Subject: Re: Slow Dell PowerEdge 1300 with FreeBSD 3.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Tal S Eilon wrote: > I Just installed my Dell PowerEdge 1300 P-III/500 + 512MB RAM + > 8Gb UW-SCSI Drive but I my system is VERY slow. It took me close > to 15min to compile tcsh-6.09.00. Did anyone experienced anything > like that before? Sounds like you must have your CPU cache disabled. Also, you may have done something weird with your kernel config. Maybe you can post the output of dmesg | head -11. - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 1:18:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from lmail.actcom.co.il (lmail.actcom.co.il [192.114.47.13]) by hub.freebsd.org (Postfix) with ESMTP id 4A83837BC75 for ; Tue, 25 Apr 2000 01:18:31 -0700 (PDT) (envelope-from tale@cybertel.co.il) Received: from tale (i0-29.haifa6.actcom.co.il [192.114.82.178]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id LAA31410; Tue, 25 Apr 2000 11:18:53 +0300 From: "Tal S Eilon" To: "Donn Miller" Cc: Subject: RE: Slow Dell PowerEdge 1300 with FreeBSD 3.4 Date: Tue, 25 Apr 2000 11:16:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hope this can help -- here it is: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-RELEASE #0: Tue Apr 25 02:23:41 GMT 2000 root@bell.superbanner.net:/usr/src/sys/compile/BELL Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III (498.48-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383fbff> real memory = 536870912 (524288K bytes) avail memory = 519454720 (507280K bytes) --Tal -----Original Message----- From: owner-freebsd-current@FreeBSD.ORG [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Donn Miller Sent: Tuesday, April 25, 2000 10:13 AM To: Tal S Eilon Cc: freebsd-current@FreeBSD.ORG Subject: Re: Slow Dell PowerEdge 1300 with FreeBSD 3.4 On Tue, 25 Apr 2000, Tal S Eilon wrote: > I Just installed my Dell PowerEdge 1300 P-III/500 + 512MB RAM + > 8Gb UW-SCSI Drive but I my system is VERY slow. It took me close > to 15min to compile tcsh-6.09.00. Did anyone experienced anything > like that before? Sounds like you must have your CPU cache disabled. Also, you may have done something weird with your kernel config. Maybe you can post the output of dmesg | head -11. - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 1:28:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from solaris.matti.ee (solaris.matti.ee [194.126.98.135]) by hub.freebsd.org (Postfix) with ESMTP id B982437B92A for ; Tue, 25 Apr 2000 01:28:12 -0700 (PDT) (envelope-from vallo@matti.ee) Received: from myhakas.matti.ee (myhakas.matti.ee [194.126.114.87]) by solaris.matti.ee (Postfix) with ESMTP id 4B2C32CE78; Tue, 25 Apr 2000 10:28:09 +0200 (EET) Received: by myhakas.matti.ee (Postfix, from userid 1000) id A30631C574E; Tue, 25 Apr 2000 10:28:11 +0200 (EET) Date: Tue, 25 Apr 2000 10:28:11 +0200 From: Vallo Kallaste To: Christopher Nielsen Cc: "Brandon D. Valentine" , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000425102811.A5689@myhakas.matti.ee> Reply-To: vallo@matti.ee References: <20000425094709.A5210@myhakas.matti.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from cnielsen@pobox.com on Mon, Apr 24, 2000 at 11:56:50PM -0700 Organization: =?UTF-8?Q?AS_Matti_B=C3=BCrootehnika?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 11:56:50PM -0700, Christopher Nielsen wrote: > Solaris is far and away better at SMP than NT. I haven't seen NT running > on 64-cpu machines, and I certainly haven't seen it scaling very nearly > linearly to ~20 CPUs (diminishing returns start to take effect around 22 > cpus). Solaris has had this since at least 2.6 (when I last evaluated > this) with 2.[78] adding greater stability and more features. You are speaking about SPARC arhitecture, aren't you? Actually we can't compare IA32 and 64-bit SPARC I think and after all I'm absolutely wrong person to discuss about SPARC so I shut up now :-) -- Vallo Kallaste vallo@matti.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 1:33:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id 3D32D37BCDD; Tue, 25 Apr 2000 01:33:50 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 12k0my-000OhL-0X; Tue, 25 Apr 2000 09:33:48 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA24379; Tue, 25 Apr 2000 09:33:49 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 25 Apr 2000 09:39:10 +0100 (BST) From: Doug Rabson To: Greg Lehey Cc: FreeBSD Committers , FreeBSD current users Subject: Re: Remote serial gdb is broken in -CURRENT. In-Reply-To: <20000425143641.J26934@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Greg Lehey wrote: > On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote: > > On Sun, 23 Apr 2000, Greg Lehey wrote: > > > >> In the last few days, my remote serial gdb has almost completely > >> stopped working. Previously I had (almost) no trouble at 38400 bps; > >> now I can barely get a response at all at 9600 bps. Does anybody have > >> an idea where this could be coming from? > > > > I noticed this too but I have no idea why. I also had to move back to > > 9600. > > I've found the problem and fixed it. It's been broken all along, but > for some reason it got worse lately. > > Basically, what happened was that the getpacket function, which does > polled I/O, wasn't locking out interrupts, and something was > interrupting long enough for characters to get lost. Since sometimes > several consecutive characters got lost, it seems likely that either > something locks out interrupts for an inappropriately long time, or > the sio interrupt routines steal them. Anyway, it works nicely at > 115200 bps now. Great, thanks Greg. Debugging at 9600bps was getting painful :-) On a nearly unrelated subject, can you try out the new stuff I just put into the kernel linker to allow it to export information to GDB. Now you should be able to use GDB's "sharedlibrary" command to load symbols. Make sure that the path used to load the file on the debugged machine is a valid path leading to the same file on the debugger machine. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 1:36:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C327137BCA6; Tue, 25 Apr 2000 01:36:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA76099; Tue, 25 Apr 2000 01:36:48 -0700 (PDT) (envelope-from dillon) Date: Tue, 25 Apr 2000 01:36:48 -0700 (PDT) From: Matthew Dillon Message-Id: <200004250836.BAA76099@apollo.backplane.com> To: "Jonathan M. Bresler" Cc: smp@csn.net, current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <20000425014539.D944E37B7A0@hub.freebsd.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> The network stack is equally easy to make MP-safe. In this case we :> have a shared lock to lookup sockets for host/port combinations and :> then fine-grained exclusive locks within those sockets. Route table :> and other high level operations could in fact remain BGL'd without :> interfering with the network stack because the network stack *already* :> caches route table lookups. :> : : might it be fair to summarize this as: you locks on data :rather than locks on code. : :jmb In a nutshell, yes. Functional data structure locking such that things don't trip over each other with a typical heavy load. For example, it may well be that it makes more sense to lock hash table chains rather then the structures stored on those chains in some instances. vm_page_lookup(), for example, and tsleep(). In other cases it may make sense to lock the terminal structures. For example: vnodes, processes, pmaps, VM objects. And in still other cases we should be able to get away with no locking at all (in the steady-state heavy load case). Network interrupts, for example, can queue packets with fixed-length bidirectional FIFOs. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 1:42:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 46A7D37BC70 for ; Tue, 25 Apr 2000 01:42:13 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id SAA09591; Tue, 25 Apr 2000 18:41:18 +1000 Date: Tue, 25 Apr 2000 18:41:14 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Boris Popov Cc: "Rodney W. Grimes" , "Jacques A . Vidrine" , Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Boris Popov wrote: > simple_lock* functions has breakage too. They defined as macros > for non-SMP case and as functions for SMP. This currently apparently affects the following modules: ccd cd9660 msdosfs nfs ntfs nwfs vinum All of these functions reference simple_lock() if it is not defined away. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 2:18:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 0E7EB37B6F8 for ; Tue, 25 Apr 2000 02:18:48 -0700 (PDT) (envelope-from paul@originative.co.uk) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id E19541D161; Tue, 25 Apr 2000 10:18:44 +0100 (BST) Message-ID: <390562F4.550B65EE@originative.co.uk> Date: Tue, 25 Apr 2000 10:18:44 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en-GB, en MIME-Version: 1.0 To: Bill Fumerola Cc: Richard Wackerbarth , Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042315420301.24082@nomad.dataplex.net> <200004240605.XAA66216@apollo.backplane.com> <00042404464300.09955@nomad.dataplex.net> <20000424144441.W397@jade.chc-chimes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote: > > On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote: > > > >From the USER's perspective, anything that requires me to as much as reload > > a module/program that I have already installed "breaks" it. > > The fact that it is only necessary to recompile it in order to fix it only > > means that it is easy to fix IF I have the source code. > > No-one forces you to upgrade you systems. Partial upgrades are something that are > nice when they work, but understood when they don't. > > We don't accept bug reports (typically) when a person hasn't upgraded their world, > kernel, and modules. I don't understand why we're accepting preemptive bitching. The trouble is, if you're running a production system then there will be cases where you really must carry out an upgrade, because of a critical bug fix, even though as the admin you really don't want to touch a live system. When you're running a "stable" code base you expect to be able to patch in these bug fixes if they're required with relatively little pain. However, if rebuilding your kernel to incorporate a critical bug fix 3 months down the line means that you're proprietary drivers no longer work then you're stuck between a rock and a hard place. Stable should mean stable and stability means not changing things unless they're critical bug fixes. Development on the stable branches has become far too fast and loose. It *is* affecting the perception of FreeBSD by commercial users who really aren't interested in getting new features on stable branch, in the main if you want new features you wait for the next major release and you go through all the hassles of regression testing your application on the new version. That's not something done lightly or often and breaking the stable branch and preventing the incorporation of genuine fixes, rather than enhancements, is not helping the adoption of FreeBSD by serious commercial users. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 2:49:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id DEA5137B620 for ; Tue, 25 Apr 2000 02:49:24 -0700 (PDT) (envelope-from paul@originative.co.uk) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id D15661D15F; Tue, 25 Apr 2000 10:49:21 +0100 (BST) Message-ID: <39056A21.C58ED54A@originative.co.uk> Date: Tue, 25 Apr 2000 10:49:21 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en-GB, en MIME-Version: 1.0 To: "Brandon D. Valentine" Cc: "Daniel C. Sobral" , Alok Dhir , 'Richard Wackerbarth' , 'Matthew Dillon' , "'freebsd-current@FreeBSD.ORG'" Subject: Re: SMP changes and breaking kld object module compatibility References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brandon D. Valentine" wrote: > > On Tue, 25 Apr 2000, Daniel C. Sobral wrote: > > >Because if we do not provide a STABLE ABI, we WON'T get third-party > >(binary only) kernel modules. > > > >I'm very divided in this issue. 4.x has just started, and would be > >seriously impaired if no further improvements to it's SMP get in. On > >the other hand, if we can't garantee third party vendors a stable ABI, > >we won't get third party vendors. > > The number one excuse large third party server vendors use to justify > use of NT over Linux on their high end SMP systems is the poor > performance of Linux SMP. This is a tremendous opportunity for FreeBSD > to take market share. People are seeing the virtues of free, open > source operating systems in the server farm and providing top notch SMP > support in FreeBSD will help to see that we make further inroads that > the Linux guys do. If the BSDi code assists us in improving SMP > performance and if the corporate backing helps our PR image, then we > could be in for a fun ride. This is the time to start thinking in terms > of "What can we do better?" or we're going to lose the battle. Sure, > those changes could go into 5.x and be released when RELENG_5 is > branched a year from now. But in this business, a year is 6 months too > late. Think about that before you object to what appear to be vast > improvements in the performance of the RELENG_4 branch while it is just > getting off the ground. I totally disagree, my experience is that commercial users upgrade not more than once a year and they expect things to continue working on their chosen branch for that year and to continue to receive bug fix support on that branch (most places upgrade much less often than once a year). "a year is 6 months too late" is true for development branches but it is not the case for production code. Having a happy user base will mean that a FreeBSD 5 with improved SMP will be anticipated and widely adopted when it is released sometime next year (I'd hope). The more we piss off the production users with unnecessary incompatibilities in stable branches the more entrenched they become with their existing releases, regardless of the improvments in later versions, because they don't trust the project to have a professional release strategy. I've seen this happen already and early adopters of 4.0 are going to be really pissed off to find that there is an ABI change in a stable branch. Most commercial users are not developers, and have no interest in anything relating to development. Professional sysadmins are conservative creatures, they expect professional quality code to play by the rules of the industry and those rules are widely accepted as meaning that stable branches do no undergo ABI changes. Such changes are reserved for major upgrades because of the consequences and risks involved. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 3:13:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 4CD8237BCD5 for ; Tue, 25 Apr 2000 03:13:39 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 05:13:29 -0500 From: Richard Wackerbarth To: Garrett Wollman Subject: Re: Archive pruning Date: Tue, 25 Apr 2000 05:13:28 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: current@freebsd.org References: <20000424185151.A36672@hub.freebsd.org> <00042422091401.16303@nomad.dataplex.net> <200004250349.XAA37420@khavrinen.lcs.mit.edu> In-Reply-To: <200004250349.XAA37420@khavrinen.lcs.mit.edu> MIME-Version: 1.0 Message-Id: <00042505132800.02416@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Garrett Wollman wrote: > < said: > > You confuse the argument for SOME complete repositories with > > the necessity that ALL (or at each most) repositories be so extensive. > > You're welcome to remove whatever history you like from your personal > copy. Not if I want to keep the recent history up to date. The distribution tools don't support that. > It's not worth the effort to the project as a whole to save a > small amount of disk space. > > The CVS tree is currently 843 Mbytes, complete. Storage cost (even if > you buy SCSI disks) is about $16. With cheap disks, that's about $6. However, you are ignoring the cost of repeatedly (re)processing that (non)information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 3:15:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.9.224.2]) by hub.freebsd.org (Postfix) with ESMTP id 399AA37BCDD; Tue, 25 Apr 2000 03:15:02 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from vega.vega.com (dialup3-20.iptelecom.net.ua [212.9.226.148]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id NAA23880; Tue, 25 Apr 2000 13:22:24 +0300 (EEST) Received: from altavista.net (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.9.3/8.9.3) with ESMTP id NAA00515; Tue, 25 Apr 2000 13:14:24 +0300 (EEST) (envelope-from sobomax@altavista.net) Message-ID: <39056FFF.5734CAA8@altavista.net> Date: Tue, 25 Apr 2000 13:14:23 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: current@freebsd.org Cc: stable@freebsd.org Subject: KLD related panic (RELENG_4 & RELENG_5) Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've just found what it seems to me an error somewhere in the KLD modules implementation affecting both 4-STABLE and 5-CURRENT. Following course of actions makes kernel panic on both releases: 1. Load vn module into kernel 2. Configure vn device using vnconfig 3. Mount vn device 4. Unmount vn device 5. Unconfigure vn device 6. Unload vn kernel module 7. Try to mount vn device. Instead of expected "device not configured" you'll have kernel panic. It seems that vn device failed to deregister itself properly on kldunload. -Maxim Following is script of my session: # kldstat Id Refs Address Size Name 1 2 0xc0100000 1c2f48 kernel 2 1 0xc02c3000 30c8 splash_bmp.ko root@notebook# vnconfig -c /dev/vn0 /tmp/tst root@notebook# kldstat Id Refs Address Size Name 1 3 0xc0100000 1c2f48 kernel 2 1 0xc02c3000 30c8 splash_bmp.ko 3 1 0xc08b9000 3000 vn.ko root@notebook# mount /dev/vn0c /mnt root@notebook# mount /dev/ad0s1a on / (ufs, asynchronous, NFS exported, local, noatime, writes: sync 4 async 41, reads: sync 507 async 22) procfs on /proc (procfs, local) /dev/vn0c on /mnt (ufs, local, writes: sync 2 async 0, reads: sync 1 async 0) root@notebook# umount /mnt root@notebook# vnconfig -u /dev/vn0 root@notebook# kldunload -i 3 root@notebook# kldstat Id Refs Address Size Name 1 2 0xc0100000 1c2f48 kernel 2 1 0xc02c3000 30c8 splash_bmp.ko root@notebook# mount /dev/vn0c /mnt Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc08bb9f0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc016d9b9 stack pointer = 0x10:0xc3313d64 frame pointer = 0x10:0xc3313d70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 209 (mount) interrupt mask = none trap number = 12 panic: page fault To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 4:47:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id F392937B92B for ; Tue, 25 Apr 2000 04:47:33 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 12k3nz-000NAP-00; Tue, 25 Apr 2000 13:47:03 +0200 From: Sheldon Hearn To: mjacob@feral.com Cc: wc.bulte@chello.nl, Richard Wackerbarth , current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-reply-to: Your message of "Mon, 24 Apr 2000 13:52:20 MST." Date: Tue, 25 Apr 2000 13:47:03 +0200 Message-ID: <89056.956663223@axl.ops.uunet.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000 13:52:20 MST, Matthew Jacob wrote: > But this isn't the point. The point is to cause less cvsup turbulence > for all and sundry. I think I can do enough of this by just splitting > the file apart to keep everyone happy. Or happy enough. If that's the _only_ point, then Garrett Wollman's idea should work perfectly. Stick the files under CVS, just agree that they should never be revised, but rather that new versions should be imported in a different directory and the old versions punted to the Attic. The only thing I'd like different from Garrett's proposal is the pathing. I'd prefer to use a general rule for this anywhere in the tree, not just in a path/to/firmware directory. In other words... src/sys/dev/isp/firmware/4.65.00/asm_pci.h Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 6: 2:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.pwahec.org (mail.pwahec.org [208.164.136.32]) by hub.freebsd.org (Postfix) with ESMTP id EFEEB37B6AD; Tue, 25 Apr 2000 06:02:30 -0700 (PDT) (envelope-from rsmall@pwahec.org) Received: from technogeek [208.129.166.68] by mail.pwahec.org (SMTPD32-5.05) id A76311340110; Tue, 25 Apr 2000 08:02:27 -0500 From: "Robert Small" To: , "Sergey Osokin" Cc: Subject: RE: make buildworld failed... Date: Tue, 25 Apr 2000 08:02:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <20000424114541.D12417@dragon.nuxi.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was using -J8, and I kept getting the same error about 20 minutes into the build, but I did it without the -j and got a perfect build, thanks for the help! Robert -----Original Message----- From: owner-freebsd-current@FreeBSD.ORG [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of David O'Brien Sent: Monday, April 24, 2000 1:46 PM To: Sergey Osokin Cc: current@FreeBSD.org Subject: Re: make buildworld failed... On Sat, Apr 22, 2000 at 01:05:24AM +0400, Sergey Osokin wrote: > Hello! > After CVSup i tryed to rebuild my 5.0... Are you using "-j" with your makes? Please try: cd /usr/src make cleandir && make cleandir and try again. Let me know the outcome -- good or bad. *If* the outcome is "good". Please do a second ``make buildworld'' w/o doing anything else. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 6:20:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id 5692537B7D4 for ; Tue, 25 Apr 2000 06:20:33 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 1148 invoked from network); 25 Apr 2000 13:20:32 -0000 Received: from lc210.cvzoom.net (208.226.154.210) by ns.cvzoom.net with SMTP; 25 Apr 2000 13:20:32 -0000 Date: Tue, 25 Apr 2000 09:20:30 -0400 (EDT) From: Donn Miller To: Robert Small Cc: obrien@FreeBSD.org, Sergey Osokin , current@FreeBSD.org Subject: RE: make buildworld failed... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Robert Small wrote: > I was using -J8, and I kept getting the same error about 20 minutes into the > build, but I did it without the -j and got a perfect build, thanks for the > help! One way to automate this would be: cd /usr/src make -j8 buildworld || make -DNOCLEAN buildworld - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 7:17:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.surf1.de (mail.Surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id 5692637BD41; Tue, 25 Apr 2000 07:17:08 -0700 (PDT) (envelope-from alex@cichlids.com) Received: from cichlids.com (p3E9C1137.dip0.t-ipconnect.de [62.156.17.55]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id PAA28271; Tue, 25 Apr 2000 15:15:28 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by cichlids.com (Postfix) with ESMTP id 34382AC2C; Tue, 25 Apr 2000 16:19:57 +0200 (CEST) Received: (from alex@localhost) by cichlids.cichlids.com (8.9.3/8.9.3) id QAA09607; Tue, 25 Apr 2000 16:15:51 +0200 (CEST) (envelope-from alex) Date: Tue, 25 Apr 2000 16:15:51 +0200 From: Alexander Langer To: Donn Miller Cc: Robert Small , obrien@FreeBSD.ORG, Sergey Osokin , current@FreeBSD.ORG Subject: Re: make buildworld failed... Message-ID: <20000425161551.A9530@cichlids.cichlids.com> Mail-Followup-To: Donn Miller , Robert Small , obrien@FreeBSD.ORG, Sergey Osokin , current@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from dmmiller@cvzoom.net on Tue, Apr 25, 2000 at 09:20:30AM -0400 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Donn Miller (dmmiller@cvzoom.net): > cd /usr/src > make -j8 buildworld || make -DNOCLEAN buildworld Hmmm. Or make -k -j8 buildworld || make -DNOCLEAN buildworld in order to build as much multithreaded as possible and then the reminding part non-threaded? :-) Alex -- I need a new ~/.sig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 7:19: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A8EEA37BD50 for ; Tue, 25 Apr 2000 07:18:43 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id QAA53741 for ; Tue, 25 Apr 2000 16:06:13 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: FreeBSD build status Date: Tue, 25 Apr 2000 16:06:13 +0200 Message-ID: <53739.956671573@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG =================================== SUMMARY =================================== World compiled 637 Warnings 45 Errors Kernel LINT compiled 149 Warnings 0 Errors Kernel GENERIC compiled 59 Warnings 0 Errors Kernel GENERIC98 ***didn't compile*** 54 Warnings 0 Errors =================================== Compile errors for kernel GENERIC98 =================================== cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../pc98/i386/machdep.c ../../pc98/i386/machdep.c:129: machine/random.h: No such file or directory *** Error code 1 (continuing) cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../pc98/pc98/syscons.c ../../pc98/pc98/syscons.c:58: machine/random.h: No such file or directory *** Error code 1 (continuing) `all' not remade because of errors. =================================== All warnings from kernel LINT =================================== ../../dev/amr/amr.c:1022: warning: `amr_wait_command' defined but not used ../../dev/amr/amr.c:1225: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:1525: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:1556: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:171: warning: cast discards qualifiers from pointer target type ../../dev/amr/amr.c:687: warning: unused variable `i' ../../dev/amr/amr.c:687: warning: unused variable `s' ../../dev/awi/if_awi_pccard.c:115: warning: assignment discards qualifiers from pointer target type ../../dev/dpt/dpt_scsi.c:1295: warning: cast discards qualifiers from pointer target type ../../dev/dpt/dpt_scsi.c:500: warning: cast discards qualifiers from pointer target type ../../dev/dpt/dpt_scsi.c:611: warning: cast discards qualifiers from pointer target type ../../dev/ex/if_ex.c:1150: warning: unused variable `sc' ../../dev/fb/vga.c:1321: warning: `fill' defined but not used ../../dev/fb/vga.c:1331: warning: `filll_io' defined but not used ../../dev/hea/eni_buffer.c:115: warning: cast discards qualifiers from pointer target type ../../dev/hea/eni_vcm.c:279: warning: cast discards qualifiers from pointer target type ../../dev/hfa/fore_buffer.c:751: warning: passing arg 1 of `atm_dev_free' discards qualifiers from pointer target type ../../dev/hfa/fore_command.c:440: warning: passing arg 1 of `atm_dev_free' discards qualifiers from pointer target type ../../dev/hfa/fore_intr.c:165: warning: enumeration value `DEV_ENI_155P' not handled in switch ../../dev/hfa/fore_intr.c:165: warning: enumeration value `DEV_FORE_SBA200' not handled in switch ../../dev/hfa/fore_intr.c:165: warning: enumeration value `DEV_FORE_SBA200E' not handled in switch ../../dev/hfa/fore_intr.c:165: warning: enumeration value `DEV_UNKNOWN' not handled in switch ../../dev/hfa/fore_load.c:1361: warning: enumeration value `DEV_ENI_155P' not handled in switch ../../dev/hfa/fore_load.c:1361: warning: enumeration value `DEV_FORE_SBA200' not handled in switch ../../dev/hfa/fore_load.c:1361: warning: enumeration value `DEV_FORE_SBA200E' not handled in switch ../../dev/hfa/fore_load.c:1361: warning: enumeration value `DEV_UNKNOWN' not handled in switch ../../dev/hfa/fore_receive.c:562: warning: passing arg 1 of `atm_dev_free' discards qualifiers from pointer target type ../../dev/hfa/fore_transmit.c:343: warning: passing arg 1 of `atm_dev_free' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1236: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1325: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1325: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1342: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1354: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1399: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1537: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1551: warning: cast discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1605: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1614: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1617: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1642: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1899: warning: cast discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1915: warning: cast discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2000: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2024: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2075: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2075: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2139: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2139: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2188: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2189: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/pdq/pdq_ifsubr.c:376: warning: #warning "Implement fddi_resolvemulti!" ../../dev/vn/vn.c:415: warning: passing arg 2 of `vm_pager_strategy' from incompatible pointer type ../../dev/xe/if_xe.c:1836: warning: `xe_compute_crc' defined but not used ../../dev/xe/if_xe.c:1871: warning: `xe_compute_hashbit' defined but not used ../../dev/xe/if_xe.c:2175: warning: `xe_reg_dump' defined but not used ../../dev/xe/if_xe.c:232: warning: `xe_memwrite' defined but not used ../../gnu/i386/isa/dgb.c:228: warning: (near initialization for `dgbspeedtab[0]') ../../gnu/i386/isa/dgb.c:228: warning: missing braces around initializer ../../gnu/i386/isa/dgb.c:803: warning: assignment discards qualifiers from pointer target type ../../gnu/i386/isa/dgb.c:847: warning: assignment discards qualifiers from pointer target type ../../gnu/i386/isa/dgb.c:848: warning: assignment discards qualifiers from pointer target type ../../gnu/i386/isa/dgb.c:851: warning: assignment discards qualifiers from pointer target type ../../gnu/i386/isa/dgb.c:852: warning: assignment discards qualifiers from pointer target type ../../gnu/i386/isa/dgm.c:231: warning: (near initialization for `dgmspeedtab[0]') ../../gnu/i386/isa/dgm.c:231: warning: missing braces around initializer ../../i386/ibcs2/ibcs2_sysent.c:18: warning: cast discards qualifiers from pointer target type ../../i386/isa/cy.c:447: warning: `firmware_version' might be used uninitialized in this function ../../i386/isa/if_rdp.c:509: warning: implicit declaration of function `isa_irq_pending' ../../i386/isa/istallion.c:1888: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:1967: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:1972: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:1994: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:1997: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:2047: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:2057: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:2134: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:2244: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:2274: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:3372: warning: cast discards qualifiers from pointer target type ../../i386/isa/istallion.c:3378: warning: cast discards qualifiers from pointer target type ../../i386/isa/matcd/matcd.c:2057: warning: `i' might be used uninitialized in this function ../../i386/isa/rp.c:1745: warning: (near initialization for `baud_table[0]') ../../i386/isa/rp.c:1745: warning: missing braces around initializer ../../i386/isa/tw.c:577: warning: (near initialization for `X10_HOUSE[0]') ../../i386/isa/tw.c:577: warning: missing braces around initializer ../../i386/isa/tw.c:597: warning: (near initialization for `X10_KEY[0]') ../../i386/isa/tw.c:597: warning: missing braces around initializer ../../i386/linux/linux_sysent.c:19: warning: cast discards qualifiers from pointer target type ../../kern/init_sysent.c:24: warning: cast discards qualifiers from pointer target type ../../kern/subr_diskslice.c:162: warning: unused variable `s' ../../kern/sys_generic.c:344: warning: cast discards qualifiers from pointer target type ../../kern/vfs_aio.c:1014: warning: cast discards qualifiers from pointer target type ../../kern/vfs_aio.c:1895: warning: cast discards qualifiers from pointer target type ../../kern/vfs_aio.c:1958: warning: cast discards qualifiers from pointer target type ../../kern/vfs_aio.c:575: warning: cast discards qualifiers from pointer target type ../../miscfs/nullfs/null_vfsops.c:422: warning: function declaration isn't a prototype ../../net/if_atmsubr.c:184: warning: address of register variable `m' requested ../../netatm/atm_if.c:524: warning: enumeration value `MEDIA_UNKNOWN' not handled in switch ../../netinet/in_proto.c:189: warning: initialization from incompatible pointer type ../../netinet/ip_input.c:665: warning: assignment from incompatible pointer type ../../netinet/tcp_subr.c:1245: warning: implicit declaration of function `ipsec6_hdrsiz' ../../netinet/tcp_subr.c:984: warning: `off' might be used uninitialized in this function ../../nfs/nfs_vfsops.c:406: warning: implicit declaration of function `bootpc_init' ../../pci/alpm.c:375: warning: `sts' might be used uninitialized in this function ../../pci/amd.c:836: warning: `amd_reset' defined but not used ../../pci/amd.c:878: warning: `amd_timeout' defined but not used ../../pci/if_fxp.c:1475: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/if_fxp.c:1532: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/if_fxp.c:2049: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/intpm.c:296: warning: assignment makes pointer from integer without a cast ../../pci/isp_pci.c:367: warning: initialization makes pointer from integer without a cast ../../pci/ncr.c:5334: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5471: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5774: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5778: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5802: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5809: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5817: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5822: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5832: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5836: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:6804: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:6805: warning: cast discards qualifiers from pointer target type ../../svr4/imgact_svr4.c:129: warning: int format, long int arg (arg 2) ../../svr4/imgact_svr4.c:170: warning: int format, long int arg (arg 2) ../../svr4/imgact_svr4.c:186: warning: unsigned int format, long unsigned int arg (arg 3) ../../svr4/imgact_svr4.c:209: warning: unsigned int format, long unsigned int arg (arg 3) ../../svr4/imgact_svr4.c:90: warning: unsigned int format, long unsigned int arg (arg 2) ../../svr4/imgact_svr4.c:90: warning: unsigned int format, long unsigned int arg (arg 3) ../../svr4/imgact_svr4.c:90: warning: unsigned int format, long unsigned int arg (arg 4) ../../svr4/svr4_fcntl.c:581: warning: unsigned int format, pointer arg (arg 2) ../../svr4/svr4_ioctl.c:100: warning: unsigned int format, u_long arg (arg 2) ../../svr4/svr4_ioctl.c:115: warning: initialization from incompatible pointer type ../../svr4/svr4_ioctl.c:156: warning: initialization from incompatible pointer type ../../svr4/svr4_misc.c:256: warning: too many arguments for format ../../svr4/svr4_resource.c:219: warning: implicit declaration of function `dosetrlimit' ../../svr4/svr4_signal.c:298: warning: long unsigned int format, svr4_sig_t arg (arg 2) ../../svr4/svr4_stream.c:1530: warning: unsigned int format, pointer arg (arg 2) ../../svr4/svr4_stream.c:1532: warning: passing arg 1 of `show_strbuf' from incompatible pointer type ../../svr4/svr4_stream.c:2251: warning: assignment from incompatible pointer type ../../svr4/svr4_sysent.c:21: warning: cast discards qualifiers from pointer target type ../../svr4/svr4_termios.c:496: warning: unsigned int format, u_long arg (arg 2) ../../sys/devfsext.h:32: warning: #warning "Using obsolete " ../../sys/devfsext.h:32: warning: #warning "Using obsolete " ../../sys/random.h:86: warning: `struct proc' declared inside parameter list ../../sys/random.h:86: warning: `struct proc' declared inside parameter list ../../sys/random.h:86: warning: its scope is only this definition or declaration, which is probably not what you want. ../../sys/random.h:86: warning: its scope is only this definition or declaration, which is probably not what you want. ../../ufs/ffs/ffs_vfsops.c:90: warning: initialization from incompatible pointer type =================================== All warnings from kernel GENERIC =================================== ../../dev/amr/amr.c:1022: warning: `amr_wait_command' defined but not used ../../dev/amr/amr.c:1225: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:1525: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:1556: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:171: warning: cast discards qualifiers from pointer target type ../../dev/amr/amr.c:687: warning: unused variable `i' ../../dev/amr/amr.c:687: warning: unused variable `s' ../../dev/awi/if_awi_pccard.c:115: warning: assignment discards qualifiers from pointer target type ../../dev/dpt/dpt_scsi.c:1295: warning: cast discards qualifiers from pointer target type ../../dev/dpt/dpt_scsi.c:500: warning: cast discards qualifiers from pointer target type ../../dev/dpt/dpt_scsi.c:611: warning: cast discards qualifiers from pointer target type ../../dev/ex/if_ex.c:1150: warning: unused variable `sc' ../../dev/ie/if_ie.c:1236: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1325: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1325: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1342: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1354: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1399: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1537: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1551: warning: cast discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1605: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1614: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1617: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1642: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1899: warning: cast discards qualifiers from pointer target type ../../dev/ie/if_ie.c:1915: warning: cast discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2000: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2024: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2075: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2075: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2139: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2139: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2188: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../dev/ie/if_ie.c:2189: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../kern/init_sysent.c:24: warning: cast discards qualifiers from pointer target type ../../kern/subr_diskslice.c:162: warning: unused variable `s' ../../kern/sys_generic.c:344: warning: cast discards qualifiers from pointer target type ../../kern/vfs_aio.c:1014: warning: cast discards qualifiers from pointer target type ../../kern/vfs_aio.c:1426: warning: `aio_aqueue' defined but not used ../../kern/vfs_aio.c:575: warning: cast discards qualifiers from pointer target type ../../netinet/ip_input.c:665: warning: assignment from incompatible pointer type ../../netinet/tcp_subr.c:984: warning: `off' might be used uninitialized in this function ../../pci/amd.c:836: warning: `amd_reset' defined but not used ../../pci/amd.c:878: warning: `amd_timeout' defined but not used ../../pci/if_fxp.c:1475: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/if_fxp.c:1532: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/if_fxp.c:2049: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/ncr.c:5334: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5471: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5774: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5778: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5802: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5809: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5817: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5822: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5832: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5836: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:6804: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:6805: warning: cast discards qualifiers from pointer target type =================================== All warnings from kernel GENERIC98 =================================== ../../dev/amr/amr.c:1022: warning: `amr_wait_command' defined but not used ../../dev/amr/amr.c:1225: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:1525: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:1556: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../dev/amr/amr.c:171: warning: cast discards qualifiers from pointer target type ../../dev/amr/amr.c:687: warning: unused variable `i' ../../dev/amr/amr.c:687: warning: unused variable `s' ../../i386/isa/bs/bsfunc.c:634: warning: large integer implicitly truncated to unsigned type ../../i386/isa/bs/bsfunc.c:64: warning: label `again' defined but not used ../../i386/isa/bs/bshw_dma.c:126: warning: called from here ../../i386/isa/bs/bshw_dma.c:223: warning: comparison is always true due to limited range of data type ../../i386/isa/bs/bshw_dma.c:38: warning: can't inline call to `bshw_dmastart' ../../i386/isa/bs/bshw_pdma.c:39: warning: can't inline call to `bshw_lc_smit_stop' ../../i386/isa/bs/bshw_pdma.c:49: warning: called from here ../../i386/isa/if_fe.c:1157: warning: suggest parentheses around arithmetic in operand of | ../../kern/init_sysent.c:24: warning: cast discards qualifiers from pointer target type ../../kern/subr_diskslice.c:162: warning: unused variable `s' ../../kern/sys_generic.c:344: warning: cast discards qualifiers from pointer target type ../../kern/vfs_aio.c:1014: warning: cast discards qualifiers from pointer target type ../../kern/vfs_aio.c:1426: warning: `aio_aqueue' defined but not used ../../kern/vfs_aio.c:575: warning: cast discards qualifiers from pointer target type ../../netinet/ip_input.c:665: warning: assignment from incompatible pointer type ../../netinet/tcp_subr.c:984: warning: `off' might be used uninitialized in this function ../../pc98/pc98/clock.c:1095: warning: `s' might be used uninitialized in this function ../../pc98/pc98/fd.c:1160: warning: unused variable `i' ../../pc98/pc98/fd.c:1161: warning: unused variable `st0' ../../pc98/pc98/fd.c:1161: warning: unused variable `st3' ../../pc98/pc98/fd.c:1165: warning: unused variable `fd_fifo' ../../pc98/pc98/fd.c:868: warning: unused variable `ic_type' ../../pc98/pc98/npx.c:273: warning: large integer implicitly truncated to unsigned type ../../pc98/pc98/npx.c:273: warning: large integer implicitly truncated to unsigned type ../../pc98/pc98/pc98gdc.c:1042: warning: `dump_buffer' defined but not used ../../pc98/pc98/pc98gdc.c:518: warning: `initialize_gdc' defined but not used ../../pc98/pc98/pc98gdc.c:612: warning: `gdc_nop' defined but not used ../../pc98/pc98/sio.c:1169: warning: `rsabase' might be used uninitialized in this function ../../pc98/pc98/sio.c:1303: warning: unused variable `xiobase' ../../pc98/pc98/sio.c:1304: warning: unused variable `io' ../../pci/amd.c:836: warning: `amd_reset' defined but not used ../../pci/amd.c:878: warning: `amd_timeout' defined but not used ../../pci/if_fxp.c:1475: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/if_fxp.c:1532: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/if_fxp.c:2049: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type ../../pci/ncr.c:5334: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5471: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5774: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5778: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5802: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5809: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5817: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5822: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5832: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:5836: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:6804: warning: cast discards qualifiers from pointer target type ../../pci/ncr.c:6805: warning: cast discards qualifiers from pointer target type =================================== END =================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 7:41: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 29CEF37BD4F for ; Tue, 25 Apr 2000 07:40:59 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA39180; Tue, 25 Apr 2000 10:40:50 -0400 (EDT) (envelope-from wollman) Date: Tue, 25 Apr 2000 10:40:50 -0400 (EDT) From: Garrett Wollman Message-Id: <200004251440.KAA39180@khavrinen.lcs.mit.edu> To: Sheldon Hearn Cc: current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <89056.956663223@axl.ops.uunet.co.za> References: <89056.956663223@axl.ops.uunet.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > If that's the _only_ point, then Garrett Wollman's idea should work > perfectly. Stick the files under CVS No, that was not my proposal. I want to keep them out of CVS entirely. CVS is Not Good at handling binary files (even if you never change them). That's why I'd like them in a separate hierarchy. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 8: 2:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from ra.nks.net (ra.nks.net [208.226.218.5]) by hub.freebsd.org (Postfix) with ESMTP id 9EB1237B7D4 for ; Tue, 25 Apr 2000 08:02:03 -0700 (PDT) (envelope-from joeo@cracktown.com) Received: from localhost (joeo@localhost) by ra.nks.net (8.8.7/8.8.7) with ESMTP id LAA06799; Tue, 25 Apr 2000 11:01:27 -0400 Date: Tue, 25 Apr 2000 11:01:27 -0400 (EDT) From: X-Sender: joeo@ra.nks.net To: Kent Hauser Cc: current@FreeBSD.ORG Subject: Re: current status of pcm ?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm not running a recent current on my TP600E (it's pre 4.0-RELEASE). Sound works on this snapshot (4.0-20000314-CURRENT). The relavent config bits... options PNPBIOS device pcm0 (notice no bridge drivers (like sbc0)) dmesg output ... unknown6: at port 0x3bc-0x3bf irq 7 on isa0 unknown: can't assign resources pcm0: at port 0x530-0x537,0x388-0x38b,0x220-0x233 irq 5 drq 1,0 on isa0 unknown7: at port 0x538-0x53f on isa0 unknown8: at port 0x200-0x207 on isa0 ... I did have to do a bios upgrade back in November to get the PNPBIOS options to play nice with the hardware, (also had to turn off the fast boot option, (hold down F1 while powering on to get the bios screen)). On Mon, 24 Apr 2000, Kelly Yancey wrote: > On Mon, 24 Apr 2000, Kent Hauser wrote: > > > > > Hi all, > > > > I've been unable to get audio (mp3 & cdplay) to work on my desktop > > with a SBLive card or on my laptop (TP 600E). I would *really* like > > to have IPSec and a working audio cd player on my laptop. I this > > supposed to work, or am I swimming upstream. > > > > Thanks all. > > Kent > > > > > > Search the mailing list archives for "emu10k1" and you'll find a HOWTO > for using the (experimental) emu10k1 drivers, which provide support for > the SBLive card and others, with 4.0. > > Kelly > > -- > Kelly Yancey - kbyanc@posi.net - Belmont, CA > System Administrator, eGroups.com http://www.egroups.com/ > Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ > Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 8:55:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id E9DEB37BD8C for ; Tue, 25 Apr 2000 08:55:02 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 9B4112DC0B; Tue, 25 Apr 2000 17:58:20 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id 168AC7811; Tue, 25 Apr 2000 17:54:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 0020210E17; Tue, 25 Apr 2000 17:54:21 +0200 (CEST) Date: Tue, 25 Apr 2000 17:54:20 +0200 (CEST) From: Andrzej Bialecki To: Paul Richards Cc: "Brandon D. Valentine" , "Daniel C. Sobral" , Alok Dhir , 'Richard Wackerbarth' , 'Matthew Dillon' , "'freebsd-current@FreeBSD.ORG'" Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <39056A21.C58ED54A@originative.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Paul Richards wrote: > branch. Most commercial users are not developers, and have no interest > in anything relating to development. Professional sysadmins are > conservative creatures, they expect professional quality code to play by > the rules of the industry and those rules are widely accepted as meaning > that stable branches do no undergo ABI changes. Such changes are > reserved for major upgrades because of the consequences and risks > involved. On a similar note: I think one of serious drawbacks of FreeBSD's model for updating and bugfixing the stable branch is 'make world'. It's very inefficient and cumbersome way to do this on production machines. STABLE is stable enough for us to be able to prepare binary patches, which can be applied to a system in some (known) version. Especially security fixes, which are usually limited to specific programs. With such system present I'd be completely satisfied (as a production manager, not as a developer) if I could start with, let's say, 3.4-RELEASE, and then apply binary patches one by one to track STABLE. Instead of putting the machine out-of-service for a couple of hours, it would be 10 minutes. Also, no need to keep the sources around. Of course, implementing such a system requires careful versioning of each file in the standard system, but I think it's possible - just having the MD5 checksums around, for each consecutive patch, should do for start. Don't get me wrong - I love to see what's under the hood, analyze the sources etc. But it's not what is expected in a production environment, (IMHO of course :). Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 8:56: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.pwahec.org (mail.pwahec.org [208.164.136.32]) by hub.freebsd.org (Postfix) with ESMTP id 147CC37BD87; Tue, 25 Apr 2000 08:55:59 -0700 (PDT) (envelope-from rsmall@pwahec.org) Received: from technogeek [208.129.166.68] by mail.pwahec.org (SMTPD32-5.05) id AFF612A0012E; Tue, 25 Apr 2000 10:55:34 -0500 From: "Robert Small" To: "Alexander Langer" , "Donn Miller" Cc: , "Sergey Osokin" , Subject: RE: make buildworld failed... Date: Tue, 25 Apr 2000 10:55:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <20000425161551.A9530@cichlids.cichlids.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I got the buildworld to finih up this morning, but when I try installworld, I get: m/vm_zone.h -> vm/vm_zone.ph vm/vnode_pager.h -> vm/vnode_pager.ph *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/utils/h2ph. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/utils. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any ideas? -----Original Message----- From: owner-freebsd-current@FreeBSD.ORG [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Alexander Langer Sent: Tuesday, April 25, 2000 9:16 AM To: Donn Miller Cc: Robert Small; obrien@FreeBSD.ORG; Sergey Osokin; current@FreeBSD.ORG Subject: Re: make buildworld failed... Thus spake Donn Miller (dmmiller@cvzoom.net): > cd /usr/src > make -j8 buildworld || make -DNOCLEAN buildworld Hmmm. Or make -k -j8 buildworld || make -DNOCLEAN buildworld in order to build as much multithreaded as possible and then the reminding part non-threaded? :-) Alex -- I need a new ~/.sig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 8:58:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by hub.freebsd.org (Postfix) with ESMTP id 0C87C37BF9D for ; Tue, 25 Apr 2000 08:56:02 -0700 (PDT) (envelope-from nate@nomad.yogotech.com) Received: from nomad.yogotech.com (mvdhcp141236.americas.nokia.com [172.18.141.236]) by mgw-x1.nokia.com (8.9.3/8.9.3) with ESMTP id SAA02339; Tue, 25 Apr 2000 18:55:49 +0300 (EETDST) X-Authentication-Warning: mgw-x1.nokia.com: Host mvdhcp141236.americas.nokia.com [172.18.141.236] claimed to be nomad.yogotech.com Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id JAA12503; Tue, 25 Apr 2000 09:15:53 -0600 (MDT) (envelope-from nate) Date: Tue, 25 Apr 2000 09:15:53 -0600 (MDT) Message-Id: <200004251515.JAA12503@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Matthew N. Dodd" Cc: Nate Williams , Chuck Robey , FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: References: <200004250253.UAA09084@nomad.yogotech.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 24 Apr 2000, Nate Williams wrote: > > I'm violently opposed to removing it completely. The only thing I > > wouldn't be violently opposed to would be removing 'Attic' files (truly > > unused file), and having them stored away somewhere in the tree for > > archival purposes. > > You realize that its possible to setup your local repo to drop these > right? (Attic files that is.) Sure, but many of the Attic files in the tree are actually files that are on an older branch that I'm currently using. I don't want to spend the time to figure out which files are 'unused' and whiche files are 'used but unused'. ;) (Once CVS removes a file and sticks it in the Attic, it *never* is removed from the Attic, even if it's added back into active status again.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 9: 0: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id 4CDEB37BD76 for ; Tue, 25 Apr 2000 08:59:57 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 562EA2DC0A; Tue, 25 Apr 2000 18:03:19 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id 5C3AE7811; Tue, 25 Apr 2000 17:57:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 4E0D410E17; Tue, 25 Apr 2000 17:57:30 +0200 (CEST) Date: Tue, 25 Apr 2000 17:57:30 +0200 (CEST) From: Andrzej Bialecki To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: FreeBSD build status In-Reply-To: <53739.956671573@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Poul-Henning Kamp wrote: > > =================================== > SUMMARY > =================================== [27kB long list of errors deleted..] I thought that the final conclusion was to have some other mailing list for this type of messages... ? Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 9: 3:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from io.yi.org (24.67.218.186.bc.wave.home.com [24.67.218.186]) by hub.freebsd.org (Postfix) with ESMTP id 3594E37BE86 for ; Tue, 25 Apr 2000 09:03:22 -0700 (PDT) (envelope-from jburkhol@home.com) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id AE322BCA7; Tue, 25 Apr 2000 09:03:40 -0700 (PDT) X-Mailer: exmh version 2.1.1 10/15/1999 To: Bruce Evans Cc: Boris Popov , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message from Bruce Evans of "Tue, 25 Apr 2000 18:41:14 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Apr 2000 09:03:40 -0700 From: Jake Burkholder Message-Id: <20000425160340.AE322BCA7@io.yi.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 25 Apr 2000, Boris Popov wrote: > > > simple_lock* functions has breakage too. They defined as macros > > for non-SMP case and as functions for SMP. > > This currently apparently affects the following modules: > > ccd > cd9660 > msdosfs > nfs > ntfs > nwfs > vinum > > All of these functions reference simple_lock() if it is not defined away. > > Bruce Has anyone thought about using kobj(9) for this? For example, it should be possible to make simple_lock and lockmgr locks safe for use from modules by introducing a lock_if.h, which has abstract version of all the lock routines. A class would be compiled with null implementations for UP, or the 'lock'ed implementations for SMP. The old functions would call through an instance of that class, automagically finding the right method. Eventually this could be a runtime abstraction, with both up and smp classes compiled into the kernel, and objects initialized with the right method table at boot time. I have diffs in the works if anyone is interested. Jake. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 9:18:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id AED4C37BE01 for ; Tue, 25 Apr 2000 09:18:41 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id SAA54332; Tue, 25 Apr 2000 18:09:00 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Andrzej Bialecki Cc: current@freebsd.org Subject: Re: FreeBSD build status In-reply-to: Your message of "Tue, 25 Apr 2000 17:57:30 +0200." Date: Tue, 25 Apr 2000 18:09:00 +0200 Message-ID: <54330.956678940@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Andrzej Bialecki writes: >On Tue, 25 Apr 2000, Poul-Henning Kamp wrote: > >> >> =================================== >> SUMMARY >> =================================== > >[27kB long list of errors deleted..] > >I thought that the final conclusion was to have some other mailing list >for this type of messages... ? I don't think there were any final conclusion, so I'm selectively forwarding it whenever something is broken. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 9:29:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from lightship.internal.homeport.org (breakwater.homeport.org [216.67.13.2]) by hub.freebsd.org (Postfix) with ESMTP id 1631637BDB7; Tue, 25 Apr 2000 09:29:24 -0700 (PDT) (envelope-from shevett@stonekeep.com) Received: from localhost (shevett@localhost) by lightship.internal.homeport.org (8.9.3/8.9.3) with ESMTP id QAA00262; Tue, 25 Apr 2000 16:30:46 -0400 (EDT) (envelope-from shevett@stonekeep.com) X-Authentication-Warning: lightship.internal.homeport.org: shevett owned process doing -bs Date: Tue, 25 Apr 2000 16:30:46 -0400 (EDT) From: Dave Belfer-Shevett X-Sender: shevett@localhost To: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Problems configuring Vadem VG-469 PCMCIA controller. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hiya folks. I'm running on FreeBSD 4.0-RELEASE, trying to get a Lucent Wavelan card (wi) working via an ActionTec PC700 PCMCIA controller (detail on this controller: http://www.actiontec.com/support/readers/pc700.html) I've been chatting with Bill (who wrote the 'wi' driver), and we can't seem to get this controller, which is apparently Plug N Play, to come up in the kernel. pnpinfo shows... [root@lightship]:~# pnpinfo Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID AEI0218 (0x1802a904), Serial Number 0x01234567 PnP Version 1.0, Vendor Version 0 Device Description: ACTIONTEC PNP PCMCIA ADAPTER Logical Device ID: AEI0218 0x1802a904 #0 Vendor register funcs 00 I/O Range 0x3e0 .. 0x3fe, alignment 0x2, len 0x2 [16-bit addr] End Tag Successfully got 4 resources, 1 logical fdevs -- card select # 0x0001 CSN AEI0218 (0x1802a904), Serial Number 0x01234567 Logical device #0 IO: 0x03e0 0x03e0 0x03e0 0x03e0 0x03e0 0x03e0 0x03e0 0x03e0 IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x01 The kernel reports: unknown0: at port 0x3e0-0x3e1 on isa0 I have this in my kernel config file: device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 I've tried changing the IRQ around by altering this line in the kernel file, to no avail. Any suggestions? Please? :) -------------------. Web-based problem management: www.stonekeep.com Dave Belfer-Shevett >----------------------------------------------------. shevett@pobox.com / 2.) HIRE YEW - complete sentence. remainder of \ ------------------< greeting. Usage: "Heidi, hire yew?" (from | | 'Hickphonics') | \______________________________________________________/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 9:57:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 66FC737C034 for ; Tue, 25 Apr 2000 09:57:18 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 11:57:09 -0500 From: Richard Wackerbarth To: Nate Williams Subject: Re: Archive pruning Date: Tue, 25 Apr 2000 11:57:08 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: current@FreeBSD.ORG References: <20000424185151.A36672@hub.freebsd.org> <00042422091401.16303@nomad.dataplex.net> <200004251609.KAA12689@nomad.yogotech.com> In-Reply-To: <200004251609.KAA12689@nomad.yogotech.com> MIME-Version: 1.0 Message-Id: <00042511570801.32593@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Nate Williams wrote: > No-one needs to grab a repository, unless they're looking at history. > Just use CVSup to grab the latest bits, no need to grab the entire > history. I find it virtually impossible to work with anything but the most stable without the recent part of the repository because I often have to "unbreak" something that was recently committed or is otherwise unfinished in order to get a working system. This is not a major complaint that I need to do so but rather the reason that I find simply cvsup'ing inadequate. > Users have the choice to take it all, since trying to build a 'pruned > repository' is alot of work (due to the way CVS does it's thing), Actually, it isn't. it can be automated rather easily based on parsing the CVS tags and using RCS primitives. The hard part is to get developers like yourself to recognize that they could refer to a CD for the old parts to the history and keep only the newer part in the online distribution. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 10: 9:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by hub.freebsd.org (Postfix) with ESMTP id C54B337B7D4 for ; Tue, 25 Apr 2000 10:09:46 -0700 (PDT) (envelope-from nate@nomad.yogotech.com) Received: from nomad.yogotech.com (mvdhcp141236.americas.nokia.com [172.18.141.236]) by mgw-x1.nokia.com (8.9.3/8.9.3) with ESMTP id TAA27778; Tue, 25 Apr 2000 19:10:28 +0300 (EETDST) X-Authentication-Warning: mgw-x1.nokia.com: Host mvdhcp141236.americas.nokia.com [172.18.141.236] claimed to be nomad.yogotech.com Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id KAA12689; Tue, 25 Apr 2000 10:09:02 -0600 (MDT) (envelope-from nate) Date: Tue, 25 Apr 2000 10:09:02 -0600 (MDT) Message-Id: <200004251609.KAA12689@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Wackerbarth Cc: Garrett Wollman , current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <00042422091401.16303@nomad.dataplex.net> References: <20000424185151.A36672@hub.freebsd.org> <200004250238.WAA37098@khavrinen.lcs.mit.edu> <00042422091401.16303@nomad.dataplex.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'd like to add that it can be particularly important when legal > > questions arise. > > You confuse the argument for SOME complete repositories with > the necessity that ALL (or at each most) repositories be so extensive. No-one needs to grab a repository, unless they're looking at history. Just use CVSup to grab the latest bits, no need to grab the entire history. Users have the choice to take it all, since trying to build a 'pruned repository' is alot of work (due to the way CVS does it's thing), so the all/nothing solution we have now should be good enough for 90% of the users, which is a pretty good solution considering the volunteer organization. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 10: 9:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by hub.freebsd.org (Postfix) with ESMTP id E7E5337BE71 for ; Tue, 25 Apr 2000 10:09:54 -0700 (PDT) (envelope-from nate@nomad.yogotech.com) Received: from nomad.yogotech.com (mvdhcp141236.americas.nokia.com [172.18.141.236]) by mgw-x1.nokia.com (8.9.3/8.9.3) with ESMTP id TAA07402; Tue, 25 Apr 2000 19:25:45 +0300 (EETDST) X-Authentication-Warning: mgw-x1.nokia.com: Host mvdhcp141236.americas.nokia.com [172.18.141.236] claimed to be nomad.yogotech.com Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id KAA12718; Tue, 25 Apr 2000 10:25:39 -0600 (MDT) (envelope-from nate) Date: Tue, 25 Apr 2000 10:25:39 -0600 (MDT) Message-Id: <200004251625.KAA12718@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Garrett Wollman Cc: Sheldon Hearn , current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <200004251440.KAA39180@khavrinen.lcs.mit.edu> References: <89056.956663223@axl.ops.uunet.co.za> <200004251440.KAA39180@khavrinen.lcs.mit.edu> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If that's the _only_ point, then Garrett Wollman's idea should work > > perfectly. Stick the files under CVS > > No, that was not my proposal. I want to keep them out of CVS > entirely. CVS is Not Good at handling binary files (even if you never > change them). That's why I'd like them in a separate hierarchy. Actually, CVS1.10 is *MUCH* better at handling binary files, although you must be sure to set them up as binary files. It works cross-platform and such, but if the file is not added as a binary file, it really gets nasty. ;( (Plus all of the size bloating issues, but that's a seperate issue IMO). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 10:28:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by hub.freebsd.org (Postfix) with ESMTP id A6BF337BD8B for ; Tue, 25 Apr 2000 10:28:36 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Received: from ix.netcom.com (sil-wa15-33.ix.netcom.com [207.93.148.33]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA17910 for ; Tue, 25 Apr 2000 13:28:34 -0400 (EDT) Received: (from tomdean@localhost) by ix.netcom.com (8.9.3/8.9.3) id KAA03679; Tue, 25 Apr 2000 10:28:23 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Date: Tue, 25 Apr 2000 10:28:23 -0700 (PDT) Message-Id: <200004251728.KAA03679@ix.netcom.com> X-Authentication-Warning: celebris.tddhome: tomdean set sender to tomdean@ix.netcom.com using -f From: "Thomas D. Dean" To: current@FreeBSD.ORG In-reply-to: (message from Andrzej Bialecki on Tue, 25 Apr 2000 17:57:30 +0200 (CEST)) Subject: Re: FreeBSD build status References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The summary may have saved lots of net time. I did not cvsup today because of the summary. tomdean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 10:42:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay02.chello.nl (relay02.chello.nl [212.83.68.146]) by hub.freebsd.org (Postfix) with ESMTP id 810AB37BD48 for ; Tue, 25 Apr 2000 10:42:36 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay02.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 99c8f334c649856e3f2cdadc4054e412) with ESMTP id <20000425174230.HIQA22628.relay02@chello.nl>; Tue, 25 Apr 2000 19:42:30 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id TAA00888; Tue, 25 Apr 2000 19:42:33 +0200 (CEST) (envelope-from wkb) Date: Tue, 25 Apr 2000 19:42:33 +0200 From: Wilko Bulte To: Andrzej Bialecki Cc: Paul Richards , "Brandon D. Valentine" , "Daniel C. Sobral" , Alok Dhir , "'Richard Wackerbarth'" , "'Matthew Dillon'" , "'freebsd-current@FreeBSD.ORG'" Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000425194233.A816@yedi.wbnet> Reply-To: wc.bulte@chello.nl References: <39056A21.C58ED54A@originative.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from abial@webgiro.com on Tue, Apr 25, 2000 at 05:54:20PM +0200 X-OS: FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 05:54:20PM +0200, Andrzej Bialecki wrote: > On Tue, 25 Apr 2000, Paul Richards wrote: > > branch. Most commercial users are not developers, and have no interest > > in anything relating to development. Professional sysadmins are > > conservative creatures, they expect professional quality code to play by > > the rules of the industry and those rules are widely accepted as meaning > > that stable branches do no undergo ABI changes. Such changes are > > reserved for major upgrades because of the consequences and risks > > involved. > On a similar note: I think one of serious drawbacks of FreeBSD's model for > updating and bugfixing the stable branch is 'make world'. It's very > inefficient and cumbersome way to do this on production machines. STABLE > is stable enough for us to be able to prepare binary patches, which can be > applied to a system in some (known) version. Especially security fixes, > which are usually limited to specific programs. > With such system present I'd be completely satisfied (as a production > manager, not as a developer) if I could start with, let's say, > 3.4-RELEASE, and then apply binary patches one by one to track > STABLE. Instead of putting the machine out-of-service for a couple of > hours, it would be 10 minutes. Also, no need to keep the sources > around. Of course, implementing such a system requires careful versioning > of each file in the standard system, but I think it's possible - just > having the MD5 checksums around, for each consecutive patch, should do for > start. Number 1 problem that I see here is the amount of resources it needs to do this. It appears this is hardly the kind of work somebody would want to volunteer for. Question: are MD5 checksums the same for each and every build (assuming static sources obviously) or is there some timestamp (or something like that) in the generated binary. If there is, one could only create binary patches relative to a -release. -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 11: 0:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 209DD37BD66 for ; Tue, 25 Apr 2000 11:00:38 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 13:00:29 -0500 From: Richard Wackerbarth To: wc.bulte@chello.nl Subject: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility Date: Tue, 25 Apr 2000 13:00:28 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: References: <39056A21.C58ED54A@originative.co.uk> <20000425194233.A816@yedi.wbnet> In-Reply-To: <20000425194233.A816@yedi.wbnet> MIME-Version: 1.0 Message-Id: <00042513002803.32593@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Wilko Bulte wrote: > > On a similar note: I think one of serious drawbacks of FreeBSD's model > > for updating and bugfixing the stable branch is 'make world'. It's very > > inefficient and cumbersome way to do this on production machines. STABLE > > is stable enough for us to be able to prepare binary patches, which can > > be applied to a system in some (known) version. > Question: are MD5 checksums the same for each and every > build (assuming static sources obviously) or is there some timestamp (or > something like that) in the generated binary. If there is, one could only > create binary patches relative to a -release. Here your logic is wrong. When I make a binary patch, I don't HAVE to update anything that is not substantively changed. Think "make all" rather than "make world". From there, it is easy enough to generate a chain of patches just like CTM does for the sources. However, is it worth the effort? I don't know. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 11:16:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144]) by hub.freebsd.org (Postfix) with ESMTP id 8C93C37B575 for ; Tue, 25 Apr 2000 11:16:04 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay01.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 99c8f334c649856e3f2cdadc4054e412) with ESMTP id <20000425181611.NREQ5152.relay01@chello.nl>; Tue, 25 Apr 2000 20:16:11 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id UAA01204; Tue, 25 Apr 2000 20:16:00 +0200 (CEST) (envelope-from wkb) Date: Tue, 25 Apr 2000 20:16:00 +0200 From: Wilko Bulte To: Richard Wackerbarth Cc: wc.bulte@chello.nl, freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility Message-ID: <20000425201600.A1134@yedi.wbnet> Reply-To: wc.bulte@chello.nl References: <39056A21.C58ED54A@originative.co.uk> <20000425194233.A816@yedi.wbnet> <00042513002803.32593@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <00042513002803.32593@nomad.dataplex.net>; from rkw@dataplex.net on Tue, Apr 25, 2000 at 01:00:28PM -0500 X-OS: FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 01:00:28PM -0500, Richard Wackerbarth wrote: > On Tue, 25 Apr 2000, Wilko Bulte wrote: > > > > On a similar note: I think one of serious drawbacks of FreeBSD's model > > > for updating and bugfixing the stable branch is 'make world'. It's very > > > inefficient and cumbersome way to do this on production machines. STABLE > > > is stable enough for us to be able to prepare binary patches, which can > > > be applied to a system in some (known) version. > > > Question: are MD5 checksums the same for each and every > > build (assuming static sources obviously) or is there some timestamp (or > > something like that) in the generated binary. If there is, one could only > > create binary patches relative to a -release. > > Here your logic is wrong. When I make a binary patch, I don't HAVE to update > anything that is not substantively changed. Think "make all" rather than OK. But you do have to uniquely identify the binary that needs to be patched. So, my question is when you generate 10x the same binary, will all these 10 binaries have the same MD5 checksum? In other words: if people did a local buildworld once on a -release sourcetree will all the executables have the same MD5 as the ones on the -release cdrom? > "make world". From there, it is easy enough to generate a chain of patches > just like CTM does for the sources. > However, is it worth the effort? I don't know. I assume it is worth it to some end-users. The question is if the project can find someone to do it ;) -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 11:20:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6A09B37B607 for ; Tue, 25 Apr 2000 11:20:44 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA08840 for ; Tue, 25 Apr 2000 11:19:53 -0700 Date: Tue, 25 Apr 2000 11:20:42 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: freebsd-current@freebsd.org Subject: cc1 sig 11'ing recently? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Any getting these too? ild-tools cd /usr/src/bin/sh; make build-tools cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat -c /usr/src/bin/sh/mkinit.c cc: Internal compiler error: program cc1 got fatal signal 11 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 11:50:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A392337BD87 for ; Tue, 25 Apr 2000 11:50:51 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA40162; Tue, 25 Apr 2000 14:50:46 -0400 (EDT) (envelope-from wollman) Date: Tue, 25 Apr 2000 14:50:46 -0400 (EDT) From: Garrett Wollman Message-Id: <200004251850.OAA40162@khavrinen.lcs.mit.edu> To: wc.bulte@chello.nl Cc: Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000425201600.A1134@yedi.wbnet> References: <39056A21.C58ED54A@originative.co.uk> <20000425194233.A816@yedi.wbnet> <00042513002803.32593@nomad.dataplex.net> <20000425201600.A1134@yedi.wbnet> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > In other words: if people did a local buildworld once on a -release > sourcetree will all the executables have the same MD5 as the ones on > the -release cdrom? No. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 12: 0:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144]) by hub.freebsd.org (Postfix) with ESMTP id E3C9937BF4F for ; Tue, 25 Apr 2000 12:00:23 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay01.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 99c8f334c649856e3f2cdadc4054e412) with ESMTP id <20000425190028.NZYV5152.relay01@chello.nl>; Tue, 25 Apr 2000 21:00:28 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id VAA01470; Tue, 25 Apr 2000 21:00:17 +0200 (CEST) (envelope-from wkb) Date: Tue, 25 Apr 2000 21:00:17 +0200 From: Wilko Bulte To: Garrett Wollman Cc: wc.bulte@chello.nl, Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility Message-ID: <20000425210017.A1430@yedi.wbnet> Reply-To: wc.bulte@chello.nl References: <39056A21.C58ED54A@originative.co.uk> <20000425194233.A816@yedi.wbnet> <00042513002803.32593@nomad.dataplex.net> <20000425201600.A1134@yedi.wbnet> <200004251850.OAA40162@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004251850.OAA40162@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Apr 25, 2000 at 02:50:46PM -0400 X-OS: FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 02:50:46PM -0400, Garrett Wollman wrote: > < said: > > > In other words: if people did a local buildworld once on a -release > > sourcetree will all the executables have the same MD5 as the ones on > > the -release cdrom? > > No. I love binary answers :-) Which brings me to my original point: it looks like you can only do binary patches relative to a -release. Unless you want to blindly patch and hope for the best. Rather unlikely. -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 12: 4:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 6742B37BD4A for ; Tue, 25 Apr 2000 12:04:25 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA40198; Tue, 25 Apr 2000 15:04:18 -0400 (EDT) (envelope-from wollman) Date: Tue, 25 Apr 2000 15:04:18 -0400 (EDT) From: Garrett Wollman Message-Id: <200004251904.PAA40198@khavrinen.lcs.mit.edu> To: wc.bulte@chello.nl Cc: Garrett Wollman , Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000425210017.A1430@yedi.wbnet> References: <39056A21.C58ED54A@originative.co.uk> <20000425194233.A816@yedi.wbnet> <00042513002803.32593@nomad.dataplex.net> <20000425201600.A1134@yedi.wbnet> <200004251850.OAA40162@khavrinen.lcs.mit.edu> <20000425210017.A1430@yedi.wbnet> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > I love binary answers :-) Which brings me to my original point: it looks > like you can only do binary patches relative to a -release. Unless > you want to blindly patch and hope for the best. Rather unlikely. I think you are right. Doing so would still require resolving the full dependency graph, so that programs affected by a library change could all be identified. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 12:12:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 284C337BD4A for ; Tue, 25 Apr 2000 12:12:10 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 14:12:02 -0500 From: Richard Wackerbarth To: wc.bulte@chello.nl Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility Date: Tue, 25 Apr 2000 14:12:01 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: <39056A21.C58ED54A@originative.co.uk> <00042513002803.32593@nomad.dataplex.net> <20000425201600.A1134@yedi.wbnet> In-Reply-To: <20000425201600.A1134@yedi.wbnet> MIME-Version: 1.0 Message-Id: <00042514120105.32593@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Wilko Bulte wrote: > In other words: if people did > a local buildworld once on a -release sourcetree will all the executables > have the same MD5 as the ones on the -release cdrom? If you are using someone's patches, you must be patching the files that they provided. If you have created your own "imposters", you cannot expect to patch them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 12:38:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id F253937BDE5 for ; Tue, 25 Apr 2000 12:38:37 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id UAA21231; Tue, 25 Apr 2000 20:38:35 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id UAA31746; Tue, 25 Apr 2000 20:38:30 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200004251938.UAA31746@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: current@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: FreeBSD build status In-Reply-To: Message from Poul-Henning Kamp of "Tue, 25 Apr 2000 16:06:13 +0200." <53739.956671573@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Apr 2000 20:38:30 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > =================================== > SUMMARY > =================================== > World > compiled > 637 Warnings > 45 Errors > Kernel LINT > compiled > 149 Warnings > 0 Errors > Kernel GENERIC > compiled > 59 Warnings > 0 Errors > Kernel GENERIC98 > ***didn't compile*** > 54 Warnings > 0 Errors This doesn't look right.... I count two :) -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 12:38:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 944EF37BDD5; Tue, 25 Apr 2000 12:38:40 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id MAA11553; Tue, 25 Apr 2000 12:38:40 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 25 Apr 2000 12:38:39 -0700 (PDT) From: Kris Kennaway To: wc.bulte@chello.nl Cc: Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000425201600.A1134@yedi.wbnet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Wilko Bulte wrote: > OK. But you do have to uniquely identify the binary that needs to be > patched. So, my question is when you generate 10x the same binary, will all > these 10 binaries have the same MD5 checksum? In other words: if people did > a local buildworld once on a -release sourcetree will all the executables > have the same MD5 as the ones on the -release cdrom? I don't think a binary patch is workable: all it takes is a single local buildworld and you've got an unpatchable system. Furthermore, I'd speculate that binary patches would usually be on the same order of size as the file itself. What *would* work is including the entire new file in the package. This is what solaris does. However, there are serious regression-testing and dependency problems with a scheme like this - i.e. making sure you've included *all* of the relevant changes. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 12:47:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 3FEB237B5C8; Tue, 25 Apr 2000 12:47:47 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id MAA12281; Tue, 25 Apr 2000 12:47:46 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 25 Apr 2000 12:47:46 -0700 (PDT) From: Kris Kennaway To: Richard Wackerbarth Cc: Nate Williams , current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <00042511570801.32593@nomad.dataplex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Richard Wackerbarth wrote: > Actually, it isn't. it can be automated rather easily based on parsing the > CVS tags and using RCS primitives. > > The hard part is to get developers like yourself to recognize that they could > refer to a CD for the old parts to the history and keep only the newer part > in the online distribution. I told myself I wouldn't get into this debate with you again, Richard, but you're not listening. The vast majority (all? I might have missed one) of the other respondants have said they WANT to have the complete repository. The above paragraph where you say these people should learn to use your scheme instead shows that you don't get it. It seems to be basically only you who wants this, so please either do the work yourself and make it available, or stop trying to push your ideas on the rest of us who have told you (again) that we don't think they're worthwhile. If it's as easy as you claim them you could automate it and make your own cvsup server which carries the repo-lite you so badly want. Kris P.S. Please don't tell me I'm being a "sandbox developer", because I've yet to see the hordes of non-developers crying out for this system either. ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 12:48:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 9B51637BF42 for ; Tue, 25 Apr 2000 12:48:31 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA55226; Tue, 25 Apr 2000 21:47:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: current@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: FreeBSD build status In-reply-to: Your message of "Tue, 25 Apr 2000 20:38:30 BST." <200004251938.UAA31746@hak.lan.Awfulhak.org> Date: Tue, 25 Apr 2000 21:47:37 +0200 Message-ID: <55224.956692057@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200004251938.UAA31746@hak.lan.Awfulhak.org>, Brian Somers writes: >> =================================== >> SUMMARY >> =================================== >> World >> compiled >> 637 Warnings >> 45 Errors >> Kernel LINT >> compiled >> 149 Warnings >> 0 Errors >> Kernel GENERIC >> compiled >> 59 Warnings >> 0 Errors >> Kernel GENERIC98 >> ***didn't compile*** >> 54 Warnings >> 0 Errors > >This doesn't look right.... I count two :) Uhm, Right, I'd better check my script :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:11:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id F144D37B6AF; Tue, 25 Apr 2000 13:11:03 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 15:10:53 -0500 From: Richard Wackerbarth To: Kris Kennaway Subject: Re: Archive pruning Date: Tue, 25 Apr 2000 15:10:53 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: In-Reply-To: Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <00042515105300.02802@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, you wrote: > I told myself I wouldn't get into this debate with you again, Richard, but > you're not listening. The vast majority (all? I might have missed one) of > the other respondants Actually, I didn't start this. Someone else brought up the idea. > P.S. Please don't tell me I'm being a "sandbox developer", because I've > yet to see the hordes of non-developers crying out for this system either. I don't disagree that the majority of the readers of this list are not interested. The quiet majority that might benefit are not very likely to speak up when they are told some is impossible. After all, they are at the mercy of the very developers who oppose change because it does not directly benefit the developers. I do object to the characterization by these developers that it CANNOT be done. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:13:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id BE3CF37B81E; Tue, 25 Apr 2000 13:13:45 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id NAA15001; Tue, 25 Apr 2000 13:13:44 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 25 Apr 2000 13:13:44 -0700 (PDT) From: Kris Kennaway To: Richard Wackerbarth Cc: current@freebsd.org Subject: Re: Archive pruning In-Reply-To: <00042515105300.02802@nomad.dataplex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Richard Wackerbarth wrote: > Actually, I didn't start this. Someone else brought up the idea. ...and quickly decided it was not worthwhile. > The quiet majority that might benefit are not very likely to speak up when > they are told some is impossible. After all, they are at the mercy of the > very developers who oppose change because it does not directly benefit > the developers. > > I do object to the characterization by these developers that it CANNOT be > done. I haven't heard anyone say that. What I have heard is "too much work for too little gain". If you still disagree, it's time to put up or shut up :-) Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:15:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id BC08D37BED5; Tue, 25 Apr 2000 13:15:11 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 15:15:04 -0500 From: Richard Wackerbarth To: kris@FreeBSD.org Subject: Re: Patchkits Date: Tue, 25 Apr 2000 15:15:03 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-current@FreeBSD.org References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00042515150301.02802@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Kris Kennaway wrote: > On Tue, 25 Apr 2000, Wilko Bulte wrote: > > OK. But you do have to uniquely identify the binary that needs to be > > patched. So, my question is when you generate 10x the same binary, will > > all these 10 binaries have the same MD5 checksum? In other words: if > > people did a local buildworld once on a -release sourcetree will all the > > executables have the same MD5 as the ones on the -release cdrom? > > I don't think a binary patch is workable: all it takes is a single local > buildworld and you've got an unpatchable system. Furthermore, I'd > speculate that binary patches would usually be on the same order of size > as the file itself. What *would* work is including the entire new file in > the package. This is what solaris does. > > However, there are serious regression-testing and dependency problems with > a scheme like this - i.e. making sure you've included *all* of the > relevant changes. Sounds like a package manager from another OS. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:26:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by hub.freebsd.org (Postfix) with ESMTP id 2127437BD75 for ; Tue, 25 Apr 2000 13:26:31 -0700 (PDT) (envelope-from nate@nomad.yogotech.com) Received: from nomad.yogotech.com (mvdhcp141236.americas.nokia.com [172.18.141.236]) by mgw-x1.nokia.com (8.9.3/8.9.3) with ESMTP id XAA18720; Tue, 25 Apr 2000 23:26:24 +0300 (EETDST) X-Authentication-Warning: mgw-x1.nokia.com: Host mvdhcp141236.americas.nokia.com [172.18.141.236] claimed to be nomad.yogotech.com Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id OAA13776; Tue, 25 Apr 2000 14:22:06 -0600 (MDT) (envelope-from nate) Date: Tue, 25 Apr 2000 14:22:06 -0600 (MDT) Message-Id: <200004252022.OAA13776@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Wackerbarth Cc: Nate Williams , current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <00042511570801.32593@nomad.dataplex.net> References: <20000424185151.A36672@hub.freebsd.org> <00042422091401.16303@nomad.dataplex.net> <200004251609.KAA12689@nomad.yogotech.com> <00042511570801.32593@nomad.dataplex.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > No-one needs to grab a repository, unless they're looking at history. > > Just use CVSup to grab the latest bits, no need to grab the entire > > history. > > I find it virtually impossible to work with anything but the most stable > without the recent part of the repository because I often have to "unbreak" > something that was recently committed or is otherwise unfinished in order to > get a working system. I consider you a very small minority. A user who is not a developer, but who could be a developer. The amount of work it would take to support your needs is way too much work, and it would only benefit < 1-2% of the user base. Does this mean we don't care about all our users? Of course not, but when the same amount of time/effort can positively effect > 50% of the user base, then it makes more sense to spend the time more wisely. > > Users have the choice to take it all, since trying to build a 'pruned > > repository' is alot of work (due to the way CVS does it's thing), > > Actually, it isn't. it can be automated rather easily based on parsing the > CVS tags and using RCS primitives. Actually, it can't be. You can get about 90% of the way automatically, and the remaining 10% requires human intervention (due to the way Attics and tags are used). Really it can't. (Tried it in a previous project, we gave up and ended up building a new repository). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:30:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 9A85137BE17; Tue, 25 Apr 2000 13:30:36 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 15:30:28 -0500 From: Richard Wackerbarth To: Kris Kennaway Subject: Re: Archive pruning Date: Tue, 25 Apr 2000 15:30:27 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: current@FreeBSD.org References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00042515302702.02802@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Kris Kennaway wrote: > On Tue, 25 Apr 2000, Richard Wackerbarth wrote: > > Actually, I didn't start this. Someone else brought up the idea. > > ...and quickly decided it was not worthwhile. Yes, the developers do a good job of repressing opinions that differ from their own. > > The quiet majority that might benefit are not very likely to speak up > > when they are told some is impossible. After all, they are at the mercy > > of the very developers who oppose change because it does not directly > > benefit the developers. > > > > I do object to the characterization by these developers that it CANNOT be > > done. > > I haven't heard anyone say that. What I have heard is "too much work for > too little gain". If you still disagree, it's time to put up or shut up And if I put up, will you (the organization) use it? It's certainly too much work to prove the obvious. I don't have to convince myself of anything. The only value accrues if it gets used. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:32:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.102.114]) by hub.freebsd.org (Postfix) with ESMTP id 5317337BA91; Tue, 25 Apr 2000 13:32:46 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.3) id NAA42187; Tue, 25 Apr 2000 13:32:43 -0700 (PDT) (envelope-from mph) Date: Tue, 25 Apr 2000 13:32:42 -0700 From: Matthew Hunt To: Richard Wackerbarth Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000425133242.A42075@wopr.caltech.edu> References: <00042515105300.02802@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00042515105300.02802@nomad.dataplex.net>; from rkw@dataplex.net on Tue, Apr 25, 2000 at 03:10:53PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 03:10:53PM -0500, Richard Wackerbarth wrote: > The quiet majority that might benefit are not very likely to speak up when > they are told some is impossible. After all, they are at the mercy of the > very developers who oppose change because it does not directly benefit > the developers. Maintaining a CVS repository is necessary only if you are working on the code, so your proposal would only affect devlopers, not Joe User. Normal users do not maintain copies of the repository and do not have a frequent need to examine history. There's always cvsweb for occasional browsing. > I do object to the characterization by these developers that it CANNOT be > done. I don't remember anyone saying that. Obviously, it can be done. It's just that nobody wants to, except you. Guess what: That means you get to do it, or stop whining! If all of the committers chip in $0.15 apiece to buy you a big enough disk, will you stop wasting our time about this? -- Matthew Hunt * Science rules. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:36:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 96D0D37B6AF; Tue, 25 Apr 2000 13:36:47 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id NAA16960; Tue, 25 Apr 2000 13:36:47 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 25 Apr 2000 13:36:47 -0700 (PDT) From: Kris Kennaway To: Richard Wackerbarth Cc: current@FreeBSD.org Subject: Re: Archive pruning In-Reply-To: <00042515302702.02802@nomad.dataplex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Richard Wackerbarth wrote: > Yes, the developers do a good job of repressing opinions that differ from > their own. Thats an interesting revision of the plain facts. > And if I put up, will you (the organization) use it? It's certainly too much > work to prove the obvious. I don't have to convince myself of anything. > The only value accrues if it gets used. Why would "The Project" have to do anything? We've already established this is of minority appeal, and if you do this properly then it would just be a matter of interested users cvsupping from your cvsup server instead of one of the standard ones. You might even convince one or two of the mirror sites to mirror it. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:41: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.102.114]) by hub.freebsd.org (Postfix) with ESMTP id B224737BBA7; Tue, 25 Apr 2000 13:41:04 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.3) id NAA42453; Tue, 25 Apr 2000 13:41:01 -0700 (PDT) (envelope-from mph) Date: Tue, 25 Apr 2000 13:41:01 -0700 From: Matthew Hunt To: Richard Wackerbarth Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000425134101.A42364@wopr.caltech.edu> References: <00042515302702.02802@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00042515302702.02802@nomad.dataplex.net>; from rkw@dataplex.net on Tue, Apr 25, 2000 at 03:30:27PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 03:30:27PM -0500, Richard Wackerbarth wrote: > And if I put up, will you (the organization) use it? It's certainly too much I cannot remember anybody ever having a guarantee that their submission will be incorporated into FreeBSD, code-unseen. That's not how it works. So, I suppose you can now go off and whimper about how closed-minded we are and not bother writing any code, just like countless people before you have. Easy, huh? -- Matthew Hunt * Science rules. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:45:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id C1E0E37BD9D for ; Tue, 25 Apr 2000 13:45:30 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 12kCCu-000MNc-0B; Tue, 25 Apr 2000 20:45:20 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA26414; Tue, 25 Apr 2000 21:45:13 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 25 Apr 2000 21:50:25 +0100 (BST) From: Doug Rabson To: Jake Burkholder Cc: Bruce Evans , Boris Popov , freebsd-current@freebsd.org Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000425160340.AE322BCA7@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Jake Burkholder wrote: > > On Tue, 25 Apr 2000, Boris Popov wrote: > > > > > simple_lock* functions has breakage too. They defined as macros > > > for non-SMP case and as functions for SMP. > > > > This currently apparently affects the following modules: > > > > ccd > > cd9660 > > msdosfs > > nfs > > ntfs > > nwfs > > vinum > > > > All of these functions reference simple_lock() if it is not defined away. > > > > Bruce > > Has anyone thought about using kobj(9) for this? > > For example, it should be possible to make simple_lock and lockmgr locks > safe for use from modules by introducing a lock_if.h, which has > abstract version of all the lock routines. A class would be compiled > with null implementations for UP, or the 'lock'ed implementations for SMP. > The old functions would call through an instance of that class, automagically > finding the right method. Eventually this could be a runtime abstraction, > with both up and smp classes compiled into the kernel, and objects initialized > with the right method table at boot time. > > I have diffs in the works if anyone is interested. Its nice to see someone actually using kobj so soon. There is a possible performance problem though - kobj method calls are roughly 20% slower than direct function calls. Having said that, this isn't that slow - I timed a method call to a two argument function at ~40ns on a 300MHz PII. I could improve this for some applications (including this one) by providing a mechanism for an application to cache the function pointer returned by the method lookup. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 13:55:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id 3954C37BA91; Tue, 25 Apr 2000 13:55:25 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (01-108.dial.008.popsite.net [209.69.194.108]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id NAA15387; Tue, 25 Apr 2000 13:55:01 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id 5BAB8192E; Tue, 25 Apr 2000 16:54:30 -0400 (EDT) Date: Tue, 25 Apr 2000 16:54:30 -0400 From: Will Andrews To: Richard Wackerbarth Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000425165430.A358@argon.blackdawn.com> References: <00042515302702.02802@nomad.dataplex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <00042515302702.02802@nomad.dataplex.net>; from rkw@dataplex.net on Tue, Apr 25, 2000 at 03:30:27PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 03:30:27PM -0500, Richard Wackerbarth wrote: > Yes, the developers do a good job of repressing opinions that differ from > their own. It should be noted that the person who brought this up was a developer. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 14: 1:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 5ED4837BBA7 for ; Tue, 25 Apr 2000 14:01:34 -0700 (PDT) (envelope-from bandix@looksharp.net) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id RAA38775; Tue, 25 Apr 2000 17:02:05 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Tue, 25 Apr 2000 17:02:05 -0400 (EDT) From: "Brandon D. Valentine" To: Andrzej Bialecki Cc: freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000425201600.A1134@yedi.wbnet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Wilko Bulte wrote: >OK. But you do have to uniquely identify the binary that needs to be >patched. So, my question is when you generate 10x the same binary, will all >these 10 binaries have the same MD5 checksum? In other words: if people did >a local buildworld once on a -release sourcetree will all the executables >have the same MD5 as the ones on the -release cdrom? Any place I have used the pronoun 'you' below is a reference to Andrzej Bialecki, originator of the thread, and not Wilko Bulte, who happened to provide a nice starting point for my response. Ideally, yes. But this assumes that the binaries are built on the same architecture with the same compiler options(especially optimizations). If you feed it the same asm as86 should always generate the same binary. Of course the minute you change compiler versions or add a different -march or -O flag to gcc you run the risk of ending up with slightly different binary code. To do this using checksums would be problematic. The only way something like this is feasible is if the binaries themselves contain information about what version they are. In other words some sort of a header in the binary which contains the RCS version number the binary was compiled from so that whatever method you were using to sync your "binary" trees(no pun intended) so to speak can compare RCS tags just as you would do with source. If you were to implement this you'd probably check the binary versions against the remote repository and then any outdated binaries would have a replacement downloaded into /usr/upgrade or some such directory where one could later chdir and run a Makefile from single user mode to move those new binaries into place. Since there are already servers which generate nightly binary snapshots the problem of keeping a -STABLE binary set available is already solved. If you want to do this you need to come up with a cvsup patchset to support this and a proposal for how to keep RCS tags available in the binary header without breaking compatibility. You also need to believe strongly in the necessity of such a system and you need to convince the project that it is important and will not place a further strain on the project's resources. Ideally a system like this could be used to replace the current upgrade knob in sysinstall. I just don't know that this is as pressing an issue at the moment as some of the other projects going on in the source tree so if it is going to happen someone(namely you) is going to need to volunteer. Brandon D. Valentine -- bandix@looksharp.net Illegitimi non carborundum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 14: 2:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from hun.org (hun.org [216.190.28.252]) by hub.freebsd.org (Postfix) with ESMTP id 752A837B684 for ; Tue, 25 Apr 2000 14:02:37 -0700 (PDT) (envelope-from attila@hun.org) Received: (from attila@localhost) by hun.org (8.9.3/8.9.2) id VAA02257; Tue, 25 Apr 2000 21:02:34 GMT (envelope-from attila) Date: Tue, 25 Apr 2000 21:02:34 GMT Message-Id: <200004252102.VAA02257@hun.org> From: attila! Organization: hun.org, over 40 years beyond the fringe home for unpenitent hackers and anarcho-cryptophreaks Mailer: FreeBSD 5.0-CURRENT with XEmacs V20.4 (see alt.religion.emacs) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit; Content-Disposition: Inline To: freebsd-current@FreeBSD.org Subject: usr.sbin/xntpd missing in 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG in 5.0-CURRENT as of this morning (Tue, 25) usr.sbin/xntpd was not in the cvs files. too a copy from a 3.1 disk; same version 3.4e. --it works. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 14: 7:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id DF11337B67E for ; Tue, 25 Apr 2000 14:07:36 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 16:07:25 -0500 From: Richard Wackerbarth To: Matthew Hunt Subject: Re: Archive pruning Date: Tue, 25 Apr 2000 16:07:25 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: current@freebsd.org References: <00042515105300.02802@nomad.dataplex.net> <20000425133242.A42075@wopr.caltech.edu> In-Reply-To: <20000425133242.A42075@wopr.caltech.edu> MIME-Version: 1.0 Message-Id: <00042516072501.02814@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Matthew Hunt wrote: > Maintaining a CVS repository is necessary only if you are working > on the code, I disagree. Anyone who attempts to run "-current" on a regular basis needs the recent history to cobble together a working system. It is also very helpful if you are a "tester" and are willing to do more than provide "Buildworld is broken today" feedback. >There's always cvsweb for occasional browsing. If you are reasonably well connected. > If all of the committers chip in $0.15 apiece to buy you a big enough > disk, will you stop wasting our time about this? I already spent a few $100 to get 18GB on my laptop. That doesn't change my argument about the value. The costs are much more than just HD space. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 14:10:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id DCB0037BE3C for ; Tue, 25 Apr 2000 14:10:01 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 25 Apr 2000 22:09:52 +0100 (BST) Date: Tue, 25 Apr 2000 22:09:51 +0100 From: David Malone To: attila! Cc: freebsd-current@FreeBSD.org Subject: Re: usr.sbin/xntpd missing in 5.0-CURRENT Message-ID: <20000425220951.A24724@walton.maths.tcd.ie> References: <200004252102.VAA02257@hun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004252102.VAA02257@hun.org>; from attila@hun.org on Tue, Apr 25, 2000 at 09:02:34PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 09:02:34PM +0000, attila! wrote: > in 5.0-CURRENT as of this morning (Tue, 25) usr.sbin/xntpd > was not in the cvs files. It was replaced with ntpd some time ago wasn't it? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 14:12:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from css-1.cs.iastate.edu (css-1.cs.iastate.edu [129.186.3.24]) by hub.freebsd.org (Postfix) with ESMTP id C288637B684 for ; Tue, 25 Apr 2000 14:12:40 -0700 (PDT) (envelope-from ghelmer@cs.iastate.edu) Received: from popeye.cs.iastate.edu (ghelmer@popeye.cs.iastate.edu [129.186.3.4]) by css-1.cs.iastate.edu (8.9.0/8.9.0) with ESMTP id QAA10479; Tue, 25 Apr 2000 16:12:34 -0500 (CDT) Received: from localhost (ghelmer@localhost) by popeye.cs.iastate.edu (8.9.0/8.9.0) with ESMTP id QAA18475; Tue, 25 Apr 2000 16:12:32 -0500 (CDT) X-Authentication-Warning: popeye.cs.iastate.edu: ghelmer owned process doing -bs Date: Tue, 25 Apr 2000 16:12:31 -0500 (CDT) From: Guy Helmer To: attila! Cc: freebsd-current@FreeBSD.ORG Subject: Re: usr.sbin/xntpd missing in 5.0-CURRENT In-Reply-To: <200004252102.VAA02257@hun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, attila! wrote: > in 5.0-CURRENT as of this morning (Tue, 25) usr.sbin/xntpd > was not in the cvs files. > > too a copy from a 3.1 disk; same version 3.4e. --it works. usr.sbin/ntpd (NTP 4.0.99b) replaced xntpd 3.x last December... Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 14:15:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by hub.freebsd.org (Postfix) with ESMTP id A003637BE90 for ; Tue, 25 Apr 2000 14:15:19 -0700 (PDT) (envelope-from brdavis@orion.ac.hmc.edu) Received: (from brdavis@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) id OAA12666; Tue, 25 Apr 2000 14:15:14 -0700 (PDT) Date: Tue, 25 Apr 2000 14:15:14 -0700 From: Brooks Davis To: attila! Cc: freebsd-current@FreeBSD.ORG Subject: Re: usr.sbin/xntpd missing in 5.0-CURRENT Message-ID: <20000425141514.A9645@orion.ac.hmc.edu> References: <200004252102.VAA02257@hun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <200004252102.VAA02257@hun.org>; from attila@hun.org on Tue, Apr 25, 2000 at 09:02:34PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 09:02:34PM +0000, attila! wrote: > in 5.0-CURRENT as of this morning (Tue, 25) usr.sbin/xntpd > was not in the cvs files. xntpd is obsolete. It has been replaced with ntpd. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 14:16:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 39AC437B534; Tue, 25 Apr 2000 14:16:25 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA19590; Tue, 25 Apr 2000 14:17:16 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Richard Wackerbarth Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: Archive pruning In-reply-to: Your message of "Tue, 25 Apr 2000 15:30:27 CDT." <00042515302702.02802@nomad.dataplex.net> Date: Tue, 25 Apr 2000 14:17:16 -0700 Message-ID: <19587.956697436@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And if I put up, will you (the organization) use it? It's certainly too much > work to prove the obvious. I don't have to convince myself of anything. > The only value accrues if it gets used. Erm, haven't we been here with you before? I can even replay the script from heart: 1. Richard comes up with some total crack-smoking idea that only he and a few people hanging around the men's room at grand central station appear to like. 2. Richard demands that this idea be implemented for everyone, both for the men's room crowd and everyone who's passing through grand central on their way to somewhere else. 3. Richard is told to prove and adequately demonstrate the genuine medical merits of smoking crack if he wants something like this to happen since the other folks always thought it was bad for you and besides, they're too busy to take up new and expensive vices. 4. Richard agrees to do so ONLY on the condition that everyone buy crack pipes and an ample supply of crack in advance, just on the off-chance that he's proven right about its benefits. 5. People refuse to do any such thing and the proposal collapses. 6. Go to step 1. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 14:57:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 1044837BFA0; Tue, 25 Apr 2000 14:57:31 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id OAA26307; Tue, 25 Apr 2000 14:57:30 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 25 Apr 2000 14:57:30 -0700 (PDT) From: Kris Kennaway To: "Brandon D. Valentine" Cc: Andrzej Bialecki , freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Brandon D. Valentine wrote: > The only way something like this is feasible is if the binaries > themselves contain information about what version they are. In other > words some sort of a header in the binary which contains the RCS version > number the binary was compiled from so that whatever method you were You've never run ident(1), right? :) Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 15: 6:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 47F0C37B606 for ; Tue, 25 Apr 2000 15:06:33 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 17:06:27 -0500 From: Richard Wackerbarth To: "Jordan K. Hubbard" Subject: Re: Archive pruning Date: Tue, 25 Apr 2000 17:06:25 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: current@FreeBSD.ORG References: <19587.956697436@zippy.cdrom.com> In-Reply-To: <19587.956697436@zippy.cdrom.com> MIME-Version: 1.0 Message-Id: <00042517062506.02814@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Jordan K. Hubbard wrote: > > And if I put up, will you (the organization) use it? It's certainly too > > much work to prove the obvious. I don't have to convince myself of > > anything. The only value accrues if it gets used. > > Erm, haven't we been here with you before? I can even replay the > script from heart: > > 1. Richard comes up with some total crack-smoking idea that only he > and a few people hanging around the men's room at grand central > station appear to like. Dig tunnels and get the trains off the streets. > 5. People refuse to do any such thing and the proposal collapses. > > 6. Go to step 1. After you sit at the train crossing waiting for the train to pass. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 16:58:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id D9B9B37B56A; Tue, 25 Apr 2000 16:58:48 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: from shell-2.enteract.com (dscheidt@shell-2.enteract.com [207.229.143.41]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id SAA16449; Tue, 25 Apr 2000 18:58:45 -0500 (CDT) (envelope-from dscheidt@enteract.com) Date: Tue, 25 Apr 2000 18:58:45 -0500 (CDT) From: David Scheidt To: Matthew Hunt Cc: Richard Wackerbarth , Kris Kennaway , current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <20000425133242.A42075@wopr.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Matthew Hunt wrote: > Maintaining a CVS repository is necessary only if you are working > on the code, so your proposal would only affect devlopers, not Joe > User. Normal users do not maintain copies of the repository and do > not have a frequent need to examine history. There's always cvsweb > for occasional browsing. This isn't quite true. A repository is very handy if you have a number of different enviornments, two or three STABLEs with different date stamps, say. That's not ideal, but it can be much easier than regression testing a bunch of applications. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 17:56:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 484E437B69C for ; Tue, 25 Apr 2000 17:56:17 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA01116; Wed, 26 Apr 2000 10:25:58 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 26 Apr 2000 10:25:57 +0930 (CST) From: "Daniel O'Connor" To: Andrzej Bialecki Subject: Re: SMP changes and breaking kld object module compatibility Cc: "freebsd-current@FreeBSD.ORG" Cc: "freebsd-current@FreeBSD.ORG" , Matthew Dillon , Richard Wackerbarth , Alok Dhir , "Daniel C. Sobral" , "Brandon D. Valentine" , Paul Richards Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On a similar note: I think one of serious drawbacks of FreeBSD's model > for > updating and bugfixing the stable branch is 'make world'. It's very > inefficient and cumbersome way to do this on production machines. > STABLE > is stable enough for us to be able to prepare binary patches, which can > be > applied to a system in some (known) version. Especially security fixes, > which are usually limited to specific programs. Try buildworld on one machine and installworld on all of your production boxes.. installworld only takes 10-20 minutes to run on my crappy IDE disks. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 18: 8:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id E5DDF37B55A for ; Tue, 25 Apr 2000 18:08:33 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA38528; Wed, 26 Apr 2000 10:37:08 +0930 (CST) Date: Wed, 26 Apr 2000 10:37:08 +0930 From: Greg Lehey To: Poul-Henning Kamp , "Thomas D. Dean" Cc: Andrzej Bialecki , current@FreeBSD.ORG Subject: Re: FreeBSD build status Message-ID: <20000426103708.G38026@freebie.lemis.com> References: <200004251728.KAA03679@ix.netcom.com> <54330.956678940@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <54330.956678940@critter.freebsd.dk> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 25 April 2000 at 18:09:00 +0200, Poul-Henning Kamp wrote: > In message , Andrzej Bialecki writes: >> On Tue, 25 Apr 2000, Poul-Henning Kamp wrote: >> >>> >>> =================================== >>> SUMMARY >>> =================================== >> >> [27kB long list of errors deleted..] >> >> I thought that the final conclusion was to have some other mailing list >> for this type of messages... ? > > I don't think there were any final conclusion, so I'm selectively > forwarding it whenever something is broken. Could you be more selective? This appears to affect only GENERIC98, but the other stuff could be misleading. On Tuesday, 25 April 2000 at 10:28:23 -0700, Thomas Dean wrote: > The summary may have saved lots of net time. > > I did not cvsup today because of the summary. I think you were one of the misled, unless you use PC98. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 18:15: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id EACE637B728 for ; Tue, 25 Apr 2000 18:15:02 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac8.wam.umd.edu (root@rac8.wam.umd.edu [128.8.10.148]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id VAA18903 for ; Tue, 25 Apr 2000 21:14:41 -0400 (EDT) Received: from rac8.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac8.wam.umd.edu (8.9.3/8.9.3) with SMTP id VAA24445 for ; Tue, 25 Apr 2000 21:14:57 -0400 (EDT) Received: from localhost (culverk@localhost) by rac8.wam.umd.edu (8.9.3/8.9.3) with ESMTP id VAA24441 for ; Tue, 25 Apr 2000 21:14:57 -0400 (EDT) X-Authentication-Warning: rac8.wam.umd.edu: culverk owned process doing -bs Date: Tue, 25 Apr 2000 21:14:57 -0400 (EDT) From: Kenneth Wayne Culver To: freebsd-current@freebsd.org Subject: linux ldconfig core dump Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As of about Thursday, Apr 20 I get this message when I try to run linux ldconfig: Segmentation fault(core dumped) I recompiled the module and the kernel on this day so I think that's what cause the problem, but I was wondering if there was anyone else having this problem. This started last thursday, and it continues to be a problem even now (with a kernel that's 10 minutes old, cvsupped today) Ken Culver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 18:15:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from aragorn.neomedia.it (aragorn.neomedia.it [195.103.207.6]) by hub.freebsd.org (Postfix) with ESMTP id 896EC37B6BD for ; Tue, 25 Apr 2000 18:15:37 -0700 (PDT) (envelope-from bartequi@neomedia.it) Received: from bartequi.ottodomain.org (ppp1-pa5.neomedia.it [195.103.207.113]) by aragorn.neomedia.it (8.9.3/8.9.3) with SMTP id DAA03945 for ; Wed, 26 Apr 2000 03:15:22 +0200 (CEST) From: Salvo Bartolotta Date: Wed, 26 Apr 2000 02:18:11 GMT Message-ID: <20000426.2181100@bartequi.ottodomain.org> Subject: A positive data point ... and one question. To: freebsd-current@FreeBSD.ORG X-Mailer: SuperCalifragilis X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear FreeBSD'ers, Although I had been reading negative news, I went ahead ruthlessly and I upgraded one of my 4.0-S slices to 5-CURRENT. My attempt was=20 successful. For the record, I had cvsup'ed -CURRENT on 25 April at about 9 GMT. However,I found a couple of curious things: 1) Albeit I had remade all the devices (including all the slices in use, sound devices etc.), this warning appeared: "WARNING: run /dev/MAKEDEV before 2000-06-01 to get rid of block devices"; 2) while booting, I saw a bunch of "unknowns": bartequi /kernel: unknown: can't assign resources bartequi /kernel: unknown: can't assign resources bartequi /kernel: unknown: can't assign resources bartequi /kernel: unknown: can't assign resources bartequi /kernel: unknown0: at iomem 0-0x9ffff,0x100000-0x17ffffff,0xe8000-0xeffff,0xf0000-0xf3fff,0xf4000 -0 xf7fff,0xf8000-0xfbfff,0xfc000-0xfffff,0xfffe0000-0xffffffff on isa0 bartequi /kernel: unknown: can't assign resources bartequi /kernel: unknown1: at port 0x40-0x43 irq 0 on isa0 bartequi /kernel: unknown2: at port 0x70-0x71 irq 8 on isa0 bartequi /kernel: unknown: can't assign resources bartequi /kernel: unknown3: at port 0xf0 irq 13 on isa0 bartequi /kernel: unknown4: at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 bartequi /kernel: unknown5: at port 0x61 on isa0 bartequi /kernel: unknown6: at port 0xcf8-0xcff on isa0 bartequi /kernel: unknown7: at port 0x290-0x297,0xe400-0xe43f,0xe800-0xe83f on isa0 bartequi /kernel: sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 bartequi /kernel: sbc0: setting card to irq 5, drq 1, 5 bartequi /kernel: pcm0: on sbc0 bartequi /kernel: joy0: at port 0x200-0x207 on isa0 bartequi /kernel: unknown8: at port 0x620-0x623 on isa0 well, I had seen unknown8 before, but it was the ONLY unknown. Finally, I deinstalled the tcsh port and changed my shell to /bin/csh (ie /bin/tcsh). Apart from the above minor items, the upgrade seems to have been quite successful. Question. I had created the 4.0-S system that I would subsequently upgrade to -CURRENT via "make release". I ran "disklabel -B ad2" just to be safe (the OS, now -CURRENT, lives on ad2s1.) When I issued a "disklabel -r ad2", I got "disk: ad2s1". On the other hand, I issued a "disklabel -B ad1" for another 4.0-S system of mine, a 4.0-S system which lives on ad1s2 (/, /var swap) and ad2s2 (/usr). I had successfully upgraded this (former) 3.4-S to 4.0-CURRENT via cvsup and the procedure described in UPDATING; then I had upgraded it to 4.0-S. For this system, disklabel -r spits out "disk:wd1s2" (instead of "ad1s2"). What am I (yawn) missing ? Thanks in advance and best regards, Salvo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 18:25:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id E05F037B55A for ; Tue, 25 Apr 2000 18:25:10 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.13 #1) id 12kGRd-0004xT-00; Wed, 26 Apr 2000 08:16:49 +0700 Date: Wed, 26 Apr 2000 08:16:49 +0700 (ALMST) From: Boris Popov To: Jake Burkholder Cc: Bruce Evans , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000425160340.AE322BCA7@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Jake Burkholder wrote: > Has anyone thought about using kobj(9) for this? > > For example, it should be possible to make simple_lock and lockmgr locks > safe for use from modules by introducing a lock_if.h, which has > abstract version of all the lock routines. A class would be compiled > with null implementations for UP, or the 'lock'ed implementations for SMP. kobj is a nice interface (I'm converted my NLS kernel module to use it), but may be unsuitable for lock family functions due to an additinal overhead invloved in the method call. I think that the empty-body functions will be more efficient in this case. -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 18:26:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id AC0DF37B50D; Tue, 25 Apr 2000 18:26:17 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA38752; Wed, 26 Apr 2000 10:53:44 +0930 (CST) Date: Wed, 26 Apr 2000 10:53:44 +0930 From: Greg Lehey To: Doug Rabson Cc: FreeBSD Committers , FreeBSD current users Subject: Re: Remote serial gdb is broken in -CURRENT. Message-ID: <20000426105344.B38665@freebie.lemis.com> References: <20000425143641.J26934@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 25 April 2000 at 9:39:10 +0100, Doug Rabson wrote: > On Tue, 25 Apr 2000, Greg Lehey wrote: > >> On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote: >>> On Sun, 23 Apr 2000, Greg Lehey wrote: >>> >>>> In the last few days, my remote serial gdb has almost completely >>>> stopped working. Previously I had (almost) no trouble at 38400 bps; >>>> now I can barely get a response at all at 9600 bps. Does anybody have >>>> an idea where this could be coming from? >>> >>> I noticed this too but I have no idea why. I also had to move back to >>> 9600. >> >> I've found the problem and fixed it. It's been broken all along, but >> for some reason it got worse lately. >> >> Basically, what happened was that the getpacket function, which does >> polled I/O, wasn't locking out interrupts, and something was >> interrupting long enough for characters to get lost. Since sometimes >> several consecutive characters got lost, it seems likely that either >> something locks out interrupts for an inappropriately long time, or >> the sio interrupt routines steal them. Anyway, it works nicely at >> 115200 bps now. > > Great, thanks Greg. Debugging at 9600bps was getting painful :-) Even that didn't work for me. BTW, the fix had the side effect of making the clock stand still. I've changed the code (spltty instead of splhigh), and it seems to work OK now, so it probably was the tty interrupt stealing characters. I'll commit when I'm sure all is still OK. > On a nearly unrelated subject, can you try out the new stuff I just put > into the kernel linker to allow it to export information to GDB. Now you > should be able to use GDB's "sharedlibrary" command to load symbols. Make > sure that the path used to load the file on the debugged machine is a > valid path leading to the same file on the debugger machine. This looks like just what I'm looking for, especially if it can extract kld symbols. How do I use it? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 18:30:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 8E94B37B50D for ; Tue, 25 Apr 2000 18:30:30 -0700 (PDT) (envelope-from brdavis@orion.ac.hmc.edu) Received: (from brdavis@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) id SAA22467; Tue, 25 Apr 2000 18:30:23 -0700 (PDT) Date: Tue, 25 Apr 2000 18:30:22 -0700 From: Brooks Davis To: Kenneth Wayne Culver Cc: freebsd-current@FreeBSD.ORG Subject: Re: linux ldconfig core dump Message-ID: <20000425183022.A21179@orion.ac.hmc.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from culverk@wam.umd.edu on Tue, Apr 25, 2000 at 09:14:57PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 09:14:57PM -0400, Kenneth Wayne Culver wrote: > As of about Thursday, Apr 20 I get this message when I try to run linux > ldconfig: > > Segmentation fault(core dumped) > > I recompiled the module and the kernel on this day so I think that's what > cause the problem, but I was wondering if there was anyone else having > this problem. This started last thursday, and it continues to be a problem > even now (with a kernel that's 10 minutes old, cvsupped today) The method of branding has changed, and David O'Brien said you need to rebrand the linux ldconfig program. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 18:35:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.115.5]) by hub.freebsd.org (Postfix) with ESMTP id F0A5437B77F for ; Tue, 25 Apr 2000 18:35:08 -0700 (PDT) (envelope-from matey@cis.ohio-state.edu) Received: from zeta.cis.ohio-state.edu (matey@zeta.cis.ohio-state.edu [164.107.112.46]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id VAA00255; Tue, 25 Apr 2000 21:35:02 -0400 (EDT) Received: (from matey@localhost) by zeta.cis.ohio-state.edu (8.9.1/8.9.1) id VAA04400; Tue, 25 Apr 2000 21:35:02 -0400 (EDT) Date: Tue, 25 Apr 2000 21:34:42 -0400 From: Alexander Matey To: Kenneth Wayne Culver Cc: freebsd-current@FreeBSD.ORG Subject: Re: linux ldconfig core dump Message-ID: <20000425213442.A63034@cis.ohio-state.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from culverk@wam.umd.edu on Tue, Apr 25, 2000 at 09:14:57PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, On Tue, Apr 25, 2000 at 09:14:57PM -0400, Kenneth Wayne Culver wrote: > As of about Thursday, Apr 20 I get this message when I try to run linux > ldconfig: > > Segmentation fault(core dumped) > > I recompiled the module and the kernel on this day so I think that's what > cause the problem, but I was wondering if there was anyone else having > this problem. This started last thursday, and it continues to be a problem > even now (with a kernel that's 10 minutes old, cvsupped today) brandelf -t Linux /usr/compat/linux/sbin/ldconfig should help. ELF branding method has changed recently. > > Ken Culver -- lx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 19: 3:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id BD70A37B6BD; Tue, 25 Apr 2000 19:03:28 -0700 (PDT) (envelope-from bandix@looksharp.net) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id WAA41112; Tue, 25 Apr 2000 22:03:56 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Tue, 25 Apr 2000 22:03:56 -0400 (EDT) From: "Brandon D. Valentine" To: Kris Kennaway Cc: Andrzej Bialecki , freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Kris Kennaway wrote: >You've never run ident(1), right? :) Very cool! No I hadn't. I was working with the assumption that it was probably possible, but I know very little about how RCS actually works. I just know that it does work and that's always been enough for me to use it. Thanks for pointing that out. If Mr. Bialecki is still interested in doing this, his job just got easier than I anticipated. =) Brandon D. Valentine -- bandix@looksharp.net Illegitimi non carborundum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 19:14:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id B899B37B872; Tue, 25 Apr 2000 19:14:12 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id WAA13884; Tue, 25 Apr 2000 22:13:58 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Tue, 25 Apr 2000 22:13:58 -0400 (EDT) From: Chuck Robey To: Richard Wackerbarth Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <00042515105300.02802@nomad.dataplex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Richard Wackerbarth wrote: > On Tue, 25 Apr 2000, you wrote: > > > I told myself I wouldn't get into this debate with you again, Richard, but > > you're not listening. The vast majority (all? I might have missed one) of > > the other respondants > > Actually, I didn't start this. Someone else brought up the idea. I did. I wanted to test the opinions. I said I had enough responses, about 40 messages ago. Damn, people, if you're *really* tired of hearing from Richard on this, for god's sake control your keyboards, they're running amuck! Let's see if you guys can just let it die, ok? > The quiet majority that might benefit are not very likely to speak up when > they are told some is impossible. Quiet majority .... hehe! Right .... ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 19:37: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by hub.freebsd.org (Postfix) with ESMTP id 8D03337B77C; Tue, 25 Apr 2000 19:37:02 -0700 (PDT) (envelope-from bloom@acm.org) Received: from acm.org (reyim.ne.mediaone.net [24.218.251.241]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id WAA29934; Tue, 25 Apr 2000 22:35:37 -0400 (EDT) Message-ID: <390655EF.312D5248@acm.org> Date: Tue, 25 Apr 2000 22:35:27 -0400 From: Jim Bloom X-Mailer: Mozilla 4.72 [en]C-MOENE (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: "Brandon D. Valentine" , Andrzej Bialecki , freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The RCS info stored in the binaries is insufficient for this purpose. There is no record of the versions of all included files. Changes to constants and/or macros would not be identifiable. Jim Bloom bloom@acm.org Kris Kennaway wrote: > > On Tue, 25 Apr 2000, Brandon D. Valentine wrote: > > > The only way something like this is feasible is if the binaries > > themselves contain information about what version they are. In other > > words some sort of a header in the binary which contains the RCS version > > number the binary was compiled from so that whatever method you were > > You've never run ident(1), right? :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 20:23:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 8C61D37B5AF for ; Tue, 25 Apr 2000 20:23:31 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac3.wam.umd.edu (root@rac3.wam.umd.edu [128.8.10.143]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id XAA16598; Tue, 25 Apr 2000 23:23:24 -0400 (EDT) Received: from rac3.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac3.wam.umd.edu (8.9.3/8.9.3) with SMTP id XAA05379; Tue, 25 Apr 2000 23:23:20 -0400 (EDT) Received: from localhost (culverk@localhost) by rac3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id XAA05375; Tue, 25 Apr 2000 23:23:19 -0400 (EDT) X-Authentication-Warning: rac3.wam.umd.edu: culverk owned process doing -bs Date: Tue, 25 Apr 2000 23:23:19 -0400 (EDT) From: Kenneth Wayne Culver To: Brooks Davis Cc: freebsd-current@FreeBSD.ORG Subject: Re: linux ldconfig core dump In-Reply-To: <20000425183022.A21179@orion.ac.hmc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG oops, I forgot all about that, thanks. :-) ================================================================= | Kenneth Culver | FreeBSD: The best OS around. | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Tue, 25 Apr 2000, Brooks Davis wrote: > On Tue, Apr 25, 2000 at 09:14:57PM -0400, Kenneth Wayne Culver wrote: > > As of about Thursday, Apr 20 I get this message when I try to run linux > > ldconfig: > > > > Segmentation fault(core dumped) > > > > I recompiled the module and the kernel on this day so I think that's what > > cause the problem, but I was wondering if there was anyone else having > > this problem. This started last thursday, and it continues to be a problem > > even now (with a kernel that's 10 minutes old, cvsupped today) > > The method of branding has changed, and David O'Brien said you need to > rebrand the linux ldconfig program. > > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 20:32:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 9B4F437B782 for ; Tue, 25 Apr 2000 20:32:30 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA41265; Wed, 26 Apr 2000 13:02:05 +0930 (CST) Date: Wed, 26 Apr 2000 13:02:05 +0930 From: Greg Lehey To: Matthew Dillon Cc: Brad Knowles , Mathew Kanner , current@FreeBSD.ORG Subject: Re: Vinum breakage Message-ID: <20000426130205.E40207@freebie.lemis.com> References: <200004051344.JAA15337@dean.pc.sas.com> <200004051606.JAA78646@apollo.backplane.com> <20000405123724.A24249@cs.mcgill.ca> <200004051649.JAA78992@apollo.backplane.com> <200004051843.LAA79634@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004051843.LAA79634@apollo.backplane.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 5 April 2000 at 11:43:52 -0700, Matthew Dillon wrote: > >> >>> Also, as a general note to everyone, make sure you are building vinum >>> into the kernel directly and not using it as a kld, just to ensure that >>> it stays in sync with the kernel. >> >> Isn't this in direct conflict with the instructions given for >> normally using vinum? Is this a temporary change, until we get over >> some of the current problems, or is this a more permanent change? >> >> Out of curiosity, is this your recommendation, or does Greg agree with it? > > This is my personal recommendation - if you are messing around with > something that is under development or test, it is best to build it > into the kernel to avoid getting out of sync without knowing it. Hmm. I seem to have mislaid this thread. I recommend using modules rather than to put vinum in the kernel. Since I test this way, I also prefer you to do it that way, so that I can't be sure there's some problem in the build process. On the other hand, Matt is right: it's currently a pain to be sure your kernel and the vinum module are in sync. Given the problems we're having, understand the issues and do whichever you prefer. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 22:13:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id D668D37B728 for ; Tue, 25 Apr 2000 22:13:19 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 3418 invoked from network); 26 Apr 2000 05:13:15 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 26 Apr 2000 05:13:15 -0000 Date: Wed, 26 Apr 2000 15:13:10 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Greg Lehey Cc: Doug Rabson , FreeBSD Committers , FreeBSD current users Subject: Re: Remote serial gdb is broken in -CURRENT. In-Reply-To: <20000426105344.B38665@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, Greg Lehey wrote: > Even that didn't work for me. BTW, the fix had the side effect of > making the clock stand still. I've changed the code (spltty instead The gdb code apparently assumes that the kernel debugger runs entirely with interrupts disabled (as is required for the kernel debugger to actually be useful for debugging interrupt handlers), or that the i/o routines are buffered. My version of ddb/gdb has always run with interrupts disabled, but I never committed the changes because they break the clock :-). I wrote fixes to restore the clock from the RTC a couple of years ago but have never been completely happy with them. Restoring the clock properly from the RTC should be part of a larger fix that restores it properly after resuming from suspend mode, intertwined with ntp-related code for slewing the clock instead of stepping it in some cases. > of splhigh), and it seems to work OK now, so it probably was the tty > interrupt stealing characters. I'll commit when I'm sure all is still > OK. Neither spltty() nor splhigh() prevents sio interrupts, since sio interrupts are fast. spltty() primarily prevents mainly keyboard interrupts and software interrupts. The former could be a problem becuase the console driver still uses polled mode for setting the keyboard LEDs (it busy-waits for typically 2-5 msec). The latter could be a problem if someone has added slow timeout routines or slow netisrs or slow camisrs. The tty software interrupt routines haven't changed lately. spltty() secondarily prevents network hardware interrupts if slip is configured or ppp is attached. Use "s = splvm(); (void)spltty();" to mask everything except clock interrupts. Try using splnet() to see if masking only timeouts and netisrs fixes the problem. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Apr 25 23:58:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id 96D6B37BBC4; Tue, 25 Apr 2000 23:58:42 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id XAA44927; Tue, 25 Apr 2000 23:58:40 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <390693A0.509C3134@gorean.org> Date: Tue, 25 Apr 2000 23:58:40 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0422 i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Wackerbarth Cc: Kris Kennaway , current@FreeBSD.org Subject: Re: Archive pruning References: <00042515302702.02802@nomad.dataplex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Wackerbarth wrote: > > On Tue, 25 Apr 2000, Kris Kennaway wrote: > > On Tue, 25 Apr 2000, Richard Wackerbarth wrote: > > > Actually, I didn't start this. Someone else brought up the idea. > > > > ...and quickly decided it was not worthwhile. > > Yes, the developers do a good job of repressing opinions that differ from > their own. But good ideas take on a life of their own, regardless. The trick is, code talks. I could give you lots of examples, but it wouldn't make any difference since you're just restating the same points over and over again regardless of what people are telling you. > > I haven't heard anyone say that. What I have heard is "too much work for > > too little gain". If you still disagree, it's time to put up or shut up > > And if I put up, will you (the organization) use it? What, "the organization?" FreeBSD is the users, not the people you're busy pissing off. Figure out a way to make your idea work, then figure out a way to make a port of it. I think the cvsup-mirror port is a good example of something in the same family (maybe a distant cousin). Then submit your port, and let's see how many people actually do find it valuable. I can't speak for any of the committers, but I'd almost guarantee that several people who've responded to this thread would be willing to commit your port just for the chance to see it go down in flames, which is as close to a guarantee as you're going to get. Any further discussion from you on this point that doesn't include code is totally and completely without value. You haven't proven the value of your suggestion to _anyone's_ satisfaction, so no one is going to do it for you. So if you're not willing to actually do it, please let it drop. Good luck, Doug -- Excess on occasion is exhilarating. It prevents moderation from acquiring the deadening effect of a habit. -- W. Somerset Maugham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 0:26:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id A3C4637BB76; Wed, 26 Apr 2000 00:26:05 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 12kMCw-000O0V-0X; Wed, 26 Apr 2000 08:26:02 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA02002; Wed, 26 Apr 2000 08:26:02 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 26 Apr 2000 08:31:07 +0100 (BST) From: Doug Rabson To: Greg Lehey Cc: FreeBSD Committers , FreeBSD current users Subject: Re: Remote serial gdb is broken in -CURRENT. In-Reply-To: <20000426105344.B38665@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, Greg Lehey wrote: > On Tuesday, 25 April 2000 at 9:39:10 +0100, Doug Rabson wrote: > > On Tue, 25 Apr 2000, Greg Lehey wrote: > > > >> On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote: > >>> On Sun, 23 Apr 2000, Greg Lehey wrote: > >>> > >>>> In the last few days, my remote serial gdb has almost completely > >>>> stopped working. Previously I had (almost) no trouble at 38400 bps; > >>>> now I can barely get a response at all at 9600 bps. Does anybody have > >>>> an idea where this could be coming from? > >>> > >>> I noticed this too but I have no idea why. I also had to move back to > >>> 9600. > >> > >> I've found the problem and fixed it. It's been broken all along, but > >> for some reason it got worse lately. > >> > >> Basically, what happened was that the getpacket function, which does > >> polled I/O, wasn't locking out interrupts, and something was > >> interrupting long enough for characters to get lost. Since sometimes > >> several consecutive characters got lost, it seems likely that either > >> something locks out interrupts for an inappropriately long time, or > >> the sio interrupt routines steal them. Anyway, it works nicely at > >> 115200 bps now. > > > > Great, thanks Greg. Debugging at 9600bps was getting painful :-) > > Even that didn't work for me. BTW, the fix had the side effect of > making the clock stand still. I've changed the code (spltty instead > of splhigh), and it seems to work OK now, so it probably was the tty > interrupt stealing characters. I'll commit when I'm sure all is still > OK. Cool. > > > On a nearly unrelated subject, can you try out the new stuff I just put > > into the kernel linker to allow it to export information to GDB. Now you > > should be able to use GDB's "sharedlibrary" command to load symbols. Make > > sure that the path used to load the file on the debugged machine is a > > valid path leading to the same file on the debugger machine. > > This looks like just what I'm looking for, especially if it can > extract kld symbols. How do I use it? Basically, all you do is load the module on the scratch box. Use an absolute path which also leads to the same file on the debugging box. Then break into GDB somehow and type "sharedlibrary". The debugger should print a message about each file which it finds and you can then use "info sharedlibrary" to see where they were loaded. All the symbols are loaded and relocated properly so you should be able to set breakpoints etc. as normal. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 0:34:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id 4F57937B805 for ; Wed, 26 Apr 2000 00:34:49 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 3D5D02DC07; Wed, 26 Apr 2000 09:38:19 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id 4ACE57811; Wed, 26 Apr 2000 09:33:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 3F7F410E17; Wed, 26 Apr 2000 09:33:46 +0200 (CEST) Date: Wed, 26 Apr 2000 09:33:46 +0200 (CEST) From: Andrzej Bialecki To: Daniel O'Connor Cc: "freebsd-current@FreeBSD.ORG" Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, Daniel O'Connor wrote: > Try buildworld on one machine and installworld on all of your production > boxes.. installworld only takes 10-20 minutes to run on my crappy IDE > disks. Yes, that's what I'm doing now - so far the best method. But still requires having N+1 boxes (which is not a concern for me, but for someone having e.g. 2 boxes in production this represents 1/3 increment), plus topology allowing for using NFS mounts. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 0:37:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id E202237BD63 for ; Wed, 26 Apr 2000 00:37:20 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id RAA10565; Wed, 26 Apr 2000 17:07:12 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 26 Apr 2000 17:07:12 +0930 (CST) From: "Daniel O'Connor" To: Andrzej Bialecki Subject: Re: SMP changes and breaking kld object module compatibility Cc: "freebsd-current@FreeBSD.ORG" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 26-Apr-00 Andrzej Bialecki wrote: > Yes, that's what I'm doing now - so far the best method. But still > requires having N+1 boxes (which is not a concern for me, but for someone > having e.g. 2 boxes in production this represents 1/3 increment), plus > topology allowing for using NFS mounts. True, depending on your setup you can do it ON your production machine :) Or on your workstation etc.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 0:48:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id D51E537B5CC for ; Wed, 26 Apr 2000 00:48:32 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Apr 2000 08:48:27 +0100 (BST) Date: Wed, 26 Apr 2000 08:48:27 +0100 From: David Malone To: Andrzej Bialecki Cc: Daniel O'Connor , "freebsd-current@FreeBSD.ORG" Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000426084827.A46379@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from abial@webgiro.com on Wed, Apr 26, 2000 at 09:33:46AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 09:33:46AM +0200, Andrzej Bialecki wrote: > > Try buildworld on one machine and installworld on all of your production > > boxes.. installworld only takes 10-20 minutes to run on my crappy IDE > > disks. > > Yes, that's what I'm doing now - so far the best method. But still > requires having N+1 boxes (which is not a concern for me, but for someone > having e.g. 2 boxes in production this represents 1/3 increment), plus > topology allowing for using NFS mounts. Usually you can buildworld on one production machine in advance and then schedule downtime for when you want to installworld. Then we usually use rdist or rsync to do keep the rest of our production machines in sync with this master machine. This procedure has worked quite well for us since 2.something. It also has the advantage that if something goes pear shaped during the upgrade, you have other machines with exact copies of all the binaries so you can restore the machine back to it's old state without resorting to tape. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 1: 4:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id AEB2D37B829; Wed, 26 Apr 2000 01:04:49 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 0977A2DC0A; Wed, 26 Apr 2000 10:08:19 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id 6C3B37811; Wed, 26 Apr 2000 10:04:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 6759D10E17; Wed, 26 Apr 2000 10:04:29 +0200 (CEST) Date: Wed, 26 Apr 2000 10:04:29 +0200 (CEST) From: Andrzej Bialecki To: Jim Bloom Cc: Kris Kennaway , "Brandon D. Valentine" , freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility In-Reply-To: <390655EF.312D5248@acm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Jim Bloom wrote: > The RCS info stored in the binaries is insufficient for this purpose. There is > no record of the versions of all included files. Changes to constants and/or > macros would not be identifiable. Yes, you're right, I'm afraid. This could theoretically be solved by adding an ELF section at the build stage, containing the RCS versions from files reported by 'make depend'. But at this point the things get ugly and complicated very quickly... :-( The simple approach could be as follows: start with the official version of the RELEASE (which takes care of having one common version, with known MD5 cksums). The patchkits would contain only the whole files, not diffs. The patch installer would have to examine the target files before doing anything, and if the MD5 checksums (relative to the last patchkit) don't match - present a choice, in a way similar to mergemaster. This way, we can push the responsibility for tracking dependencies to the user... :-/ Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 1:22:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from solaris.matti.ee (solaris.matti.ee [194.126.98.135]) by hub.freebsd.org (Postfix) with ESMTP id 35D6437B569; Wed, 26 Apr 2000 01:22:21 -0700 (PDT) (envelope-from vallo@matti.ee) Received: from myhakas.matti.ee (myhakas.matti.ee [194.126.114.87]) by solaris.matti.ee (Postfix) with ESMTP id 3CBF82CE64; Wed, 26 Apr 2000 10:22:16 +0200 (EET) Received: by myhakas.matti.ee (Postfix, from userid 1000) id EA9481C574E; Wed, 26 Apr 2000 10:22:08 +0200 (EET) Date: Wed, 26 Apr 2000 10:22:08 +0200 From: Vallo Kallaste To: Robert Small Cc: Alexander Langer , Donn Miller , obrien@FreeBSD.ORG, Sergey Osokin , current@FreeBSD.ORG Subject: Re: make buildworld failed... Message-ID: <20000426102208.C9255@myhakas.matti.ee> Reply-To: vallo@matti.ee References: <20000425161551.A9530@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from rsmall@pwahec.org on Tue, Apr 25, 2000 at 10:55:36AM -0500 Organization: =?UTF-8?Q?AS_Matti_B=C3=BCrootehnika?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 10:55:36AM -0500, Robert Small wrote: > Ok, I got the buildworld to finih up this morning, but when I try > installworld, I get: > m/vm_zone.h -> vm/vm_zone.ph > vm/vnode_pager.h -> vm/vnode_pager.ph > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/perl/utils/h2ph. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/perl/utils. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/perl. > *** Error code 1 I've got this trap for several times and I really want to know what's causing this. The first time was about a year ago and after no answer I've not bothered to send out more questions about it. Anyway, several people report it time-to-time, so it's something general going on. -- Vallo Kallaste vallo@matti.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 1:56:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id D38D137B569 for ; Wed, 26 Apr 2000 01:56:54 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Wed, 26 Apr 2000 03:56:45 -0500 From: Richard Wackerbarth To: Doug Barton Subject: Re: Archive pruning Date: Wed, 26 Apr 2000 03:56:44 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: <00042515302702.02802@nomad.dataplex.net> <390693A0.509C3134@gorean.org> In-Reply-To: <390693A0.509C3134@gorean.org> Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <00042603564400.06932@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, you wrote: > Any further discussion from you on this point that doesn't include code > is totally and completely without value. You haven't proven the value of > your suggestion to _anyone's_ satisfaction, so no one is going to do it > for you. So if you're not willing to actually do it, please let it drop. You are correct that I "haven't proven" yet. Much of this is because the audience doesn't relate to the problem because they don't see themselves directly impacted by it. However, they are paying for it every time they use cvsup or cvs. That's the trouble with this developer community. They see EVERYTHING as WRITING CODE and "adding on". This is not about writing code. The code already exists. I am just advocating using it in a different way. As for the actual "doing", I'm quite willing to do to actual "legwork" that results from the change. But the change is a fundamental change in the way the organization "does business". Unless the organization makes a change, there is nothing to do. I think that it is just a matter of time until the matter gets raised by yet another person as the underlying problem gets more acute. I'll sit back and wait... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 2:50:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 0B16937B951 for ; Wed, 26 Apr 2000 02:50:29 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id LAA58620 for ; Wed, 26 Apr 2000 11:50:11 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: PATCH: Removal of unneeded From: Poul-Henning Kamp Date: Wed, 26 Apr 2000 11:50:11 +0200 Message-ID: <58618.956742611@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch This patch removes 67 unneeded instances of #include Comments, tests and reviews please. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 3:38:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38]) by hub.freebsd.org (Postfix) with ESMTP id C83F137BB8B for ; Wed, 26 Apr 2000 03:38:24 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by trinity.skynet.be (Postfix) with ESMTP id 7C1B9180D5; Wed, 26 Apr 2000 12:38:19 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: <200004252022.OAA13776@nomad.yogotech.com> References: <20000424185151.A36672@hub.freebsd.org> <00042422091401.16303@nomad.dataplex.net> <200004251609.KAA12689@nomad.yogotech.com> <00042511570801.32593@nomad.dataplex.net> <200004252022.OAA13776@nomad.yogotech.com> Date: Wed, 26 Apr 2000 12:22:13 +0200 To: nate@yogotech.com (Nate Williams), Richard Wackerbarth From: Brad Knowles Subject: Re: Archive pruning Cc: Nate Williams , current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:22 PM -0600 2000/4/25, Nate Williams wrote: > I consider you a very small minority. A user who is not a developer, > but who could be a developer. The amount of work it would take to > support your needs is way too much work, and it would only benefit < > 1-2% of the user base. Does this mean we don't care about all our > users? Of course not, but when the same amount of time/effort can > positively effect > 50% of the user base, then it makes more sense to > spend the time more wisely. Not that I really want to be seen as being on the same side of the argument as Richard, but there is an issue I think you've ignored -- current versus potential future customers. When you look at current customers (at least, the ones that are vocal enough to express an opinion), you get the sorts of numbers you have expressed. However, when you compare this against potential future customers, I think you could very quickly find that the people who currently appear to be the vocal majority instead find themselves to be a vocal minority. I see this as being the same sort of problem that is faced by the "Moral Majority" crowd. IMO, they are neither moral nor a majority, but they are exceptionally vocal, and quite good at shouting down people who oppose them, and making sure that most of the real majority never even thinks of stepping into the debate simply because they don't want to have to deal with these bozos. Not that I want to equate the people who have taken the opposite view as being a "Moral Majority" or anything, just that there is a similar problem that I think has to be recognized, and we have to try to find some way to address it. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 3:38:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38]) by hub.freebsd.org (Postfix) with ESMTP id B30BC37BED4; Wed, 26 Apr 2000 03:38:30 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by trinity.skynet.be (Postfix) with ESMTP id DD85D18108; Wed, 26 Apr 2000 12:38:28 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: <20000425133242.A42075@wopr.caltech.edu> References: <00042515105300.02802@nomad.dataplex.net> <20000425133242.A42075@wopr.caltech.edu> Date: Wed, 26 Apr 2000 12:24:59 +0200 To: Matthew Hunt , Richard Wackerbarth From: Brad Knowles Subject: Re: Archive pruning Cc: Kris Kennaway , current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:32 PM -0700 2000/4/25, Matthew Hunt wrote: > Maintaining a CVS repository is necessary only if you are working > on the code, so your proposal would only affect devlopers, not Joe > User. Normal users do not maintain copies of the repository and do > not have a frequent need to examine history. True enough. However, how many "normal users" would you expect to be subscribing to the freebsd-current mailing list? If this is a current versus stable versus release issue, I think we can all agree that most users are clueless enough that they can't even figure out how to send e-mail to the freebsd-questions mailing list, much less anything else. So, you are either forced to change your definition of "normal users" to be people who would be subscribing to this list (and hopefully contributing in some way) and you have to acknowledge that change in definition, or you have to change the term that you use. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 3:38:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38]) by hub.freebsd.org (Postfix) with ESMTP id 1EB4A37B56A; Wed, 26 Apr 2000 03:38:33 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by trinity.skynet.be (Postfix) with ESMTP id B014E180C9; Wed, 26 Apr 2000 12:38:31 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: References: Date: Wed, 26 Apr 2000 12:27:22 +0200 To: Kris Kennaway , Richard Wackerbarth From: Brad Knowles Subject: Re: Archive pruning Cc: current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:36 PM -0700 2000/4/25, Kris Kennaway wrote: > Why would "The Project" have to do anything? We've already established > this is of minority appeal, Have we? Really? We have established that this is of minority appeal to the people who have spoken up on this mailing list, but does this mailing list really reflect accurately the opinions of the entire user base and potential future user base? I don't want to claim that you are wrong, I just would like to accurately establish just what it is we've really determined and why, and where this is going to take us. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 4:48:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id D177B37BB6A for ; Wed, 26 Apr 2000 04:48:21 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 651743E44; Wed, 26 Apr 2000 13:48:20 +0200 (CEST) Date: Wed, 26 Apr 2000 13:48:20 +0200 From: Jesper Skriver To: Andrzej Bialecki Cc: Daniel O'Connor , "freebsd-current@FreeBSD.ORG" Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <20000426134820.L7811@skriver.dk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from abial@webgiro.com on Wed, Apr 26, 2000 at 09:33:46AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 09:33:46AM +0200, Andrzej Bialecki wrote: > On Wed, 26 Apr 2000, Daniel O'Connor wrote: > > > Try buildworld on one machine and installworld on all of your production > > boxes.. installworld only takes 10-20 minutes to run on my crappy IDE > > disks. > > Yes, that's what I'm doing now - so far the best method. But still > requires having N+1 boxes (which is not a concern for me, but for someone > having e.g. 2 boxes in production this represents 1/3 increment), plus > topology allowing for using NFS mounts. Or burning /usr/src/ and /usr/obj/ onto a CD after buildworld, and using that for installworlds ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 7:54:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.9.224.2]) by hub.freebsd.org (Postfix) with ESMTP id D592A37B952 for ; Wed, 26 Apr 2000 07:54:02 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from vega.vega.com (dialup5-58.iptelecom.net.ua [212.9.227.58]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id SAA00616 for ; Wed, 26 Apr 2000 18:01:31 +0300 (EEST) Received: from altavista.net (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.9.3/8.9.3) with ESMTP id RAA11272 for ; Wed, 26 Apr 2000 17:52:53 +0300 (EEST) (envelope-from sobomax@altavista.net) Message-ID: <390702C6.BCC0CA88@altavista.net> Date: Wed, 26 Apr 2000 17:52:54 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: current@freebsd.org Subject: vn.ko load/unload/mount = panic Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've already submitted this crash report earlier but it seems that developers in -current list are too busy discussing whether Matt allowed to commit his SMP work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is slightly simplified course of actions which is known to produce kernel panic on both 4.0 and 5.0: root@notebook# kldstat Id Refs Address Size Name 1 2 0xc0100000 1c2f48 kernel 2 1 0xc02c3000 30c8 splash_bmp.ko root@notebook# mount /dev/vn0c /mnt mount: Device not configured root@notebook# kldload /modules/vn.ko root@notebook# kldstat Id Refs Address Size Name 1 3 0xc0100000 1c2f48 kernel 2 1 0xc02c3000 30c8 splash_bmp.ko 3 1 0xc0823000 3000 vn.ko root@notebook# kldunload -i 3 root@notebook# mount /dev/vn0c /mnt [BINGO] Fatal trap 12: page fault while in kernel mode [...] -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 8:18:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from bilbo.w-link.net (bilbo.w-link.net [206.98.114.20]) by hub.freebsd.org (Postfix) with ESMTP id 7CB3037B875 for ; Wed, 26 Apr 2000 08:18:14 -0700 (PDT) (envelope-from jason@beestung.com) Received: from station7 (station7.w-link.net [208.170.201.16]) by bilbo.w-link.net (8.9.3/8.9.3) with SMTP id IAA03530 for ; Wed, 26 Apr 2000 08:19:12 -0700 (PDT) Message-ID: <005f01bfaf92$3e396ca0$10c9aad0@wlink.net> From: "Jason Mitchell" To: Subject: NAT tutorial? Date: Wed, 26 Apr 2000 08:15:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know of a tutorial or more detailed instructions on how to use NAT and IP masquerading in 3.4? I can configure it so that it is running and working with IP firewall within the box no problem, but as far as dolling out local IPs to the rest of the workstations or even building a natd.conf file, I'm lost. The closest I've found is the tutorial at http://freebsd.peon.net, but that doesn't quite cover enough. Thanks in advance, Jason Mitchell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 8:26: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from Mail.Openet-Telecom.COM (opentisdn.isdn.dublin.esat.net [193.120.50.79]) by hub.freebsd.org (Postfix) with ESMTP id D58B137BF29 for ; Wed, 26 Apr 2000 08:25:53 -0700 (PDT) (envelope-from peter.edwards@openet-telecom.com) Received: from openet-telecom.com (rocklobster.openet-telecom.lan [10.0.0.40]) by Mail.Openet-Telecom.COM (8.9.3/8.9.3) with ESMTP id QAA95049; Wed, 26 Apr 2000 16:33:10 +0100 (IST) (envelope-from peter.edwards@openet-telecom.com) Message-ID: <39070A7A.A2766B32@openet-telecom.com> Date: Wed, 26 Apr 2000 16:25:46 +0100 From: "Peter Edwards (local)" Organization: Openet Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: current@FreeBSD.ORG Subject: Re: vn.ko load/unload/mount = panic References: <390702C6.BCC0CA88@altavista.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, After a (very) quick look at the source it looks like there's a missing cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling I haven't time to test it, but try this: *** vn.c.old Wed Apr 26 16:23:03 2000 --- vn.c Wed Apr 26 16:24:06 2000 *************** *** 762,767 **** --- 762,768 ---- case MOD_UNLOAD: /* fall through */ case MOD_SHUTDOWN: + cdevsw_remove(&vn_cdevsw); for (;;) { vn = SLIST_FIRST(&vn_list); if (!vn) Maxim Sobolev wrote: > > Hi, > > I've already submitted this crash report earlier but it seems that developers > in -current list are too busy discussing whether Matt allowed to commit his SMP > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is > slightly simplified course of actions which is known to produce kernel panic on > both 4.0 and 5.0: > > root@notebook# kldstat > Id Refs Address Size Name > 1 2 0xc0100000 1c2f48 kernel > 2 1 0xc02c3000 30c8 splash_bmp.ko > root@notebook# mount /dev/vn0c /mnt > mount: Device not configured > root@notebook# kldload /modules/vn.ko > root@notebook# kldstat > Id Refs Address Size Name > 1 3 0xc0100000 1c2f48 kernel > 2 1 0xc02c3000 30c8 splash_bmp.ko > 3 1 0xc0823000 3000 vn.ko > root@notebook# kldunload -i 3 > root@notebook# mount /dev/vn0c /mnt > [BINGO] > Fatal trap 12: page fault while in kernel mode > [...] > > -Maxim > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 8:51:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.102.114]) by hub.freebsd.org (Postfix) with ESMTP id C90E837BF3B; Wed, 26 Apr 2000 08:50:54 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.3) id IAA59165; Wed, 26 Apr 2000 08:50:40 -0700 (PDT) (envelope-from mph) Date: Wed, 26 Apr 2000 08:50:40 -0700 From: Matthew Hunt To: Brad Knowles Cc: Kris Kennaway , current@freebsd.org Subject: Re: Archive pruning Message-ID: <20000426085040.A59015@wopr.caltech.edu> References: <00042515105300.02802@nomad.dataplex.net> <20000425133242.A42075@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from blk@skynet.be on Wed, Apr 26, 2000 at 12:24:59PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 12:24:59PM +0200, Brad Knowles wrote: > > Maintaining a CVS repository is necessary only if you are working > > on the code, so your proposal would only affect devlopers, not Joe > > User. Normal users do not maintain copies of the repository and do > > not have a frequent need to examine history. > > True enough. However, how many "normal users" would you expect > to be subscribing to the freebsd-current mailing list? If this is a [...] > So, you are either forced to change your definition of "normal > users" to be people who would be subscribing to this list (and > hopefully contributing in some way) and you have to acknowledge that > change in definition, or you have to change the term that you use. Perhaps I am missing your point, but in terms of deciding whether Richard's proposal has merit, the fact that we're discussing this on -CURRENT does not seem to me to be an issue. In any case where somebody says "Y'all should do such-and-such" without ponying up the code himself, we should be thinking about whether the benefit to the users will "pay for" the time it takes us to do it. If 10% of the people who run -CURRENT would find a pruned-history repository useful, but only 10% of our user-base runs -CURRENT, then it seems to me that the fact that it benefits 1% of the user population is the relevant figure. (This is different from the usual case of only putting new features in -CURRENT, because that code will eventually become -STABLE; the people benefitting from Richard's proposal, according to the arguments I've seen so far, are the ones who keep running -CURRENT, whatever that happens to be at the moment.) Does this address your criticism? Matt -- Matthew Hunt * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 8:54:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id F349737B78F for ; Wed, 26 Apr 2000 08:53:57 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime.exit.com [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id IAA00161; Wed, 26 Apr 2000 08:53:53 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.3) id IAA33917; Wed, 26 Apr 2000 08:53:52 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200004261553.IAA33917@realtime.exit.com> Subject: Re: Archive pruning In-Reply-To: <00042603564400.06932@nomad.dataplex.net> from Richard Wackerbarth at "Apr 26, 2000 03:56:44 am" To: Richard Wackerbarth Date: Wed, 26 Apr 2000 08:53:52 -0700 (PDT) Cc: Doug Barton , current@freebsd.org Reply-To: frank@exit.com Organization: Exit Consulting X-Copyright0: Copyright 2000 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Wackerbarth wrote: > You are correct that I "haven't proven" yet. Much of this is because the > audience doesn't relate to the problem because they don't see themselves > directly impacted by it. However, they are paying for it every time they use > cvsup or cvs. "Frankly, my dear, I don't give a damn." > That's the trouble with this developer community. They see EVERYTHING as > WRITING CODE and "adding on". This is not about writing code. The code > already exists. I am just advocating using it in a different way. _What_ code, Richard? All you've done in this whole ridiculous thread is spout generalities and generally attack -core. > As for the actual "doing", I'm quite willing to do to actual "legwork" that > results from the change. But the change is a fundamental change in the way > the organization "does business". Unless the organization makes a change, > there is nothing to do. This is a cop-out. Define your "different way." If it takes code to do it, write the code, even if that's just shell scripts. Set up a prototype that's publically visible. Prove your point, don't just argue. > I think that it is just a matter of time until the matter gets raised by yet > another person as the underlying problem gets more acute. You haven't even proven that there _is_ an "underlying problem." As far as _I'm_ concerned, there _isn't_, and I keep a full repository just for the convenience of having it local. > I'll sit back and wait... Uh, huh. Cop out. Business as usual for you, Richard, from what I have seen in the past. It's simple: Put up or shut up. -- Frank Mayhar frank@exit.com http://www.exit.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 9:16: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from apoq.skynet.be (apoq.skynet.be [195.238.2.35]) by hub.freebsd.org (Postfix) with ESMTP id 0686137BE4F; Wed, 26 Apr 2000 09:15:51 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by apoq.skynet.be (Postfix) with ESMTP id 472711F4EF; Wed, 26 Apr 2000 18:15:47 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: <20000426085040.A59015@wopr.caltech.edu> References: <00042515105300.02802@nomad.dataplex.net> <20000425133242.A42075@wopr.caltech.edu> <20000426085040.A59015@wopr.caltech.edu> Date: Wed, 26 Apr 2000 18:11:23 +0200 To: Matthew Hunt From: Brad Knowles Subject: Re: Archive pruning Cc: Kris Kennaway , current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:50 AM -0700 2000/4/26, Matthew Hunt wrote: > In any case where somebody says "Y'all should do such-and-such" > without ponying up the code himself, we should be thinking about > whether the benefit to the users will "pay for" the time it takes > us to do it. Sounds like a reasonable cost-benefit analysis, as far as it goes. > If 10% of the people who run -CURRENT would find a > pruned-history repository useful, but only 10% of our user-base > runs -CURRENT, then it seems to me that the fact that it benefits > 1% of the user population is the relevant figure. I am only guessing, but the way I read the original proposal (which Richard has been advocating much more strongly than the person who originally proposed it) sounded to me like it would benefit anyone and everyone that installed the sources, and therefore is a much broader issue that really should be discussed on something like a -POLICY mailing list, as opposed to here on -CURRENT. Assuming it were relevant to just the users of -CURRENT, how can you be sure that only 10% of them would benefit? To be fair and honest, you'd have to take a statistical sample of a large enough group of users of -CURRENT, and not just rely on the self-selecting responses by a vocal subset. Assuming you could take a statistically valid sample and prove that it really would benefit just 10% of the users of -CURRENT, how could you prove that only 10% of the people run -CURRENT as opposed to -STABLE? > Does this address your criticism? I think there are a number of issues to be resolved. Probably the most important is the issue of scope of the change, and who all would potentially benefit (or be harmed) by such a change. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 9:17:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id 31AA937C123 for ; Wed, 26 Apr 2000 09:17:14 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id JAA48653; Wed, 26 Apr 2000 09:17:01 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <3907167D.786C1036@gorean.org> Date: Wed, 26 Apr 2000 09:17:01 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0422 i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Wackerbarth Cc: current@freebsd.org Subject: Re: Archive pruning References: <00042515302702.02802@nomad.dataplex.net> <390693A0.509C3134@gorean.org> <00042603564400.06932@nomad.dataplex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Wackerbarth wrote: > > On Wed, 26 Apr 2000, you wrote: > > > Any further discussion from you on this point that doesn't include code > > is totally and completely without value. > You are correct that I "haven't proven" yet. . . . > I'll sit back and wait... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 9:21: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.102.114]) by hub.freebsd.org (Postfix) with ESMTP id 4599737BEFF; Wed, 26 Apr 2000 09:21:05 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.3) id JAA59659; Wed, 26 Apr 2000 09:20:57 -0700 (PDT) (envelope-from mph) Date: Wed, 26 Apr 2000 09:20:57 -0700 From: Matthew Hunt To: Brad Knowles Cc: Kris Kennaway , current@freebsd.org Subject: Re: Archive pruning Message-ID: <20000426092057.A59624@wopr.caltech.edu> References: <00042515105300.02802@nomad.dataplex.net> <20000425133242.A42075@wopr.caltech.edu> <20000426085040.A59015@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from blk@skynet.be on Wed, Apr 26, 2000 at 06:11:23PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 06:11:23PM +0200, Brad Knowles wrote: > I am only guessing, but the way I read the original proposal > (which Richard has been advocating much more strongly than the person > who originally proposed it) sounded to me like it would benefit > anyone and everyone that installed the sources, and therefore is a My impression was that it would benefit the people who installed the repository, not just the sources. If I'm mistaken, I'm sure someone will correct me. But that's why I perceive the propasal as mostly affecting developers (in the sense of people who do any code-tinkering, not just committers). > Assuming it were relevant to just the users of -CURRENT, how can > you be sure that only 10% of them would benefit? To be fair and The 10% figures were hypotheticals to demonstrate which figure I believed to be relevant. They weren't meant to be accurate, aside from both being smaller than unity. IMHO, though, I generally find it reasonable that those who have an opinion on a propsal should take it upon themselves to speak up, rather than waiting to be polled. But as you say, the proposal must be set forth in an appropriate venue. -- Matthew Hunt * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 9:46:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from Mail.Openet-Telecom.COM (opentisdn.isdn.dublin.esat.net [193.120.50.79]) by hub.freebsd.org (Postfix) with ESMTP id 2EBCC37BE52 for ; Wed, 26 Apr 2000 09:46:50 -0700 (PDT) (envelope-from peter.edwards@openet-telecom.com) Received: from openet-telecom.com (rocklobster.openet-telecom.lan [10.0.0.40]) by Mail.Openet-Telecom.COM (8.9.3/8.9.3) with ESMTP id RAA95498; Wed, 26 Apr 2000 17:54:06 +0100 (IST) (envelope-from peter.edwards@openet-telecom.com) Message-ID: <39071D73.28DFC120@openet-telecom.com> Date: Wed, 26 Apr 2000 17:46:43 +0100 From: "Peter Edwards (local)" Organization: Openet Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: vn.ko load/unload/mount = panic References: <390702C6.BCC0CA88@altavista.net> <39070A7A.A2766B32@openet-telecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry, I think that fix is incomplete (though it'll prolly stop the crashes). I think there should be a destroy_dev() call for each created device in the MOD_UNLOAD case also. I'll make a patch and send-pr it once I get back to my home machine, unless someone more experienced feels the need to do it. -- Peter. "Peter Edwards (local)" wrote: > > Hi, > After a (very) quick look at the source it looks like there's a missing > cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling > I haven't time to test it, but try this: > > *** vn.c.old Wed Apr 26 16:23:03 2000 > --- vn.c Wed Apr 26 16:24:06 2000 > *************** > *** 762,767 **** > --- 762,768 ---- > case MOD_UNLOAD: > /* fall through */ > case MOD_SHUTDOWN: > + cdevsw_remove(&vn_cdevsw); > for (;;) { > vn = SLIST_FIRST(&vn_list); > if (!vn) > > Maxim Sobolev wrote: > > > > Hi, > > > > I've already submitted this crash report earlier but it seems that developers > > in -current list are too busy discussing whether Matt allowed to commit his SMP > > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is > > slightly simplified course of actions which is known to produce kernel panic on > > both 4.0 and 5.0: > > > > root@notebook# kldstat > > Id Refs Address Size Name > > 1 2 0xc0100000 1c2f48 kernel > > 2 1 0xc02c3000 30c8 splash_bmp.ko > > root@notebook# mount /dev/vn0c /mnt > > mount: Device not configured > > root@notebook# kldload /modules/vn.ko > > root@notebook# kldstat > > Id Refs Address Size Name > > 1 3 0xc0100000 1c2f48 kernel > > 2 1 0xc02c3000 30c8 splash_bmp.ko > > 3 1 0xc0823000 3000 vn.ko > > root@notebook# kldunload -i 3 > > root@notebook# mount /dev/vn0c /mnt > > [BINGO] > > Fatal trap 12: page fault while in kernel mode > > [...] > > > > -Maxim > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 9:57: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id AD38C37B7C1 for ; Wed, 26 Apr 2000 09:56:57 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id RAA49983; Wed, 26 Apr 2000 17:56:54 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id RAA03883; Wed, 26 Apr 2000 17:56:50 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200004261656.RAA03883@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: freebsd-current@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: cc1 sig 11'ing recently? In-Reply-To: Message from Matthew Jacob of "Tue, 25 Apr 2000 11:20:42 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Apr 2000 17:56:50 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Any getting these too? > > ild-tools > cd /usr/src/bin/sh; make build-tools > cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat -c > /usr/src/bin/sh/mkinit.c > cc: Internal compiler error: program cc1 got fatal signal 11 Only people with dodgy memory or cache (probably memory). -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 9:59: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E708637B802 for ; Wed, 26 Apr 2000 09:59:01 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA12367; Wed, 26 Apr 2000 09:57:57 -0700 Date: Wed, 26 Apr 2000 09:58:54 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Brian Somers Cc: freebsd-current@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: cc1 sig 11'ing recently? In-Reply-To: <200004261656.RAA03883@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Umm- doubt it, but I'll check. This system has been fine for the last 18 months and runs everything else just peachy. On Wed, 26 Apr 2000, Brian Somers wrote: > > > > Any getting these too? > > > > ild-tools > > cd /usr/src/bin/sh; make build-tools > > cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat -c > > /usr/src/bin/sh/mkinit.c > > cc: Internal compiler error: program cc1 got fatal signal 11 > > Only people with dodgy memory or cache (probably memory). > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 10: 0:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 8AA5D37BF89; Wed, 26 Apr 2000 10:00:30 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id KAA53241; Wed, 26 Apr 2000 10:00:29 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Wed, 26 Apr 2000 10:00:29 -0700 (PDT) From: Kris Kennaway To: Vallo Kallaste Cc: Robert Small , Alexander Langer , Donn Miller , obrien@FreeBSD.ORG, Sergey Osokin , current@FreeBSD.ORG Subject: Re: make buildworld failed... In-Reply-To: <20000426102208.C9255@myhakas.matti.ee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, Vallo Kallaste wrote: > I've got this trap for several times and I really want to know what's > causing this. The first time was about a year ago and after no answer > I've not bothered to send out more questions about it. Anyway, several > people report it time-to-time, so it's something general going on. Check the archives - I've answered the question several times in the past month or two. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 10:16:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144]) by hub.freebsd.org (Postfix) with ESMTP id 3A9C037B895 for ; Wed, 26 Apr 2000 10:16:04 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay01.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 99c8f334c649856e3f2cdadc4054e412) with ESMTP id <20000426171610.DMJA10828.relay01@chello.nl>; Wed, 26 Apr 2000 19:16:10 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id TAA01241; Wed, 26 Apr 2000 19:15:59 +0200 (CEST) (envelope-from wkb) Date: Wed, 26 Apr 2000 19:15:59 +0200 From: Wilko Bulte To: "Peter Edwards (local)" Cc: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: vn.ko load/unload/mount = panic Message-ID: <20000426191559.B1021@yedi.wbnet> Reply-To: wc.bulte@chello.nl References: <390702C6.BCC0CA88@altavista.net> <39070A7A.A2766B32@openet-telecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39070A7A.A2766B32@openet-telecom.com>; from peter.edwards@openet-telecom.com on Wed, Apr 26, 2000 at 04:25:46PM +0100 X-OS: FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 04:25:46PM +0100, Peter Edwards (local) wrote: How about send-pr ing this stuff? Wilko > Hi, > After a (very) quick look at the source it looks like there's a missing > cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling > I haven't time to test it, but try this: > > *** vn.c.old Wed Apr 26 16:23:03 2000 > --- vn.c Wed Apr 26 16:24:06 2000 > *************** > *** 762,767 **** > --- 762,768 ---- > case MOD_UNLOAD: > /* fall through */ > case MOD_SHUTDOWN: > + cdevsw_remove(&vn_cdevsw); > for (;;) { > vn = SLIST_FIRST(&vn_list); > if (!vn) > > > Maxim Sobolev wrote: > > > > Hi, > > > > I've already submitted this crash report earlier but it seems that developers > > in -current list are too busy discussing whether Matt allowed to commit his SMP > > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is > > slightly simplified course of actions which is known to produce kernel panic on > > both 4.0 and 5.0: > > > > root@notebook# kldstat > > Id Refs Address Size Name > > 1 2 0xc0100000 1c2f48 kernel > > 2 1 0xc02c3000 30c8 splash_bmp.ko > > root@notebook# mount /dev/vn0c /mnt > > mount: Device not configured > > root@notebook# kldload /modules/vn.ko > > root@notebook# kldstat > > Id Refs Address Size Name > > 1 3 0xc0100000 1c2f48 kernel > > 2 1 0xc02c3000 30c8 splash_bmp.ko > > 3 1 0xc0823000 3000 vn.ko > > root@notebook# kldunload -i 3 > > root@notebook# mount /dev/vn0c /mnt > > [BINGO] > > Fatal trap 12: page fault while in kernel mode > > [...] > > > > -Maxim -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 12: 7:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 6425537BCC3 for ; Wed, 26 Apr 2000 12:07:48 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: from shell-1.enteract.com (dscheidt@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id OAA11072; Wed, 26 Apr 2000 14:07:42 -0500 (CDT) (envelope-from dscheidt@enteract.com) Date: Wed, 26 Apr 2000 14:07:42 -0500 (CDT) From: David Scheidt To: Matthew Jacob Cc: Brian Somers , freebsd-current@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: cc1 sig 11'ing recently? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, Matthew Jacob wrote: > > Umm- doubt it, but I'll check. This system has been fine for the last 18 > months and runs everything else just peachy. > Sudden SIGSEGVs are almost always the result of failed memory. The fact that the machine worked fine for 18 months doesn't mean anything. Replace the memory and your problems will likely go away. If they don't, it's likely that the problem is cooling, processor cache, or a bad motherboard memory bus. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 12:40:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from zappa.demon.nl (zappa.demon.nl [195.173.232.30]) by hub.freebsd.org (Postfix) with ESMTP id 584F237B9D0 for ; Wed, 26 Apr 2000 12:40:05 -0700 (PDT) (envelope-from ron@zappa.demon.nl) Received: from chaos (sonic.demon.nl [192.168.1.3]) by zappa.demon.nl (Postfix) with SMTP id CDC4F2F; Wed, 26 Apr 2000 21:38:37 +0200 (CEST) Message-ID: <003c01bfafb6$e138d4d0$0301a8c0@chaos> From: "Ron Klinkien" To: , "Brian Somers" Cc: , References: <200004261656.RAA03883@hak.lan.Awfulhak.org> Subject: Re: cc1 sig 11'ing recently? Date: Wed, 26 Apr 2000 21:37:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Any getting these too? > > > > ild-tools > > cd /usr/src/bin/sh; make build-tools > > cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat -c > > /usr/src/bin/sh/mkinit.c > > cc: Internal compiler error: program cc1 got fatal signal 11 > > Only people with dodgy memory or cache (probably memory). Or dodgy CPU's like some of the AMD K6/233 ones, when you install more than 32Mb memory. I myself got bitten by this bug yesterday ;( Didn't know this bug exists until I runned a Linux kernel ones, it warned me for this... Something for the FreeBSD kernel too? Ron Klinkien. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 14: 2: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B83A037BD32 for ; Wed, 26 Apr 2000 14:02:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA97586; Wed, 26 Apr 2000 14:02:04 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Apr 2000 14:02:04 -0700 (PDT) From: Matthew Dillon Message-Id: <200004262102.OAA97586@apollo.backplane.com> To: freebsd-current@freebsd.org Subject: linux emulation patch committed to -current - recompile linux module Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The linux emulation patch has been committed to -current, you must recompile your linux emulation kld. This patch will be MFC'd to 4.x on Friday. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 14:14:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (hermes.dialup.ru [194.87.16.230]) by hub.freebsd.org (Postfix) with ESMTP id DE65A37BD32 for ; Wed, 26 Apr 2000 14:14:06 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.9.3/8.9.3) id BAA07544 for current@freebsd.org; Thu, 27 Apr 2000 01:14:04 +0400 (MSD) (envelope-from ache) Date: Thu, 27 Apr 2000 01:14:02 +0400 From: "Andrey A. Chernov" To: current@freebsd.org Subject: Workaround for hanging on exit: patch for review Message-ID: <20000427011402.A7265@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I often notice processes hanging forever on exit's ttywait when TCP connection dropped. Here is a patch I plan to commit which restrict waiting for output drain by 3 minutes. Any comments, improvements or objections? --- kern_exit.c.bak Sun Apr 16 23:35:55 2000 +++ kern_exit.c Thu Apr 27 00:56:02 2000 @@ -230,6 +230,9 @@ if (sp->s_ttyp && (sp->s_ttyp->t_session == sp)) { if (sp->s_ttyp->t_pgrp) pgsignal(sp->s_ttyp->t_pgrp, SIGHUP, 1); + /* XXX don't hang forever */ + if (sp->s_ttyp->t_timeout == 0) + sp->s_ttyp->t_timeout = 180 * hz; (void) ttywait(sp->s_ttyp); /* * The tty could have been revoked -- Andrey A. Chernov http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 14:23: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C936137B986 for ; Wed, 26 Apr 2000 14:23:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA97717; Wed, 26 Apr 2000 14:22:47 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Apr 2000 14:22:47 -0700 (PDT) From: Matthew Dillon Message-Id: <200004262122.OAA97717@apollo.backplane.com> To: "Andrey A. Chernov" Cc: current@FreeBSD.ORG Subject: Re: Workaround for hanging on exit: patch for review References: <20000427011402.A7265@nagual.pp.ru> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I often notice processes hanging forever on exit's ttywait when TCP :connection dropped. Here is a patch I plan to commit which restrict :waiting for output drain by 3 minutes. Any comments, improvements or :objections? : :--- kern_exit.c.bak Sun Apr 16 23:35:55 2000 :+++ kern_exit.c Thu Apr 27 00:56:02 2000 :@@ -230,6 +230,9 @@ : if (sp->s_ttyp && (sp->s_ttyp->t_session == sp)) { : if (sp->s_ttyp->t_pgrp) : pgsignal(sp->s_ttyp->t_pgrp, SIGHUP, 1); :+ /* XXX don't hang forever */ :+ if (sp->s_ttyp->t_timeout == 0) :+ sp->s_ttyp->t_timeout = 180 * hz; : (void) ttywait(sp->s_ttyp); : /* : * The tty could have been revoked : :-- :Andrey A. Chernov I think this is a good idea. I've seen processes stuck in ttywait forever too, usually when I'm using cu and the remote end is spewing all sorts of junk my way. p.s. (on a different topic) I am also seeing serial stream corruption for serial console output. If I add a kernel printf() that generates a lot of output, I get most of it on the serial console plus a lot of other random garbage. Very weird. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 14:46:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from flame.quicksilver.co.nz (flame.quicksilver.co.nz [202.89.130.2]) by hub.freebsd.org (Postfix) with SMTP id 0753537B781 for ; Wed, 26 Apr 2000 14:46:09 -0700 (PDT) (envelope-from jabley@automagic.org) Received: (qmail 23548 invoked by uid 1000); 26 Apr 2000 21:46:07 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Apr 2000 21:46:07 -0000 Date: Thu, 27 Apr 2000 09:46:07 +1200 (NZST) From: Joe Abley X-Sender: jabley@flame.quicksilver.co.nz To: Jason Mitchell Cc: current@freebsd.org Subject: Re: NAT tutorial? In-Reply-To: <005f01bfaf92$3e396ca0$10c9aad0@wlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Jason, This is really a -questions question, not a -current question. On Wed, 26 Apr 2000, Jason Mitchell wrote: > Does anyone know of a tutorial or more detailed instructions on how to use > NAT and IP masquerading in 3.4? "IP masquerading" is what the linux people call NAT. They are the same thing. > I can configure it so that it is running > and working with IP firewall within the box no problem, but as far as > dolling out local IPs to the rest of the workstations Dynamic allocation of IP addresses to workstations doesn't have much to do with NAT -- try hunting for information on dhcp or bootp. There are two DHCP servers in the ports tree (net/isc-dhcp2 and net/wide-dhcp). If I'm barking up the wrong tree, and you're actually talking about static NAT maps, then see natd(8). > or even building a > natd.conf file, I'm lost. You have read natd(8), right? > The closest I've found is the tutorial at > http://freebsd.peon.net, but that doesn't quite cover enough. Try describing exactly what you're trying to achieve, rather than guessing at components that might provide solutions -- then post the question to the -questions list. There are lots of helpful people there that will give you ideas. Oh -- also, check out Dan's list of NAT articles at http://www.freebsddiary.org/topics.php3#nat Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 14:59:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7B6E037B781 for ; Wed, 26 Apr 2000 14:59:25 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA13348; Wed, 26 Apr 2000 14:58:23 -0700 Date: Wed, 26 Apr 2000 14:59:21 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Brian Somers Cc: freebsd-current@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: cc1 sig 11'ing recently? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks to all who mentioned failing memory- I don't think this was the case. Installing a new source tree on a local directory instead of building on top of NFS mounted /usr/src worked for me. It's not clear what to make of this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 15: 7:17 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 542) id 700D137B9C7; Wed, 26 Apr 2000 15:07:15 -0700 (PDT) Date: Wed, 26 Apr 2000 15:07:15 -0700 From: "Andrey A. Chernov" To: Matthew Dillon Cc: current@FreeBSD.ORG Subject: Re: Workaround for hanging on exit: patch for review Message-ID: <20000426150715.A29997@freebsd.org> References: <20000427011402.A7265@nagual.pp.ru> <200004262122.OAA97717@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <200004262122.OAA97717@apollo.backplane.com>; from dillon@apollo.backplane.com on Wed, Apr 26, 2000 at 02:22:47PM -0700 Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 02:22:47PM -0700, Matthew Dillon wrote: > :I often notice processes hanging forever on exit's ttywait when TCP > > I think this is a good idea. I've seen processes stuck in ttywait > forever too, usually when I'm using cu and the remote end is spewing > all sorts of junk my way. There is a number of places this may occurse and all of them have no timeout by default. F.e. if some terminal shell hangs in exit's ttywait, comsat hangs on ttywrite and lots of comsats appearse after several hours. Alternative solution will be adding tp->t_timeout = 180 * hz; while initializing tp struct, but it is more radical than I suggest initially. Any ideas? -- Andrey A. Chernov http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 17: 1:25 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 542) id 2B31A37B72A; Wed, 26 Apr 2000 17:01:23 -0700 (PDT) Date: Wed, 26 Apr 2000 17:01:23 -0700 From: "Andrey A. Chernov" To: Matthew Dillon Cc: current@FreeBSD.ORG Subject: Re: Workaround for hanging on exit: patch for review Message-ID: <20000426170123.A50417@freebsd.org> References: <20000427011402.A7265@nagual.pp.ru> <200004262122.OAA97717@apollo.backplane.com> <20000426150715.A29997@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000426150715.A29997@freebsd.org>; from ache@freebsd.org on Wed, Apr 26, 2000 at 03:07:15PM -0700 Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There is a number of places this may occurse and all of them have no timeout > by default. F.e. if some terminal shell hangs in exit's ttywait, comsat > hangs on ttywrite and lots of comsats appearse after several hours. Alternative > solution will be adding > > tp->t_timeout = 180 * hz; > > while initializing tp struct, but it is more radical than I suggest initially. > Any ideas? I mean following patch here: --- tty.c.bak Thu Apr 6 19:20:22 2000 +++ tty.c Thu Apr 27 03:27:42 2000 @@ -218,6 +218,7 @@ SET(tp->t_state, TS_CONNECTED); bzero(&tp->t_winsize, sizeof(tp->t_winsize)); } + tp->t_timeout = 180 * hz; /* XXX don't hang forever */ ttsetwater(tp); splx(s); return (0); -- Andrey A. Chernov http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 17:14:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id C180137BDBB; Wed, 26 Apr 2000 17:14:07 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA54996; Thu, 27 Apr 2000 09:44:11 +0930 (CST) Date: Thu, 27 Apr 2000 09:44:11 +0930 From: Greg Lehey To: Poul-Henning Kamp Cc: current@FreeBSD.ORG Subject: Re: PATCH: Removal of unneeded Message-ID: <20000427094411.G43932@freebie.lemis.com> References: <58618.956742611@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <58618.956742611@critter.freebsd.dk> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 26 April 2000 at 11:50:11 +0200, Poul-Henning Kamp wrote: > > New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch > > This patch removes 67 unneeded instances of #include > > Comments, tests and reviews please. Have you checked that there are no references which are #ifdefed out? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 19:32:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id 1381837B653; Wed, 26 Apr 2000 19:32:52 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (04-128.dial.008.popsite.net [209.69.197.128]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id TAA47116; Wed, 26 Apr 2000 19:32:34 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id ABC751919; Wed, 26 Apr 2000 22:11:33 -0400 (EDT) Date: Wed, 26 Apr 2000 22:11:33 -0400 From: Will Andrews To: Brad Knowles Cc: Kris Kennaway , Richard Wackerbarth , current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000426221133.A1070@argon.blackdawn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from blk@skynet.be on Wed, Apr 26, 2000 at 12:27:22PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 12:27:22PM +0200, Brad Knowles wrote: > > Why would "The Project" have to do anything? We've already established > > this is of minority appeal, > > Have we? Really? We have established that this is of minority It seems to me that the typical assumption is that if someone doesn't speak up, they abstain their vote, for whatever value it might have. Thus, given the number of people who have said they don't think it worth it, and given the number who said they would like this feature, I think we've established that this is a minority issue, quite clearly. Since this is a volunteer project, people are NOT going to be polled on their opinion about X, Y, or Z. They'll either speak up if they care enough or they'll be quiet about the whole proceeding. It does seem that this mailing list is entirely inappropriate for this particular topic; perhaps this thread should be moved to freebsd-arch. Or, as Chuck said about 10 messages ago, it should just die. Either way, I don't honestly care. I'm just not going to be convinced to do any of the coding necessary to prune our repository. I have better things to do with my time than something like that. :-) -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 19:45:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146]) by hub.freebsd.org (Postfix) with ESMTP id 1DE6637B8ED for ; Wed, 26 Apr 2000 19:45:50 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from john.baldwin.cx (john [10.0.0.2]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id WAA65262; Wed, 26 Apr 2000 22:45:42 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-Id: <200004270245.WAA65262@server.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <00042603564400.06932@nomad.dataplex.net> Date: Wed, 26 Apr 2000 22:45:42 -0400 (EDT) From: John Baldwin To: Richard Wackerbarth Subject: Re: Archive pruning Cc: current@FreeBSD.org, Doug Barton Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 26-Apr-00 Richard Wackerbarth wrote: > On Wed, 26 Apr 2000, you wrote: > >> Any further discussion from you on this point that doesn't include code >> is totally and completely without value. You haven't proven the value of >> your suggestion to _anyone's_ satisfaction, so no one is going to do it >> for you. So if you're not willing to actually do it, please let it drop. > > You are correct that I "haven't proven" yet. Much of this is because the > audience doesn't relate to the problem because they don't see themselves > directly impacted by it. However, they are paying for it every time they use > cvsup or cvs. *Bzzzt*. Wrong. You only get the old history during the intial cvsup. And since the most recent revisions are stored at the beginning of an RCS file, you don't pay for this on cvs operations except for 'cvs log' and other operations dealing with the history. Good grief, at least get your facts straight before blathering on. > That's the trouble with this developer community. They see EVERYTHING as > WRITING CODE and "adding on". This is not about writing code. The code > already exists. I am just advocating using it in a different way. No, we just don't do things that we feel are beneficial just because one person is jumping up and down yelling for it. If you want it done, do it yourself, basically. That's why the ports I have committed so far are in the tree. I wanted a port of some program, it wasn't in the tree, so I made it myself, and when I was done I committed it so everyone else could have the option of playing with it. Welcome to a volunteer project. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 19:55:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 3924C37BD6A; Wed, 26 Apr 2000 19:55:10 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Wed, 26 Apr 2000 21:55:02 -0500 From: Richard Wackerbarth To: John Baldwin Subject: Re: Archive pruning Date: Wed, 26 Apr 2000 21:55:00 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain References: <200004270245.WAA65262@server.baldwin.cx> In-Reply-To: <200004270245.WAA65262@server.baldwin.cx> Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <00042621550003.15247@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, you wrote: > *Bzzzt*. Wrong. You only get the old history during the intial cvsup. > And since the most recent revisions are stored at the beginning of an RCS > file, you don't pay for this on cvs operations except for 'cvs log' and > other operations dealing with the history. Good grief, at least get your > facts straight before blathering on. I suggest that YOU get your facts straight. 1) Only the head changes are written at the top of the file. For other branches, cvs has to track down to the branch point and then back out the branch. At each step, it must apply the "patch" that represents the difference in the two versions. 2) I have seen routines that append to the end of a file. However, if I insert at the front, I must copy the entire file. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 20: 7:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146]) by hub.freebsd.org (Postfix) with ESMTP id C82C537BAD5 for ; Wed, 26 Apr 2000 20:07:46 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from john.baldwin.cx (john [10.0.0.2]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id XAA65292; Wed, 26 Apr 2000 23:07:41 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-Id: <200004270307.XAA65292@server.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <00042621550003.15247@nomad.dataplex.net> Date: Wed, 26 Apr 2000 23:07:41 -0400 (EDT) From: John Baldwin To: Richard Wackerbarth Subject: Re: Archive pruning Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Apr-00 Richard Wackerbarth wrote: > On Wed, 26 Apr 2000, you wrote: > >> *Bzzzt*. Wrong. You only get the old history during the intial cvsup. >> And since the most recent revisions are stored at the beginning of an RCS >> file, you don't pay for this on cvs operations except for 'cvs log' and >> other operations dealing with the history. Good grief, at least get your >> facts straight before blathering on. > > I suggest that YOU get your facts straight. > > 1) Only the head changes are written at the top of the file. For other > branches, cvs has to track down to the branch point and then back out the > branch. At each step, it must apply the "patch" that represents the > difference in the two versions. And since these will need to be kept for the branches to be useful, this is irrelevant to the discussion at hand. > 2) I have seen routines that append to the end of a file. However, if I > insert at the front, I must copy the entire file. Yes, I suppose your nightly cvsup might take an extra 1 s longer to complete, but I can't really tell since I'm usually sleeping through it. Seriously, do you sit there during the day with a stopwatch and time how long each cvsup takes every five minutes? Besides, this only comes in to play during cvsup, not during any cvs operations since users aren't committing changes. Anyways, one thing that Alfred Perlstein said he might like would be to have another cvsup server that a lite version of the repo could be cvsup'ed from. If, as you say, this can all be truly automated, then setup a cvsup server that cvsups every so often, and automatically expires old history and then serves up the new repo via cvsup. Even if you just generate a proof of concept and don't have the resources to provide the mirror, someone might be interested in running a mirror with your patches. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 20:32:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 58C0737B677; Wed, 26 Apr 2000 20:32:44 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA92748; Wed, 26 Apr 2000 21:32:43 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA49166; Wed, 26 Apr 2000 21:31:43 -0600 (MDT) Message-Id: <200004270331.VAA49166@harmony.village.org> To: Dave Belfer-Shevett Subject: Re: Problems configuring Vadem VG-469 PCMCIA controller. Cc: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG In-reply-to: Your message of "Tue, 25 Apr 2000 16:30:46 EDT." References: Date: Wed, 26 Apr 2000 21:31:43 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Dave Belfer-Shevett writes: : Vendor ID AEI0218 (0x1802a904), Serial Number 0x01234567 You'll have to add this ID to the list of IDs in the pcic driver for 4.0. I'll try to do this when I get back if you can wait. And if you can't then you'll have to do it yourself :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 22: 4:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from ugly.prth.tensor.pgs.com (ugly.prth.tensor.pgs.com [157.147.225.240]) by hub.freebsd.org (Postfix) with ESMTP id 1E97037B81D for ; Wed, 26 Apr 2000 22:04:36 -0700 (PDT) (envelope-from shocking@ugly.prth.tensor.pgs.com) Received: from ugly (IDENT:shocking@localhost.prth.tensor.pgs.com [127.0.0.1]) by ugly.prth.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id NAA29330 for ; Thu, 27 Apr 2000 13:02:40 +0800 Message-Id: <200004270502.NAA29330@ugly.prth.tensor.pgs.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: current@freebsd.org Subject: DEVFS - what's happening with it? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 13:02:39 +0800 From: Stephen Hocking-Senior Programmer PGS SPS Perth Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Haven't seen any discussion for quite some time. The Linux people seem to be getting into a lather about it as well. Rehashing the issues like device persistence, et cetera. Is anyone doodling around with a sysctlfs? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 22:17: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 67D3837B8B9 for ; Wed, 26 Apr 2000 22:17:01 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id HAA62935; Thu, 27 Apr 2000 07:16:02 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Greg Lehey Cc: current@FreeBSD.ORG Subject: Re: PATCH: Removal of unneeded In-reply-to: Your message of "Thu, 27 Apr 2000 09:44:11 +0930." <20000427094411.G43932@freebie.lemis.com> Date: Thu, 27 Apr 2000 07:16:02 +0200 Message-ID: <62933.956812562@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000427094411.G43932@freebie.lemis.com>, Greg Lehey writes: >On Wednesday, 26 April 2000 at 11:50:11 +0200, Poul-Henning Kamp wrote: >> >> New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch >> >> This patch removes 67 unneeded instances of #include >> >> Comments, tests and reviews please. > >Have you checked that there are no references which are #ifdefed out? Yes, the src/tools/tools/kerninclude script first renames the include and if the source file still compiles it declares a "no-read" and leaves the #include intact. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 22:40:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [149.173.1.1]) by hub.freebsd.org (Postfix) with ESMTP id C1B3F37BD43 for ; Wed, 26 Apr 2000 22:40:18 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [149.173.6.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id BAA13264 for ; Thu, 27 Apr 2000 01:39:52 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA01197; Thu, 27 Apr 2000 01:39:11 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.3/8.9.1) id BAA34619 for freebsd-current@freebsd.org; Thu, 27 Apr 2000 01:39:10 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <200004270539.BAA34619@bb01f39.unx.sas.com> Subject: Archive pruning - some #s To: freebsd-current@freebsd.org Date: Thu, 27 Apr 2000 01:39:10 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL61 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've been idly watching this thread and decided to check a few numbers.... Is it truly worth pruning? I mirror the freebsd repository, mail archives, and www site locally: size 1.9Gig. time 4:48min about 2/5 gig per minute ie: it takes about 5 minutes for the update to run. Most of that time is due to the mediocre link I live behind. Internally, we maintain a CVS repository which we use cvsup to backup (100T x-over direct between machines). size 57Gig (no, that isn't a typo). time 41:36 about 1.3 gig per minute In the above case, the network is not the bottle-neck. We simply can't read the data off the disk(s) fast enough (currently a dpt raid, moving to amr with more than twice the performance). I guess I don't see why it's worth pruning. The network connection in my case seems to be the bigger problem. Pruning the tree isn't going to buy me anything. And, we lose information... Comments? Later, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 22:50:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id DD06537BE64 for ; Wed, 26 Apr 2000 22:50:46 -0700 (PDT) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id BAA53964 for ; Thu, 27 Apr 2000 01:51:34 -0400 (EDT) (envelope-from bsdx@looksharp.net) Date: Thu, 27 Apr 2000 01:51:33 -0400 (EDT) From: Adam To: current@freebsd.org Subject: Re: cc1 sig 11'ing recently? In-Reply-To: <003c01bfafb6$e138d4d0$0301a8c0@chaos> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, Ron Klinkien wrote: >> > Any getting these too? >> > >> > ild-tools >> > cd /usr/src/bin/sh; make build-tools >> > cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat -c >> > /usr/src/bin/sh/mkinit.c >> > cc: Internal compiler error: program cc1 got fatal signal 11 >> >> Only people with dodgy memory or cache (probably memory). > >Or dodgy CPU's like some of the AMD K6/233 ones, when you install more than >32Mb memory. > >I myself got bitten by this bug yesterday ;( > I have also seem bad cyrix chips cause this - it drove me nuts because I happened to grab a spare cpu which happened to be faulty in the same way from the spare tray and it lead me to building an almost complete clone of the misbehaving computer before I decided to try another cpu :/ Ended up with the original bad and TWO bad cpu's from the spare tray before I found one that worked :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 22:55:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [149.173.1.1]) by hub.freebsd.org (Postfix) with ESMTP id 4A4BB37BE0F for ; Wed, 26 Apr 2000 22:55:49 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [149.173.6.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id BAA13604 for ; Thu, 27 Apr 2000 01:55:16 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA01750; Thu, 27 Apr 2000 01:54:36 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.3/8.9.1) id BAA34693 for freebsd-current@freebsd.org; Thu, 27 Apr 2000 01:54:36 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <200004270554.BAA34693@bb01f39.unx.sas.com> Subject: Support for large mfs To: freebsd-current@freebsd.org Date: Thu, 27 Apr 2000 01:54:36 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL61 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Today, we tried to create a 5Gig mfs. It turns out this is not such a good idea. It turns out that support is basically limited to an int. Extracts from some of the appropriate files show some of the problems... newfs.c: int fssize; /* file system size */ case 's': if ((fssize = atoi(optarg)) <= 0) ufs/ufs/ufsmount.h /* * Arguments to mount MFS */ struct mfs_args { char *fspec; /* name to export for statfs */ struct export_args export; /* if exported MFSes are supported */ caddr_t base; /* base of file system in memory */ u_long size; /* size of file system */ }; ufs/mfs/mfsnode.h struct mfsnode { struct vnode *mfs_vnode; /* vnode associated with this mfsnode */ caddr_t mfs_baseoff; /* base of file system in memory */ long mfs_size; /* size of memory file system */ pid_t mfs_pid; /* supporting process pid */ struct buf_queue_head buf_queue; /* list of I/O requests */ int mfs_active; long mfs_spare[1]; }; As can be seen above, the only constant we have is that the size is atleast a 4 byte entity. Before we start changing the size from an int/long/u_long to a quad_t, is there a better way to do this? How does md fit into the picture? Thanks! John ps: On a side note, what is the correct way to create a quad_t constant in the config file? The following works, but seems dirty: options MAXDSIZ="((__int64_t)5*1024*1024*1024)" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 23: 6: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C1BC237B5A0 for ; Wed, 26 Apr 2000 23:06:00 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA00807; Wed, 26 Apr 2000 23:05:59 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Apr 2000 23:05:59 -0700 (PDT) From: Matthew Dillon Message-Id: <200004270605.XAA00807@apollo.backplane.com> To: "John W. DeBoskey" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs References: <200004270554.BAA34693@bb01f39.unx.sas.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi, : : Today, we tried to create a 5Gig mfs. It turns out this is :not such a good idea. It turns out that support is basically :limited to an int. Extracts from some of the appropriate files :show some of the problems... More then just a few.... MFS uses an mmap()'d segment, so you can't create an MFS partition larger then what a process can mmap() anyway. The max is going to be around 2-3 GB. You should be able to create a large virtual VN device. man vnconfig for more information - you have the choice of making it file-backed, swap-backed, or swap-backed with the swap pre-reserved. file-backed VN devices have a sector size of 512 bytes (which is standard). Swap-backed VN devices have a sector size of a page (4K on PC's). vnconfig up a VN device, disklabel it, and newfs away. You can also turn softupdates on in the VN filesystem partitions. I've tested VN all the way to a terrabyte - and just managed to newfs it before I ran out of swap :-) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 23: 6:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 3926D37B5A0 for ; Wed, 26 Apr 2000 23:06:16 -0700 (PDT) (envelope-from keichii@iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 530DC5BA0; Thu, 27 Apr 2000 01:06:16 -0500 (CDT) Date: Thu, 27 Apr 2000 01:06:16 -0500 From: "Michael C . Wu" To: "Andrey A. Chernov" Cc: current@freebsd.org Subject: Re: Workaround for hanging on exit: patch for review Message-ID: <20000427010616.A26613@peorth.iteration.net> References: <20000427011402.A7265@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000427011402.A7265@nagual.pp.ru>; from ache@nagual.pp.ru on Thu, Apr 27, 2000 at 01:14:02AM +0400 X-FreeBSD-Header: This is a subliminal message from the vast FreeBSD conspiracy project. X-Operating-System: FreeBSD peorth.iteration.net 4.0-STABLE FreeBSD 4.0-STABLE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 27, 2000 at 01:14:02AM +0400, Andrey A. Chernov scribbled: | I often notice processes hanging forever on exit's ttywait when TCP | connection dropped. Here is a patch I plan to commit which restrict | waiting for output drain by 3 minutes. Any comments, improvements or | objections? ---end quoted text--- This sounds really absurd and "bike shed"ish. Please make that 5 minutes. I frequently connect to places that have 2~3 minute lag. :) -- keichii@recursive.iteration.net - Is this a stupid host? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Apr 26 23:17:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id BBB7037B5A0 for ; Wed, 26 Apr 2000 23:17:23 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id IAA63331 for ; Thu, 27 Apr 2000 08:17:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: PATCH: http://phk.freebsd/dk/misc/vm_vm_zone_h.patch From: Poul-Henning Kamp Date: Thu, 27 Apr 2000 08:17:06 +0200 Message-ID: <63329.956816226@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Removes 43 unneeded #include includes. Comments, tests and reviews please -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 1:26: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from morpheus.skynet.be (morpheus.skynet.be [195.238.2.39]) by hub.freebsd.org (Postfix) with ESMTP id B4B5C37B57C for ; Thu, 27 Apr 2000 01:25:59 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by morpheus.skynet.be (Postfix) with ESMTP id C498CDCC1; Thu, 27 Apr 2000 10:24:28 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be (Unverified) Message-Id: In-Reply-To: <200004270605.XAA00807@apollo.backplane.com> References: <200004270554.BAA34693@bb01f39.unx.sas.com> <200004270605.XAA00807@apollo.backplane.com> Date: Thu, 27 Apr 2000 10:18:34 +0200 To: Matthew Dillon , "John W. DeBoskey" From: Brad Knowles Subject: Re: Support for large mfs Cc: freebsd-current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:05 PM -0700 2000/4/26, Matthew Dillon wrote: > You should be able to create a large virtual VN device. man > vnconfig for more information - you have the choice of making it > file-backed, swap-backed, or swap-backed with the swap pre-reserved. > file-backed VN devices have a sector size of 512 bytes (which is > standard). Swap-backed VN devices have a sector size of a page (4K on > PC's). Hmm. This has got me thinking.... I use a mfs for storing the Diablo history file on our news peering server. Yes, I know the front part of the file is mmap()'ed and effectively kept completely in memory anyway, but I've seen periods of time when we received over 160,000 articles in a single hour (an average of about 45 per second), and if you compare this to our normal ratio of offered versus accepted articles (something in the range of 32,238,303 vs. 612,429; for a 52.64:1 ratio), this would imply we probably did something like 2,368.8 history lookups per second during that period of time -- and this is just for inbound articles. In my experience, it is a non-trivial exercise to build a drive array system that can keep up with the number of disk accesses necessary to handle this many history lookups per second. I think I've recently done it (and reported my testing results on news.software.nntp, along with summarizing the previous test results from Joe Greco and Terry Kennedy), but it's still non-trivial and the solutions I've seen so far are all still rather expensive. Thus the reason why I currently continue to use an mfs for the history database. However, now I'm wondering if it might not be better to use a file-backed or maybe a swap-backed VN device instead of an mfs. Do you have any thoughts? -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 3:44:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 4703D37B6A5 for ; Thu, 27 Apr 2000 03:44:07 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id LAA78440; Thu, 27 Apr 2000 11:44:03 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id LAA01935; Thu, 27 Apr 2000 11:14:26 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200004271014.LAA01935@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: Greg Lehey , current@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: PATCH: Removal of unneeded In-Reply-To: Message from Poul-Henning Kamp of "Thu, 27 Apr 2000 07:16:02 +0200." <62933.956812562@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 11:14:26 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <20000427094411.G43932@freebie.lemis.com>, Greg Lehey writes: > >On Wednesday, 26 April 2000 at 11:50:11 +0200, Poul-Henning Kamp wrote: > >> > >> New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch > >> > >> This patch removes 67 unneeded instances of #include > >> > >> Comments, tests and reviews please. > > > >Have you checked that there are no references which are #ifdefed out? > > Yes, the src/tools/tools/kerninclude script first renames the include > and if the source file still compiles it declares a "no-read" and > leaves the #include intact. The thing that's screwed me up the most doing this sort of thing is something like: #include /* For TUNS* ioctls */ .... #ifdef TUNSIFMODE /* Make sure we're POINTOPOINT */ iff = IFF_POINTOPOINT; if (ID0ioctl(bundle.dev.fd, TUNSIFMODE, &iff) < 0) log_Printf(LogERROR, "bundle_Create: ioctl(TUNSIFMODE): %s\n", strerror(errno)); #endif hence the comments beside many of the includes in ppp. I think the only way to ensure something really can be removed is to compile with & without and ensure that the resulting object is the same modulo embedded compile dates. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 3:55: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 719D337B6D4 for ; Thu, 27 Apr 2000 03:55:01 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id MAA64621; Thu, 27 Apr 2000 12:53:31 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Greg Lehey , current@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: PATCH: Removal of unneeded In-reply-to: Your message of "Thu, 27 Apr 2000 11:14:26 BST." <200004271014.LAA01935@hak.lan.Awfulhak.org> Date: Thu, 27 Apr 2000 12:53:31 +0200 Message-ID: <64619.956832811@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200004271014.LAA01935@hak.lan.Awfulhak.org>, Brian Somers writes: >> Yes, the src/tools/tools/kerninclude script first renames the include >> and if the source file still compiles it declares a "no-read" and >> leaves the #include intact. > >The thing that's screwed me up the most doing this sort of thing is >something like: > > #include /* For TUNS* ioctls */ > .... > #ifdef TUNSIFMODE > /* Make sure we're POINTOPOINT */ > iff = IFF_POINTOPOINT; > if (ID0ioctl(bundle.dev.fd, TUNSIFMODE, &iff) < 0) > log_Printf(LogERROR, "bundle_Create: ioctl(TUNSIFMODE): %s\n", > strerror(errno)); > #endif > >hence the comments beside many of the includes in ppp. I think the >only way to ensure something really can be removed is to compile with >& without and ensure that the resulting object is the same modulo >embedded compile dates. If the MD5 over the generated object file changes after substituting an empty file for the include, I consider it "used" by default, so that case should be covered as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 4:38:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from apoq.skynet.be (apoq.skynet.be [195.238.2.35]) by hub.freebsd.org (Postfix) with ESMTP id 04BA137B84E for ; Thu, 27 Apr 2000 04:38:25 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by apoq.skynet.be (Postfix) with ESMTP id D2DD71F3D6; Thu, 27 Apr 2000 13:38:19 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: <200004270502.NAA29330@ugly.prth.tensor.pgs.com> References: <200004270502.NAA29330@ugly.prth.tensor.pgs.com> Date: Thu, 27 Apr 2000 13:38:07 +0200 To: Stephen Hocking-Senior Programmer PGS SPS Perth , current@FreeBSD.ORG From: Brad Knowles Subject: Re: DEVFS - what's happening with it? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:02 PM +0800 2000/4/27, Stephen Hocking-Senior Programmer PGS SPS Perth wrote: > Haven't seen any discussion for quite some time. The Linux people seem to be > getting into a lather about it as well. Rehashing the issues like device > persistence, et cetera. Yeah, there's a really fascinating summary of a whole lot of things happening for kernel 2.4 at , including the devfs and procfs stuff. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 4:52:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from Mail.Openet-Telecom.COM (opentisdn.isdn.dublin.esat.net [193.120.50.79]) by hub.freebsd.org (Postfix) with ESMTP id 6D9D237B7A4 for ; Thu, 27 Apr 2000 04:52:22 -0700 (PDT) (envelope-from peter.edwards@openet-telecom.com) Received: from openet-telecom.com (rocklobster.openet-telecom.lan [10.0.0.40]) by Mail.Openet-Telecom.COM (8.9.3/8.9.3) with ESMTP id MAA99571 for ; Thu, 27 Apr 2000 12:59:44 +0100 (IST) (envelope-from peter.edwards@openet-telecom.com) Message-ID: <390829F5.2E1ADEFF@openet-telecom.com> Date: Thu, 27 Apr 2000 12:52:21 +0100 From: "Peter Edwards (local)" Organization: Openet Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: buildworld breakage in getconf Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Compiling 5.0-CURRENT on 4.0-STABLE generates problems in getconf: ===> usr.bin/getconf gperf -t -L ANSI-C -C -k 1,2,7-10,21,'$' /usr/current/src/usr.bin/getconf/confstr.gperf >confstr.c /* starting time is 11:48:16 */ gperf: unrecognized option `-L' usage: gperf [-acCdDef[num]gGhHijkKlnNoprsStTv]. (type gperf -h for help) *** Error code 1 Stop in /usr/current/src/usr.bin/getconf. *** Error code 1 Stop in /usr/current/src/usr.bin. *** Error code 1 Stop in /usr/current/src. *** Error code 1 Stop in /usr/current/src. *** Error code 1 Stop in /usr/current/src. It seems the makefile is using the /usr/bin/gperf, which doesn't have the -L option on 4.0-STABLE -- Peter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 9:34:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E159437B8F5 for ; Thu, 27 Apr 2000 09:34:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA05279; Thu, 27 Apr 2000 09:34:41 -0700 (PDT) (envelope-from dillon) Date: Thu, 27 Apr 2000 09:34:41 -0700 (PDT) From: Matthew Dillon Message-Id: <200004271634.JAA05279@apollo.backplane.com> To: Brad Knowles Cc: "John W. DeBoskey" , freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs References: <200004270554.BAA34693@bb01f39.unx.sas.com> <200004270605.XAA00807@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : I use a mfs for storing the Diablo history file on our news :peering server. Yes, I know the front part of the file is mmap()'ed :and effectively kept completely in memory anyway, but I've seen :periods of time when we received over 160,000 articles in a single :hour (an average of about 45 per second), and if you compare this to :our normal ratio of offered versus accepted articles (something in :the range of 32,238,303 vs. 612,429; for a 52.64:1 ratio), this would :imply we probably did something like 2,368.8 history lookups per :second during that period of time -- and this is just for inbound :articles. : : In my experience, it is a non-trivial exercise to build a drive :array system that can keep up with the number of disk accesses :necessary to handle this many history lookups per second. I think :I've recently done it (and reported my testing results on :news.software.nntp, along with summarizing the previous test results :from Joe Greco and Terry Kennedy), but it's still non-trivial and the :solutions I've seen so far are all still rather expensive. Thus the :reason why I currently continue to use an mfs for the history :database. : : However, now I'm wondering if it might not be better to use a :file-backed or maybe a swap-backed VN device instead of an mfs. Do :you have any thoughts? : :-- : These are my opinions -- not to be taken as official Skynet policy :====================================================================== :Brad Knowles, || Belgacom Skynet SA/NV I can't imagine why MFS would perform better... it shouldn't, every block is stored in system memory *TWICE* (once in the VM cache, and once in the mfs process's address space). If you have enough system memory to create a large MFS filesystem and it performs well, then the system should perform even better if you remove the MFS filesystem and just use a normal filesystem. A swap-backed VN device operates just like a normal disk device except that you get automatic striping if your swap happens to be striped. It takes advantage of the fact that the system's VM page cache does a good job of caching the disk blocks so it doesn't have to. This is how a normal filesystem works as well. If you have enough memory, the system should be able to cache a normal filesytem's data blocks as easily as it caches the VN devices and easier (because they aren't double-cached) then the MFS device. I would consider trying a normal filesystem with an async or a softupdates mount. Or a normal filesystem with softupdates enabled. It may also help to turn off write-behind (sysctl -w vfs.write_behind=0), though if you are running the latest 4.x stable the write heuristic is now in and should do a good job on its own. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 9:47: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7846E37BB40 for ; Thu, 27 Apr 2000 09:47:04 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA48644; Thu, 27 Apr 2000 12:46:43 -0400 (EDT) (envelope-from wollman) Date: Thu, 27 Apr 2000 12:46:43 -0400 (EDT) From: Garrett Wollman Message-Id: <200004271646.MAA48644@khavrinen.lcs.mit.edu> To: "Peter Edwards (local)" Cc: current@FreeBSD.ORG Subject: buildworld breakage in getconf In-Reply-To: <390829F5.2E1ADEFF@openet-telecom.com> References: <390829F5.2E1ADEFF@openet-telecom.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > Compiling 5.0-CURRENT on 4.0-STABLE generates problems in getconf: I got caught out by gperf version skew. gperf is now a build-tool (as it should always have been) so this problem should be fixed in your next update. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 9:55:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from apoq.skynet.be (apoq.skynet.be [195.238.2.35]) by hub.freebsd.org (Postfix) with ESMTP id D199137BAAF for ; Thu, 27 Apr 2000 09:55:43 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by apoq.skynet.be (Postfix) with ESMTP id 7C4EE1F206; Thu, 27 Apr 2000 18:55:41 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: <200004271634.JAA05279@apollo.backplane.com> References: <200004270554.BAA34693@bb01f39.unx.sas.com> <200004270605.XAA00807@apollo.backplane.com> <200004271634.JAA05279@apollo.backplane.com> Date: Thu, 27 Apr 2000 18:52:47 +0200 To: Matthew Dillon From: Brad Knowles Subject: Re: Support for large mfs Cc: "John W. DeBoskey" , freebsd-current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:34 AM -0700 2000/4/27, Matthew Dillon wrote: > I can't imagine why MFS would perform better... it shouldn't, every > block is stored in system memory *TWICE* (once in the VM cache, and > once in the mfs process's address space). If you have enough system > memory to create a large MFS filesystem and it performs well, then > the system should perform even better if you remove the MFS filesystem > and just use a normal filesystem. When I tried using a regular file on the filesystem, my system time went way up, my iowait went way up, and my performance dropped through the floor. However, this was on 3.2-RELEASE and was several months ago -- I hope that 4.0-STABLE would be a bit better about that. ;-) > I would consider trying a normal filesystem with an async or a >softupdates > mount. Or a normal filesystem with softupdates enabled. It may also > help to turn off write-behind (sysctl -w vfs.write_behind=0), though if > you are running the latest 4.x stable the write heuristic is now in and > should do a good job on its own. I believe I had tried this with softupdates at the time, but it's been long enough since I tried this that I can't be sure. I do recall seeing my performance go down quickly enough and seeing the disk I/O go through the roof fast enough that I decided I would never, ever, ever try that again. Of course, now I am revisiting that decision. ;-) I'm seriously contemplating getting a Dell PowerEdge 2450 with five internal 10kRPM/18GB disks, 2GB of RAM, two of the fastest processors they've got, perhaps a pair of Intel EtherExpress Pro 100+ NICs, and giving this another go with FreeBSD 4.0-STABLE. Do you have any thoughts on this subject? Is 3.2-RELEASE old and non-optimized enough that it really could stand replacing? Given some of the problems we've been seeing lately (which I'm pretty sure are a result of running out of virtual memory and the machine spontaneously rebooting), I think I might be able to convince my management to spring for a third 2450, but with a slightly different configuration than what I'll be using for the news reader servers. It would help me formulate useful arguments for this proposal if I had input from more knowledgeable people than I. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 10: 7: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 43A9537BF5B for ; Thu, 27 Apr 2000 10:07:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA05542; Thu, 27 Apr 2000 10:06:57 -0700 (PDT) (envelope-from dillon) Date: Thu, 27 Apr 2000 10:06:57 -0700 (PDT) From: Matthew Dillon Message-Id: <200004271706.KAA05542@apollo.backplane.com> To: Brad Knowles Cc: "John W. DeBoskey" , freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs References: <200004270554.BAA34693@bb01f39.unx.sas.com> <200004270605.XAA00807@apollo.backplane.com> <200004271634.JAA05279@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : Do you have any thoughts on this subject? Is 3.2-RELEASE old and :non-optimized enough that it really could stand replacing? 3.2 is certainly old. The question is whether or not the performance issue that caught you under 3.2 is fixed under 4.0. Not knowing what was causing the hangups under 3.2 I can only guess that there's a 50-50 change it's been fixed in 4.0. I'm trying to think of what Diablo could be doing that would cause the system to stall on the history file, and I can't think of anything. It ought to work pretty well.... certainly as good or better then MFS, anyway. I suspect that if the issue still exists it's going to be something stupid simple that doing something trivial like turning off write-behind will fix. -Matt : Given some of the problems we've been seeing lately (which I'm :pretty sure are a result of running out of virtual memory and the :machine spontaneously rebooting), I think I might be able to convince :my management to spring for a third 2450, but with a slightly :different configuration than what I'll be using for the news reader :servers. : : It would help me formulate useful arguments for this proposal if :I had input from more knowledgeable people than I. : :-- : These are my opinions -- not to be taken as official Skynet policy :====================================================================== :Brad Knowles, || Belgacom Skynet SA/NV To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 10: 9:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-132.dsl.snfc21.pacbell.net [63.202.176.132]) by hub.freebsd.org (Postfix) with ESMTP id 7161E37BC14 for ; Thu, 27 Apr 2000 10:09:13 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA08417; Thu, 27 Apr 2000 10:16:52 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004271716.KAA08417@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brad Knowles Cc: Matthew Dillon , "John W. DeBoskey" , freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs In-reply-to: Your message of "Thu, 27 Apr 2000 18:52:47 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 10:16:52 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm seriously contemplating getting a Dell PowerEdge 2450 with > five internal 10kRPM/18GB disks, 2GB of RAM, two of the fastest > processors they've got, perhaps a pair of Intel EtherExpress Pro 100+ > NICs, and giving this another go with FreeBSD 4.0-STABLE. I would consider 4.0, several (three or four) strings of LVD disks and either a Mylex eXtremeRAID 1100 (64MB or more) or an AMI MegaRAID Enterprise 1500. (The 1600 should probably work too, but I haven't seen one yet so I can't be sure.) And definitely softupdates. Note that you can't put more than 8 disks into an array with the Mylex controller (easily), so you'd still want to use ccd or vinum over the top. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 12:23:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id A033637B551 for ; Thu, 27 Apr 2000 12:23:28 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@c02-166.006.popsite.net [216.126.135.166]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id MAA54460; Thu, 27 Apr 2000 12:23:22 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id MAA84103; Thu, 27 Apr 2000 12:23:20 -0700 (PDT) (envelope-from obrien) Date: Thu, 27 Apr 2000 12:23:20 -0700 From: "David O'Brien" To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: buildworld breakage in getconf Message-ID: <20000427122319.A37827@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <390829F5.2E1ADEFF@openet-telecom.com> <200004271646.MAA48644@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004271646.MAA48644@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Apr 27, 2000 at 12:46:43PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 27, 2000 at 12:46:43PM -0400, Garrett Wollman wrote: > I got caught out by gperf version skew. gperf is now a build-tool (as > it should always have been) so this problem should be fixed in your > next update. Was this not ``make buildworld'' tested, or is there a change to gnu/usr.bin/gperf/Makefile you forgot to commit? - -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 12:23:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id B1FEE37BAA7 for ; Thu, 27 Apr 2000 12:23:52 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@c02-166.006.popsite.net [216.126.135.166]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id MAA54468; Thu, 27 Apr 2000 12:23:46 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id MAA84127; Thu, 27 Apr 2000 12:23:43 -0700 (PDT) (envelope-from obrien) Date: Thu, 27 Apr 2000 12:23:43 -0700 From: "David O'Brien" To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: buildworld breakage in getconf Message-ID: <20000427122343.B37827@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <390829F5.2E1ADEFF@openet-telecom.com> <200004271646.MAA48644@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004271646.MAA48644@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Apr 27, 2000 at 12:46:43PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 27, 2000 at 12:46:43PM -0400, Garrett Wollman wrote: > I got caught out by gperf version skew. gperf is now a build-tool (as > it should always have been) so this problem should be fixed in your > next update. cc -pipe -O -DSHELL -I. -I/FBSD/src/bin/sh -Wall -Wformat -static mksyntax.o -o mksyntax cd /FBSD/src/gnu/usr.bin/gperf; make build-tools make: don't know how to make build-tools. Stop *** Error code 2 Stop in /FBSD/src. *** Error code 1 Stop in /FBSD/src. *** Error code 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 12:26:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A858A37BD73; Thu, 27 Apr 2000 12:26:32 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA49083; Thu, 27 Apr 2000 15:26:27 -0400 (EDT) (envelope-from wollman) Date: Thu, 27 Apr 2000 15:26:27 -0400 (EDT) From: Garrett Wollman Message-Id: <200004271926.PAA49083@khavrinen.lcs.mit.edu> To: obrien@FreeBSD.ORG Cc: current@FreeBSD.ORG Subject: Re: buildworld breakage in getconf In-Reply-To: <20000427122319.A37827@dragon.nuxi.com> References: <390829F5.2E1ADEFF@openet-telecom.com> <200004271646.MAA48644@khavrinen.lcs.mit.edu> <20000427122319.A37827@dragon.nuxi.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > Was this not ``make buildworld'' tested, or is there a change to > gnu/usr.bin/gperf/Makefile you forgot to commit? I am obviously *way* out of date with the state of the build system.... I was trying to quickly get things back working again for upgrade builds, and ended up breaking everything.... sigh.... -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 12:32:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 7424F37B7DC for ; Thu, 27 Apr 2000 12:32:04 -0700 (PDT) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id VAA06113; Thu, 27 Apr 2000 21:31:16 +0200 (CEST) (envelope-from asmodai) Date: Thu, 27 Apr 2000 21:31:16 +0200 From: Jeroen Ruigrok van der Werven To: Stephen Hocking-Senior Programmer PGS SPS Perth Cc: current@FreeBSD.ORG Subject: Re: DEVFS - what's happening with it? Message-ID: <20000427213116.E5420@lucifer.bart.nl> References: <200004270502.NAA29330@ugly.prth.tensor.pgs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004270502.NAA29330@ugly.prth.tensor.pgs.com>; from shocking@ugly.prth.tensor.pgs.com on Thu, Apr 27, 2000 at 01:02:39PM +0800 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000427 07:05], Stephen Hocking-Senior Programmer PGS SPS Perth (shocking@ugly.prth.tensor.pgs.com) wrote: >Haven't seen any discussion for quite some time. The Linux people seem to be >getting into a lather about it as well. Rehashing the issues like device >persistence, et cetera. If I recall correctly, Boris Popov is working on that, next to his SMB code. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Answering the questions that no one asks... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 13: 4:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 660EF37B818 for ; Thu, 27 Apr 2000 13:04:37 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id WAA66943 for ; Thu, 27 Apr 2000 22:04:19 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: FreeBSD build status Date: Thu, 27 Apr 2000 22:04:19 +0200 Message-ID: <66941.956865859@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG =================================== SUMMARY =================================== World ***didn't compile*** 3 Warnings Kernel LINT compiled 147 Warnings Kernel GENERIC compiled 58 Warnings Kernel GENERIC98 ***didn't compile*** 63 Warnings =================================== Compile errors for kernel GENERIC98 =================================== cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../pc98/pc98/wd_cd.c In file included from ../../pc98/pc98/wd_cd.c:44: ../../pc98/pc98/wormio.h:9: warning: `/*' within comment ../../pc98/pc98/wormio.h:117: unbalanced `#endif' *** Error code 1 (continuing) `all' not remade because of errors. =================================== Compile errors from make world =================================== cd /otte/src/games/phantasia; make build-tools cc -O -pipe -c -o cross-phantglobs.o /otte/src/games/phantasia/phantglobs.c cc -O -pipe -c /otte/src/games/phantasia/setup.c cc -static -O -pipe -o setup cross-phantglobs.o setup.o -lm cd /otte/src/gnu/usr.bin/gperf; make build-tools make: don't know how to make build-tools. Stop *** Error code 2 Stop in /otte/src. *** Error code 1 Stop in /otte/src. *** Error code 1 Stop in /otte/src. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 13: 9: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from morpheus.skynet.be (morpheus.skynet.be [195.238.2.39]) by hub.freebsd.org (Postfix) with ESMTP id 7516C37B993; Thu, 27 Apr 2000 13:09:03 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [194.78.235.98] (dialup1890.brussels.skynet.be [194.78.235.98]) by morpheus.skynet.be (Postfix) with ESMTP id F33A6DB04; Thu, 27 Apr 2000 22:08:57 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: <200004271716.KAA08417@mass.cdrom.com> References: <200004271716.KAA08417@mass.cdrom.com> Date: Thu, 27 Apr 2000 21:57:37 +0200 To: Mike Smith From: Brad Knowles Subject: Re: Support for large mfs Cc: Matthew Dillon , "John W. DeBoskey" , freebsd-current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:16 AM -0700 2000/4/27, Mike Smith wrote: > I would consider 4.0, several (three or four) strings of LVD disks and > either a Mylex eXtremeRAID 1100 (64MB or more) or an AMI MegaRAID > Enterprise 1500. (The 1600 should probably work too, but I haven't seen > one yet so I can't be sure.) And definitely softupdates. That would be for a spool server, but a news peering server shouldn't need that many disks. I was planning on doing four 10kRPM/18GB disks with a small RAID 0+1 partition for /usr/news/history (and a separate one for the /usr/news/spool), but four separate filesystems mounted under /usr/news/spool/news, and doing it all with vinum. I figure if I lose a single disk, 1/4 of the spool will be toast but /usr/news/history and /usr/news/spool will still be okay (albeit reduced in performance), and vinum should be quite fast enough for what will be asked of it. > Note that you can't put more than 8 disks into an array with the Mylex > controller (easily), so you'd still want to use ccd or vinum over the top. I'm doing that now on our news spool server, for similar reasons -- it can't make simultaneous use of more than five disks in a LUN, and can't do its own striping across LUNs. In fact, I'd be extremely interested to know if you can build a Mylex or AMI RAID configuration that is optimized for random read performance that can perform on the same sort of levels as the 1.8TB news spool server that Joe Greco built (and reported on in news.software.nntp), the solid-state disk that Terry Kennedy has on his news peering server (and reported on in news.software.nntp), or the news spool server I've built (and reported on in news.software.nntp ;-). -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 13:21:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from camel.avias.com (camel.avias.com [195.14.38.87]) by hub.freebsd.org (Postfix) with ESMTP id 9238737B523 for ; Thu, 27 Apr 2000 13:21:39 -0700 (PDT) (envelope-from camel@avias.com) Received: from 192.168.2.2 ([192.168.2.2]) by camel.avias.com (8.9.3/8.9.3) with ESMTP id AAA96078 for ; Fri, 28 Apr 2000 00:21:37 +0400 (MSD) (envelope-from camel@avias.com) Date: Fri, 28 Apr 2000 00:21:45 +0400 From: Ilya Naumov X-Mailer: The Bat! (v1.42 Beta/19) Educational Reply-To: Ilya Naumov X-Priority: 3 (Normal) Message-ID: <19614794653.20000428002145@avias.com> To: current@FreeBSD.ORG Subject: "make release" breakage Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, make release fails with the following diagnosis: ===> bin/csh/nls ===> bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /R/stage/trees/bin/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat *** Error code 71 -- Best regards, Ilya mailto:camel@avias.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 13:44: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from io.yi.org (24.67.218.186.bc.wave.home.com [24.67.218.186]) by hub.freebsd.org (Postfix) with ESMTP id DDFA037B818 for ; Thu, 27 Apr 2000 13:43:42 -0700 (PDT) (envelope-from jburkhol@home.com) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 9648DBCA7; Thu, 27 Apr 2000 13:43:41 -0700 (PDT) X-Mailer: exmh version 2.1.1 10/15/1999 To: Doug Rabson Cc: Jake Burkholder , Bruce Evans , Boris Popov , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: Message from Doug Rabson of "Tue, 25 Apr 2000 21:50:25 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 13:43:41 -0700 From: Jake Burkholder Message-Id: <20000427204341.9648DBCA7@io.yi.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ...snip... > > Its nice to see someone actually using kobj so soon. There is a possible > performance problem though - kobj method calls are roughly 20% slower than > direct function calls. Having said that, this isn't that slow - I timed a > method call to a two argument function at ~40ns on a 300MHz PII. > > I could improve this for some applications (including this one) by > providing a mechanism for an application to cache the function pointer > returned by the method lookup. Yes, this sounds interesting. I can see that there are provisions for a cache in the code, and I can see from the sysctls that hits and misses are happening, but I can't see where the function pointers are entered into the cache. Is this enabled by default? It also might be possible to have default implementations that do "less than nothing", a special value could be entered in the cache that indicates don't call through the function pointer at all. I don't know how an inline cache lookup would compare to an empty function call, but it might be a win when the locks are supposed to do nothing. Anyway, I've made a patch that uses Boris's suggestion of providing functions with empty bodies. I worry about optimizing for the static UP kernel because of introducing more SMP and KLD_MODULE ifdefs, possibly it should just be a function call in all cases. http://io.yi.org/lock.diff I will send-pr it if no one has any comments. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 15:48: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id 8F11237BCBC for ; Thu, 27 Apr 2000 15:48:05 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (04-128.dial.008.popsite.net [209.69.197.128]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id PAA65373; Thu, 27 Apr 2000 15:47:18 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id 4D2A41923; Thu, 27 Apr 2000 09:09:06 -0400 (EDT) Date: Thu, 27 Apr 2000 09:09:06 -0400 From: Will Andrews To: Frank Mayhar Cc: Richard Wackerbarth , Doug Barton , current@freebsd.org Subject: Re: Archive pruning Message-ID: <20000427090905.C390@argon.blackdawn.com> References: <00042603564400.06932@nomad.dataplex.net> <200004261553.IAA33917@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004261553.IAA33917@realtime.exit.com>; from frank@exit.com on Wed, Apr 26, 2000 at 08:53:52AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 08:53:52AM -0700, Frank Mayhar wrote: > "Frankly, my dear, I don't give a damn." Richard, for the record, I'd like to point out that the person who said this is not a developer and therefore the backlashing you're getting is not solely from developers. Other people are sick of your crap, too. :) -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 16:37: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 5EB2437B957 for ; Thu, 27 Apr 2000 16:37:04 -0700 (PDT) (envelope-from jeremyp@pc0640.alcatel.com.au) Received: by border.alcanet.com.au id <115256>; Fri, 28 Apr 2000 09:37:29 +1000 From: Peter Jeremy Subject: Re: asm_pci.h,v Holy cow! In-reply-to: <89056.956663223@axl.ops.uunet.co.za>; from sheldonh@uunet.co.za on Tue, Apr 25, 2000 at 09:48:18PM +1000 To: Sheldon Hearn Cc: current@FreeBSD.ORG Message-Id: <00Apr28.093729est.115256@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <89056.956663223@axl.ops.uunet.co.za> Date: Fri, 28 Apr 2000 09:37:27 +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 09:48:18PM +1000, Sheldon Hearn wrote: >If that's the _only_ point, then Garrett Wollman's idea should work >perfectly. Stick the files under CVS, just agree that they should >never be revised, but rather that new versions should be imported in a >different directory and the old versions punted to the Attic. AFAIK, ctm (not sure about CVSup) doesn't support a rename function - when a file is deleted into the Attic, ctm deletes the old file and then creates a new file in the Attic (transferring the content). So this approach probably wouldn't solve Julian's immediate problem. Apart from that, this approach seems significantly better than (effectively) committing diffs to binary files. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 16:37:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 86C2D37BDAB for ; Thu, 27 Apr 2000 16:37:17 -0700 (PDT) (envelope-from jeremyp@pc0640.alcatel.com.au) Received: by border.alcanet.com.au id <115303>; Fri, 28 Apr 2000 09:37:40 +1000 From: Peter Jeremy Subject: Re: asm_pci.h,v Holy cow! In-reply-to: <200004241726.NAA34251@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Apr 25, 2000 at 03:27:38AM +1000 To: Garrett Wollman Cc: current@FreeBSD.ORG Message-Id: <00Apr28.093740est.115303@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <200004241536.LAA33905@khavrinen.lcs.mit.edu> <200004241726.NAA34251@khavrinen.lcs.mit.edu> Date: Fri, 28 Apr 2000 09:37:40 +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 03:27:38AM +1000, Garrett Wollman wrote: >The fact that said directory is under CVS control, which is what I'm >suggesting we get away from. How do you suggest such files get distributed? Everything else is in the CVS repository and most (if not all) of our build process is designed around it. As Matt pointed out, CVS provides us with a good mechanism for ensuring that I can identify what version of the firmware I am using - and be reasonably certain it matches the code that Matt (or whoever) validated. >The files can be compiled into the kernel very easily using `file2c', >or simply loaded directly by the boot loader. I don't see the purpose of having a firmware image permanently resident (especially given their sizes). Getting the boot loader to directly load the firmware into the device seems a much nicer solution. If this is impractical, treating the firmware as a kld and unloading it after downloading the firmware would seem the next best option. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 16:37:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 0B38C37B957; Thu, 27 Apr 2000 16:37:15 -0700 (PDT) (envelope-from jeremyp@pc0640.alcatel.com.au) Received: by border.alcanet.com.au id <115313>; Fri, 28 Apr 2000 09:37:44 +1000 From: Peter Jeremy Subject: Re: OpenSSL asm optimizations In-reply-to: ; from winter@jurai.net on Sat, Apr 22, 2000 at 02:35:51PM +1000 To: "Matthew N. Dodd" Cc: Kris Kennaway , current@FreeBSD.ORG Message-Id: <00Apr28.093744est.115313@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: Date: Fri, 28 Apr 2000 09:37:44 +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 21 Apr 2000, Kris Kennaway wrote: > OpenSSL includes asm code for several platforms to speed up various > operations. Currently we don't build any of this - the attached patch > turns on asm code for Pentiums and above (it relies on an uncommitted > patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to > "i586" or "i686" (both are actually identical at present) and rebuild. On Sat, Apr 22, 2000 at 02:35:51PM +1000, Matthew N. Dodd wrote: >Can these be turned on at runtime? Not the way the libraries are currently structured. There are a number of libraries where we would get significant speedups by supporting target-dependent code. I can think of three possible ways of supporting this: 1) Use machine-depend shared libraries to replace functions in the standard shared libraries. This approach is used on Solaris - the rtld automatically loads a machine-specific library (if it exists) before libc.so. The disadvantages are: - no support for static executables or in-line functions - slower startup due to the extra libraries (particularly if Kris's idea of an ordered list of machine architectures) - increased VM usage due to multiple function versions in the process address space - I'm not sure how difficult it would be to integrate into FreeBSD's lazy binding scheme 2) Use indirect function calls, with run-time initialisation to setup the pointers. This approach is used in the kernel for bzero/bcopy. The disadvantages are: - no support for in-line functions - need to invoke a library initialisation routine (not too difficult with ELF) - increased function call overheads (indirect rather than direct calls). - increased VM usage due to multiple function versions in the process address space 3) Have separate library versions for each target. - Significant increase in disk space occupied by libraries All the approaches increase the build time since multiple copies of functions need to be built. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 17: 2:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from incandescent.firedrake.org (incandescent.firedrake.org [195.157.96.1]) by hub.freebsd.org (Postfix) with ESMTP id 0E11E37BB94 for ; Thu, 27 Apr 2000 17:02:08 -0700 (PDT) (envelope-from float@firedrake.org) Received: from float by incandescent.firedrake.org with local (Exim 2.05 #1 (Debian)) id 12kyDy-0007j2-00; Fri, 28 Apr 2000 01:01:38 +0100 Date: Fri, 28 Apr 2000 01:01:38 +0100 From: void To: "Michael C . Wu" Cc: "Andrey A. Chernov" , current@freebsd.org Subject: Re: Workaround for hanging on exit: patch for review Message-ID: <20000428010138.A27406@firedrake.org> References: <20000427011402.A7265@nagual.pp.ru> <20000427010616.A26613@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i In-Reply-To: <20000427010616.A26613@peorth.iteration.net>; from keichii@peorth.iteration.net on Thu, Apr 27, 2000 at 01:06:16AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 27, 2000 at 01:06:16AM -0500, Michael C . Wu wrote: > On Thu, Apr 27, 2000 at 01:14:02AM +0400, Andrey A. Chernov scribbled: > | I often notice processes hanging forever on exit's ttywait when TCP > | connection dropped. Here is a patch I plan to commit which restrict > | waiting for output drain by 3 minutes. Any comments, improvements or > | objections? > ---end quoted text--- > > This sounds really absurd and "bike shed"ish. > Please make that 5 minutes. I frequently connect > to places that have 2~3 minute lag. :) And make it sysctl-controllable, perhaps? -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 17:12:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from MexComUSA.Net (adsl-63-200-120-86.dsl.mtry01.pacbell.net [63.200.120.86]) by hub.freebsd.org (Postfix) with ESMTP id 8637D37BCBC for ; Thu, 27 Apr 2000 17:11:02 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Received: from EnContacto.Net (adsl-63-200-120-84.dsl.mtry01.pacbell.net [63.200.120.84]) by MexComUSA.Net (8.9.3/8.9.3) with ESMTP id RAA17688; Thu, 27 Apr 2000 17:10:55 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Message-ID: <3908D70F.E2D83554@EnContacto.Net> Date: Thu, 27 Apr 2000 17:10:55 -0700 From: Edwin Culp Organization: MexComUSA.Net/EnContacto.Net X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ilya Naumov Cc: current@FreeBSD.ORG Subject: Re: "make release" breakage References: <19614794653.20000428002145@avias.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ilya Naumov wrote: > Hello, > > make release fails with the following diagnosis: > > ===> bin/csh/nls > ===> bin/csh/nls/finnish > install -c -o root -g wheel -m 444 tcsh.cat /R/stage/trees/bin/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat > *** Error code 71 > I just finished one a couple of hours ago with a cvsup and world this morning of course I do it with NODOC=yes. ed Making fixit floppy. disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/rvnn0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 384 i/g) super-block backups (for fsck -b #) at: 32 2606 blocks Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounte d on /dev/vnn0c 1363 1322 -68 105% 353 29 92% /mnt >>> Filesystem is 1440 K, -68 left >>> 4000 bytes/inode, 29 left touch release.9 0 blocks Setting up CDROM distribution area 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks Setting up FTP distribution area 0 blocks 0 blocks Release done + echo make release Finished make release Finished To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 17:25: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id B7D9A37BCBC for ; Thu, 27 Apr 2000 17:25:06 -0700 (PDT) (envelope-from leifn@neland.dk) Received: (from uucp@localhost) by ns.internet.dk (8.9.2/8.9.3) with UUCP id CAA02481 for freebsd-current@FreeBSD.ORG; Fri, 28 Apr 2000 02:25:05 +0200 (CEST) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.9.3/8.9.3) with SMTP id CAA95002 for ; Fri, 28 Apr 2000 02:24:51 +0200 (CEST) (envelope-from leifn@neland.dk) Message-ID: <021701bfb0a8$54a113a0$0e00a8c0@neland.dk> Reply-To: "Leif Neland" From: "Leif Neland" To: Subject: kernel panic at boot with 2 printers Date: Fri, 28 Apr 2000 02:25:23 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry not to have details at hand but anyways: Current cvsupped today. I have 2 parallel ports in use. I have had no problems with kernels dated 2 weeks or older, but since a few days ago, the system crashes at boot while probing the parallel ports. "Page fault while in supervisor mode", (I seem to remember vaguely) If I disable either lpt0 or lpt1 in -c config, the system boots and operates without problems. I know this is a terrible bug-report, but perhaps it still could trigger the memory of whoever made changes to the printer system.... I can provide better info tomorrow if needed, but it's so late I can't find a pencil to write the exact messages. 'night Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 17:47:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id DCED837BE24 for ; Thu, 27 Apr 2000 17:47:48 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA50288; Thu, 27 Apr 2000 20:47:42 -0400 (EDT) (envelope-from wollman) Date: Thu, 27 Apr 2000 20:47:42 -0400 (EDT) From: Garrett Wollman Message-Id: <200004280047.UAA50288@khavrinen.lcs.mit.edu> To: Peter Jeremy Cc: current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <00Apr28.093740est.115303@border.alcanet.com.au> References: <200004241536.LAA33905@khavrinen.lcs.mit.edu> <200004241726.NAA34251@khavrinen.lcs.mit.edu> <00Apr28.093740est.115303@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > How do you suggest such files get distributed? cvsup and/or rsync. This does leave CTM-users the odd men out.... > As Matt pointed out, CVS provides us with a good mechanism for > ensuring that I can identify what version of the firmware I am using > - and be reasonably certain it matches the code that Matt (or > whoever) validated. So would simply naming the files by version. This works because most if not all of our drivers use firmware from another vendor with its own version-numbering scheme. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 18: 0:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from pericles.IPAustralia.gov.au (pericles.IPAustralia.gov.au [202.14.186.30]) by hub.freebsd.org (Postfix) with ESMTP id 266FF37BDB4 for ; Thu, 27 Apr 2000 18:00:15 -0700 (PDT) (envelope-from carl@xena.aipo.gov.au) Received: (from smap@localhost) by pericles.IPAustralia.gov.au (8.9.3/8.9.3) id KAA69093; Fri, 28 Apr 2000 10:59:31 +1000 (EST) (envelope-from carl@xena.aipo.gov.au) Received: from newton.aipo.gov.au(10.0.100.18) by pericles.IPAustralia.gov.au via smap (V2.0) id xma069081; Fri, 28 Apr 00 10:59:02 +1000 Received: from localhost (carl@localhost) by newton.aipo.gov.au (8.9.3/8.9.3) with ESMTP id LAA37375; Fri, 28 Apr 2000 11:01:36 +1000 (EST) (envelope-from carl@xena.aipo.gov.au) X-Authentication-Warning: newton.aipo.gov.au: carl owned process doing -bs Date: Fri, 28 Apr 2000 11:01:36 +1000 (EST) From: Carl Makin X-Sender: carl@newton.aipo.gov.au To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs In-Reply-To: <200004271634.JAA05279@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Matthew, On Thu, 27 Apr 2000, Matthew Dillon wrote: > I can't imagine why MFS would perform better... it shouldn't, every > block is stored in system memory *TWICE* (once in the VM cache, and > once in the mfs process's address space). If you have enough system I've been running a MFS /tmp dir since around 2.2.4, are you now saying that it would be better (under 4.0-STABLE or CURRENT) to run a swap backed vnode fs? Carl. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 18:32:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 636A337B934 for ; Thu, 27 Apr 2000 18:32:30 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA07593; Thu, 27 Apr 2000 18:32:24 -0700 (PDT) (envelope-from dillon) Date: Thu, 27 Apr 2000 18:32:24 -0700 (PDT) From: Matthew Dillon Message-Id: <200004280132.SAA07593@apollo.backplane.com> To: Carl Makin Cc: freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi Matthew, : :On Thu, 27 Apr 2000, Matthew Dillon wrote: : :> I can't imagine why MFS would perform better... it shouldn't, every :> block is stored in system memory *TWICE* (once in the VM cache, and :> once in the mfs process's address space). If you have enough system : :I've been running a MFS /tmp dir since around 2.2.4, are you now saying :that it would be better (under 4.0-STABLE or CURRENT) to run a swap backed :vnode fs? : :Carl. With a softupdates /tmp, the only thing MFS will save you are the write-behind disk writes on large files. The cost to using MFS is that every disk block in an MFS filesystem is in main memory twice. If you do anything significant in your /tmp this will strain the VM system. In general, an MFS /tmp does not give you enough of an advantage to be worth it. I would go with a normal UFS /tmp with softupdates enabled. A Swap-backed VN /tmp will work as well, but keep in mind that the sector size is 4K and you should use the appropriate options to vnconfig to pre-reserve the swap space so performance does not degrade from fragmentation. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 20:23:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from tkc.att.ne.jp (tkc.att.ne.jp [165.76.16.7]) by hub.freebsd.org (Postfix) with ESMTP id E4F5D37B901; Thu, 27 Apr 2000 20:23:26 -0700 (PDT) (envelope-from mzaki@e-mail.ne.jp) Received: from work.mzaki.nom (232.pool5.tokyo.att.ne.jp [165.76.22.247]) by tkc.att.ne.jp (8.8.8+Spin/3.6W-CONS(10/24/99)) id MAA20199; Fri, 28 Apr 2000 12:23:23 +0900 (JST) Received: from work.mzaki.nom (mzaki@localhost [127.0.0.1]) by work.mzaki.nom (8.9.3/8.9.3) with ESMTP id MAA00401; Fri, 28 Apr 2000 12:23:30 +0900 (JST) (envelope-from mzaki@e-mail.ne.jp) Date: Fri, 28 Apr 2000 12:23:29 +0900 Message-ID: <8666t2q572.wl@tkc.att.ne.jp> From: Motomichi Matsuzaki To: jhb@FreeBSD.org Cc: dcs@newsguy.com, FreeBSD-current@FreeBSD.org, mzaki@e-mail.ne.jp Subject: Re: Please test for 8G-OVER-Booting with /boot/loader In-Reply-To: In your message of "Tue, 28 Mar 2000 06:46:27 -0500 (EST)" <200003281146.GAA87302@server.baldwin.cx> References: <38E067A8.10298DC@newsguy.com> <200003281146.GAA87302@server.baldwin.cx> X-Mailer: Wanderlust/2.2.12 (Joyride) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: multipart/mixed; boundary="Multipart_Fri_Apr_28_12:23:29_2000-1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Multipart_Fri_Apr_28_12:23:29_2000-1 Content-Type: text/plain; charset=US-ASCII Hi At Tue, 28 Mar 2000 06:46:27 -0500 (EST), John Baldwin wrote: > >> Looks good to me, but I need to test it to make sure. I will also look > >> at seeing if I can squeeze the int 13 extension installation check into > >> boot1 and boot0 so that they will use packet mode automatically as well. > Oh, I remember. This just checks if the controller supports LBA. You also > need to check if the drive supports LBA. The problem is with older drives. > Hmm, I'll look around to see if you can ask the BIOS for drive capabilities. I have convinced that there are no widespread services to query whether drive supports LBA. So I changed my patch to use Packet I/F only when we need to access over 8GB. Please review and test following patch. Thanks. -- Motomichi Matsuzaki Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan --Multipart_Fri_Apr_28_12:23:29_2000-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="biosdisk.c.diff" Content-Transfer-Encoding: 7bit --- boot/i386/libi386/biosdisk.c.orig Wed Mar 29 06:03:28 2000 +++ boot/i386/libi386/biosdisk.c Fri Apr 28 11:59:22 2000 @@ -74,7 +74,7 @@ int od_flags; #define BD_MODEMASK 0x3 #define BD_MODEINT13 0x0 -#define BD_MODEEDD1 0x1 +#define BD_MODEPACKET 0x1 #define BD_MODEEDD3 0x2 #define BD_FLOPPY (1<<2) struct disklabel od_disklabel; @@ -166,13 +166,13 @@ bdinfo[nbdinfo].bd_unit = unit; bdinfo[nbdinfo].bd_flags = (unit < 0x80) ? BD_FLOPPY : 0; - /* XXX add EDD probes */ if (!bd_int13probe(&bdinfo[nbdinfo])) break; /* XXX we need "disk aliases" to make this simpler */ - printf("BIOS drive %c: is disk%d\n", - (unit < 0x80) ? ('A' + unit) : ('C' + unit - 0x80), nbdinfo); + printf("BIOS drive %c: is disk%d%s\n", + (unit < 0x80) ? ('A' + unit) : ('C' + unit - 0x80), nbdinfo, + (bdinfo[nbdinfo].bd_flags & BD_MODEPACKET) ? " (LBA)" : ""); nbdinfo++; } } @@ -180,7 +180,7 @@ } /* - * Try to detect a device supported by the legacy int13 BIOS + * Try to detect a device supported by the int13 BIOS */ static int @@ -197,6 +197,26 @@ ((v86.edx & 0xff) > (bd->bd_unit & 0x7f))) { /* unit # OK */ bd->bd_flags |= BD_MODEINT13; bd->bd_type = v86.ebx & 0xff; + + /* LBA support by Motomichi Matsuzaki */ + + v86.ctl = V86_FLAGS; + v86.addr = 0x13; + v86.eax = 0x4100; + v86.ebx = 0x55AA; + v86.edx = bd->bd_unit; + v86int(); + + if (!(v86.efl & 0x1) && /* carry clear */ + (v86.ebx & 0xffff) == 0xAA55) { /* magic OK */ + if ((v86.eax & 0xf000) >= 0x3000) { + bd->bd_flags |= BD_MODEEDD3; /* meanless? */ + } + if (v86.ecx & 0x1) { + bd->bd_flags |= BD_MODEPACKET; /* packet access */ + } + } + return(1); } return(0); @@ -648,6 +668,15 @@ /* Max number of sectors to bounce-buffer if the request crosses a 64k boundary */ #define FLOPPY_BOUNCEBUF 18 +struct lba_packet { + u_int8_t len; + u_int8_t rsrv; + u_int16_t blks; + u_int16_t offs; + u_int16_t seg; + u_int64_t blkno; +}; + static int bd_read(struct open_disk *od, daddr_t dblk, int blks, caddr_t dest) { @@ -709,25 +738,46 @@ v86.edx = od->od_unit; v86int(); } - - /* build request XXX support EDD requests too */ - v86.ctl = V86_FLAGS; - v86.addr = 0x13; - v86.eax = 0x200 | x; - v86.ecx = ((cyl & 0xff) << 8) | ((cyl & 0x300) >> 2) | sec; - v86.edx = (hd << 8) | od->od_unit; - v86.es = VTOPSEG(xp); - v86.ebx = VTOPOFF(xp); - v86int(); + + /* build request */ + if (od->od_flags & BD_MODEPACKET && + (hd & ~0xff || cyl & ~0x3ff || sec & ~0x3f)) { + struct lba_packet pkt + = {sizeof(pkt), 0, x, VTOPOFF(xp), VTOPSEG(xp), dblk}; + v86.ctl = V86_FLAGS; + v86.addr = 0x13; + v86.eax = 0x4200; + v86.edx = od->od_unit; + v86.ds = VTOPSEG(&pkt); + v86.esi = VTOPOFF(&pkt); + v86int(); + } else { + v86.ctl = V86_FLAGS; + v86.addr = 0x13; + v86.eax = 0x200 | x; + v86.ecx = ((cyl & 0xff) << 8) | ((cyl & 0x300) >> 2) | sec; + v86.edx = (hd << 8) | od->od_unit; + v86.es = VTOPSEG(xp); + v86.ebx = VTOPOFF(xp); + v86int(); + } result = (v86.efl & 0x1); if (result == 0) break; } - DEBUG("%d sectors from %d/%d/%d to %p (0x%x) %s", x, cyl, hd, sec - 1, p, VTOP(p), result ? "failed" : "ok"); - /* BUG here, cannot use v86 in printf because putchar uses it too */ - DEBUG("ax = 0x%04x cx = 0x%04x dx = 0x%04x status 0x%x", - 0x200 | x, ((cyl & 0xff) << 8) | ((cyl & 0x300) >> 2) | sec, (hd << 8) | od->od_unit, (v86.eax >> 8) & 0xff); + if (od->od_flags & BD_MODEPACKET && + (hd & ~0xff || cyl & ~0x3ff || sec & ~0x3f)) { + DEBUG("%d sectors from linear %d to %p (0x%x) using LBA %s", + x, dblk, p, VTOP(p), result ? "failed" : "ok"); + } else { + DEBUG("%d sectors from %d/%d/%d to %p (0x%x) %s", + x, cyl, hd, sec - 1, p, VTOP(p), result ? "failed" : "ok"); + /* BUG here, cannot use v86 in printf because putchar uses it too */ + DEBUG("ax = 0x%04x cx = 0x%04x dx = 0x%04x status 0x%x", + 0x200 | x, ((cyl & 0xff) << 8) | ((cyl & 0x300) >> 2) | sec, + (hd << 8) | od->od_unit, (v86.eax >> 8) & 0xff); + } if (result) { if (bbuf != NULL) free(bbuf); --Multipart_Fri_Apr_28_12:23:29_2000-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 20:43:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6771A37BC5A for ; Thu, 27 Apr 2000 20:43:44 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id UAA18206; Thu, 27 Apr 2000 20:42:14 -0700 Date: Thu, 27 Apr 2000 20:43:20 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Peter Jeremy Cc: Garrett Wollman , current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: <00Apr28.093740est.115303@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't see the purpose of having a firmware image permanently > resident (especially given their sizes). Getting the boot loader to > directly load the firmware into the device seems a much nicer > solution. If this is impractical, treating the firmware as a kld and > unloading it after downloading the firmware would seem the next best > option. There's an open PR on this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 22:26:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id BE8B237B8DD; Thu, 27 Apr 2000 22:26:54 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (04-128.dial.008.popsite.net [209.69.197.128]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id WAA70343; Thu, 27 Apr 2000 22:26:48 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id 6C7FD18E6; Fri, 28 Apr 2000 01:26:30 -0400 (EDT) Date: Fri, 28 Apr 2000 01:26:30 -0400 From: Will Andrews To: Poul-Henning Kamp Cc: current@FreeBSD.ORG Subject: Re: PATCH: Removal of unneeded Message-ID: <20000428012630.B2098@argon.blackdawn.com> References: <58618.956742611@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <58618.956742611@critter.freebsd.dk>; from phk@FreeBSD.ORG on Wed, Apr 26, 2000 at 11:50:11AM +0200 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 11:50:11AM +0200, Poul-Henning Kamp wrote: > New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch > > This patch removes 67 unneeded instances of #include > > Comments, tests and reviews please. Just write a script to check all #include's against their prototypes and have it autogen diffs. I'm sure perl mavens will say that'll only take about 100 lines of perl. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 22:42:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id C4B9A37B6DA for ; Thu, 27 Apr 2000 22:42:10 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 1081 invoked from network); 28 Apr 2000 05:42:09 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 28 Apr 2000 05:42:09 -0000 Message-ID: <390924AD.6313EDAA@cvzoom.net> Date: Fri, 28 Apr 2000 01:42:05 -0400 From: Donn Miller X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Will Andrews Cc: Poul-Henning Kamp , current@FreeBSD.ORG Subject: Re: PATCH: Removal of unneeded References: <58618.956742611@critter.freebsd.dk> <20000428012630.B2098@argon.blackdawn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Will Andrews wrote: > > On Wed, Apr 26, 2000 at 11:50:11AM +0200, Poul-Henning Kamp wrote: > > Comments, tests and reviews please. > > Just write a script to check all #include's against their prototypes and > have it autogen diffs. I agree. I like the automated method better. What happens if someone accidentally commits an additional unnecessary #include after the patch has been applied? - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 22:46:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 5B59B37B5CA for ; Thu, 27 Apr 2000 22:46:08 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id HAA69169; Fri, 28 Apr 2000 07:45:37 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Donn Miller Cc: Will Andrews , current@FreeBSD.ORG Subject: Re: PATCH: Removal of unneeded In-reply-to: Your message of "Fri, 28 Apr 2000 01:42:05 EDT." <390924AD.6313EDAA@cvzoom.net> Date: Fri, 28 Apr 2000 07:45:36 +0200 Message-ID: <69167.956900736@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <390924AD.6313EDAA@cvzoom.net>, Donn Miller writes: >Will Andrews wrote: >> >> On Wed, Apr 26, 2000 at 11:50:11AM +0200, Poul-Henning Kamp wrote: > >> > Comments, tests and reviews please. >> >> Just write a script to check all #include's against their prototypes and >> have it autogen diffs. > >I agree. I like the automated method better. What happens if someone >accidentally commits an additional unnecessary #include after the >patch has been applied? I agree too, but nobody has written *that* code yet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 23: 0:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id 0809C37B770 for ; Thu, 27 Apr 2000 23:00:57 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (04-128.dial.008.popsite.net [209.69.197.128]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id WAA70578; Thu, 27 Apr 2000 22:56:00 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id 7EAA418E6; Fri, 28 Apr 2000 01:55:42 -0400 (EDT) Date: Fri, 28 Apr 2000 01:55:42 -0400 From: Will Andrews To: Poul-Henning Kamp Cc: Donn Miller , Will Andrews , current@FreeBSD.ORG Subject: Re: PATCH: Removal of unneeded Message-ID: <20000428015542.D2098@argon.blackdawn.com> References: <390924AD.6313EDAA@cvzoom.net> <69167.956900736@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <69167.956900736@critter.freebsd.dk>; from phk@critter.freebsd.dk on Fri, Apr 28, 2000 at 07:45:36AM +0200 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 28, 2000 at 07:45:36AM +0200, Poul-Henning Kamp wrote: > I agree too, but nobody has written *that* code yet. Instead of trying to find these yourself, why not invest this time in writing said script? :) (I'm not volunteering for this.. ;-) -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 23: 4:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id C9DF937B963 for ; Thu, 27 Apr 2000 23:04:09 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id IAA69240; Fri, 28 Apr 2000 08:03:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Will Andrews Cc: Donn Miller , current@FreeBSD.ORG Subject: Re: PATCH: Removal of unneeded In-reply-to: Your message of "Fri, 28 Apr 2000 01:55:42 EDT." <20000428015542.D2098@argon.blackdawn.com> Date: Fri, 28 Apr 2000 08:03:45 +0200 Message-ID: <69238.956901825@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000428015542.D2098@argon.blackdawn.com>, Will Andrews writes: >On Fri, Apr 28, 2000 at 07:45:36AM +0200, Poul-Henning Kamp wrote: >> I agree too, but nobody has written *that* code yet. > >Instead of trying to find these yourself, why not invest this time in >writing said script? :) I already wrote src/tools/tools/kerniinclude that works for me for now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Apr 27 23:52:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id F088937BE89 for ; Thu, 27 Apr 2000 23:52:20 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 22463 invoked from network); 28 Apr 2000 06:52:17 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 28 Apr 2000 06:52:17 -0000 Date: Fri, 28 Apr 2000 16:52:13 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Poul-Henning Kamp Cc: current@FreeBSD.ORG Subject: Re: FreeBSD build status In-Reply-To: <66941.956865859@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Poul-Henning Kamp wrote: > =================================== > SUMMARY > =================================== > World > ***didn't compile*** > 3 Warnings > Kernel LINT > compiled > 147 Warnings LINT has been broken for a long time by depenencies on optional crypto sources (sys/crypto). The IPSEC options have required crypto sources for a long time. Now the NETGRQAPH_MPCC_ENCRYPTION option requires them. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 0: 2: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 36A3637BBC9 for ; Fri, 28 Apr 2000 00:02:04 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id JAA69416; Fri, 28 Apr 2000 09:01:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: FreeBSD build status In-reply-to: Your message of "Fri, 28 Apr 2000 16:52:13 +1000." Date: Fri, 28 Apr 2000 09:01:38 +0200 Message-ID: <69414.956905298@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bruce Ev ans writes: >On Thu, 27 Apr 2000, Poul-Henning Kamp wrote: > >> =================================== >> SUMMARY >> =================================== >> World >> ***didn't compile*** >> 3 Warnings >> Kernel LINT >> compiled >> 147 Warnings > >LINT has been broken for a long time by depenencies on optional crypto >sources (sys/crypto). The IPSEC options have required crypto sources >for a long time. Now the NETGRQAPH_MPCC_ENCRYPTION option requires >them. I've given up on that fight, I pull the internat crypto sources now... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 1: 7:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 173BD37B7CD for ; Fri, 28 Apr 2000 01:07:44 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 12l5oJ-000D9M-0Y; Fri, 28 Apr 2000 09:07:42 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA48163; Fri, 28 Apr 2000 09:07:55 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 28 Apr 2000 09:12:27 +0100 (BST) From: Doug Rabson To: Jake Burkholder Cc: Bruce Evans , Boris Popov , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000427204341.9648DBCA7@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Jake Burkholder wrote: > ...snip... > > > > Its nice to see someone actually using kobj so soon. There is a possible > > performance problem though - kobj method calls are roughly 20% slower than > > direct function calls. Having said that, this isn't that slow - I timed a > > method call to a two argument function at ~40ns on a 300MHz PII. > > > > I could improve this for some applications (including this one) by > > providing a mechanism for an application to cache the function pointer > > returned by the method lookup. > > Yes, this sounds interesting. I can see that there are provisions for a > cache in the code, and I can see from the sysctls that hits and misses > are happening, but I can't see where the function pointers are entered > into the cache. Is this enabled by default? This is enabled by default. The address of the cache entry is passed as the second argument to kobj_lookup_method(). > > It also might be possible to have default implementations that do > "less than nothing", a special value could be entered in the cache that > indicates don't call through the function pointer at all. I don't know > how an inline cache lookup would compare to an empty function call, > but it might be a win when the locks are supposed to do nothing. Thats an interesting thought. It would add a compare and branch to the normal method dispatch case which might be too high a cost. > > Anyway, I've made a patch that uses Boris's suggestion of providing > functions with empty bodies. I worry about optimizing for the static UP > kernel because of introducing more SMP and KLD_MODULE ifdefs, possibly it > should just be a function call in all cases. > > http://io.yi.org/lock.diff > > I will send-pr it if no one has any comments. It looks quite reasonable to me. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 1:16:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id E848A37BE57 for ; Fri, 28 Apr 2000 01:16:30 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id RAA69255; Fri, 28 Apr 2000 17:45:38 +0930 (CST) Date: Fri, 28 Apr 2000 17:45:38 +0930 From: Greg Lehey To: Poul-Henning Kamp Cc: current@FreeBSD.ORG Subject: Re: FreeBSD build status Message-ID: <20000428174538.F67288@freebie.lemis.com> References: <66941.956865859@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <66941.956865859@critter.freebsd.dk> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 27 April 2000 at 22:04:19 +0200, Poul-Henning Kamp wrote: This looks a lot better. Greg > =================================== > SUMMARY > =================================== > World > ***didn't compile*** > 3 Warnings > Kernel LINT > compiled > 147 Warnings > Kernel GENERIC > compiled > 58 Warnings > Kernel GENERIC98 > ***didn't compile*** > 63 Warnings > > =================================== > Compile errors for kernel GENERIC98 > =================================== > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../pc98/pc98/wd_cd.c > In file included from ../../pc98/pc98/wd_cd.c:44: > ../../pc98/pc98/wormio.h:9: warning: `/*' within comment > ../../pc98/pc98/wormio.h:117: unbalanced `#endif' > *** Error code 1 (continuing) > `all' not remade because of errors. > > =================================== > Compile errors from make world > =================================== > cd /otte/src/games/phantasia; make build-tools > cc -O -pipe -c -o cross-phantglobs.o /otte/src/games/phantasia/phantglobs.c > cc -O -pipe -c /otte/src/games/phantasia/setup.c > cc -static -O -pipe -o setup cross-phantglobs.o setup.o -lm > cd /otte/src/gnu/usr.bin/gperf; make build-tools > make: don't know how to make build-tools. Stop > *** Error code 2 > > Stop in /otte/src. > *** Error code 1 > > Stop in /otte/src. > *** Error code 1 > > Stop in /otte/src. -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 4:39:37 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 542) id 0A1B837B6C7; Fri, 28 Apr 2000 04:39:36 -0700 (PDT) Date: Fri, 28 Apr 2000 04:39:36 -0700 From: "Andrey A. Chernov" To: void Cc: "Michael C . Wu" , current@freebsd.org Subject: Re: Workaround for hanging on exit: patch for review Message-ID: <20000428043935.A17180@freebsd.org> References: <20000427011402.A7265@nagual.pp.ru> <20000427010616.A26613@peorth.iteration.net> <20000428010138.A27406@firedrake.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000428010138.A27406@firedrake.org>; from float@firedrake.org on Fri, Apr 28, 2000 at 01:01:38AM +0100 Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 28, 2000 at 01:01:38AM +0100, void wrote: > > to places that have 2~3 minute lag. :) > > And make it sysctl-controllable, perhaps? It is already tunable for years via ioctl -- Andrey A. Chernov http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 4:55:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from Mail.Openet-Telecom.COM (opentisdn.isdn.dublin.esat.net [193.120.50.79]) by hub.freebsd.org (Postfix) with ESMTP id 9627037B611 for ; Fri, 28 Apr 2000 04:55:48 -0700 (PDT) (envelope-from peter.edwards@openet-telecom.com) Received: from openet-telecom.com (rocklobster.openet-telecom.lan [10.0.0.40]) by Mail.Openet-Telecom.COM (8.9.3/8.9.3) with ESMTP id NAA04537; Fri, 28 Apr 2000 13:03:03 +0100 (IST) (envelope-from peter.edwards@openet-telecom.com) Message-ID: <39097C24.55671DBE@openet-telecom.com> Date: Fri, 28 Apr 2000 12:55:16 +0100 From: Peter Edwards Organization: Openet Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: current@FreeBSD.ORG Cc: wc.bulte@chello.nl, Maxim Sobolev Subject: Re: vn.ko load/unload/mount = panic References: <390702C6.BCC0CA88@altavista.net> <39070A7A.A2766B32@openet-telecom.com> <20000426191559.B1021@yedi.wbnet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had a longer look at this, and a more complete patch is logged as PR kern/18270 (try at your own risk: it works for me). I'd appreciate someone more experienced having a look at it and commenting. Cheers, Peter. Wilko Bulte wrote: > > On Wed, Apr 26, 2000 at 04:25:46PM +0100, Peter Edwards (local) wrote: > > How about send-pr ing this stuff? > > Wilko > > > Hi, > > After a (very) quick look at the source it looks like there's a missing > > cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling > > I haven't time to test it, but try this: > > > > *** vn.c.old Wed Apr 26 16:23:03 2000 > > --- vn.c Wed Apr 26 16:24:06 2000 > > *************** > > *** 762,767 **** > > --- 762,768 ---- > > case MOD_UNLOAD: > > /* fall through */ > > case MOD_SHUTDOWN: > > + cdevsw_remove(&vn_cdevsw); > > for (;;) { > > vn = SLIST_FIRST(&vn_list); > > if (!vn) > > > > > > Maxim Sobolev wrote: > > > > > > Hi, > > > > > > I've already submitted this crash report earlier but it seems that developers > > > in -current list are too busy discussing whether Matt allowed to commit his SMP > > > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is > > > slightly simplified course of actions which is known to produce kernel panic on > > > both 4.0 and 5.0: > > > > > > root@notebook# kldstat > > > Id Refs Address Size Name > > > 1 2 0xc0100000 1c2f48 kernel > > > 2 1 0xc02c3000 30c8 splash_bmp.ko > > > root@notebook# mount /dev/vn0c /mnt > > > mount: Device not configured > > > root@notebook# kldload /modules/vn.ko > > > root@notebook# kldstat > > > Id Refs Address Size Name > > > 1 3 0xc0100000 1c2f48 kernel > > > 2 1 0xc02c3000 30c8 splash_bmp.ko > > > 3 1 0xc0823000 3000 vn.ko > > > root@notebook# kldunload -i 3 > > > root@notebook# mount /dev/vn0c /mnt > > > [BINGO] > > > Fatal trap 12: page fault while in kernel mode > > > [...] > > > > > > -Maxim > > -- > Wilko Bulte Powered by FreeBSD http://www.freebsd.org > http://www.tcja.nl > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 5:37:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 929D937B611 for ; Fri, 28 Apr 2000 05:37:22 -0700 (PDT) (envelope-from paul@originative.co.uk) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id 646CD1D160; Fri, 28 Apr 2000 13:37:21 +0100 (BST) Message-ID: <39098601.5258795B@originative.co.uk> Date: Fri, 28 Apr 2000 13:37:21 +0100 From: "Paul Richards.width" Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en-GB, en MIME-Version: 1.0 To: Matthew Dillon Cc: "Andrey A. Chernov" , current@FreeBSD.ORG Subject: Re: Workaround for hanging on exit: patch for review References: <20000427011402.A7265@nagual.pp.ru> <200004262122.OAA97717@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > p.s. (on a different topic) I am also seeing serial stream corruption > for serial console output. If I add a kernel printf() that generates > a lot of output, I get most of it on the serial console plus a lot > of other random garbage. Very weird. I've been seeing this as well. Things seem to work fine until a lot of output occurs and then I just get a load of garbage. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 9:49:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 72E4237BF7D for ; Fri, 28 Apr 2000 09:49:09 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 86EE23E46; Fri, 28 Apr 2000 18:49:08 +0200 (CEST) Date: Fri, 28 Apr 2000 18:49:08 +0200 From: Jesper Skriver To: current@FreeBSD.org Subject: crash - perhaps vinum or sym related Message-ID: <20000428184908.A24463@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On a 5.0-CURRENT box (no custom changes), as of 2 hours ago, we have a reproducable crash when trying to bring up a vinum mirror. The box is a dual 500 MHz Pentium III, intel motherboard Tecram SCSI controllers (the sym driver) and 27 IBM ultrastar 36LZX 9 GB drives, these drives are setup as 2 stripes of 13 drives each, which is mirrored, and a spare disk. I'm not sure if this is a vinum problem, or a problem with the sym driver, I hope someone is able to help us here. Here is what we did. (note this is regarding the raid01 volume). remie# vinum list 29 drives: D d1 State: up Device /dev/da1s1f Avail: 1/3178 MB (0%) D d2 State: up Device /dev/da2s1f Avail: 1/3178 MB (0%) D a1 State: up Device /dev/da5s1e Avail: 0/8682 MB (0%) D a2 State: up Device /dev/da6s1e Avail: 0/8682 MB (0%) D a3 State: up Device /dev/da7s1e Avail: 0/8682 MB (0%) D a4 State: up Device /dev/da8s1e Avail: 0/8682 MB (0%) D a5 State: up Device /dev/da9s1e Avail: 0/8682 MB (0%) D a6 State: up Device /dev/da10s1e Avail: 0/8682 MB (0%) D a7 State: up Device /dev/da11s1e Avail: 0/8682 MB (0%) D a8 State: up Device /dev/da12s1e Avail: 0/8682 MB (0%) D a9 State: up Device /dev/da13s1e Avail: 0/8682 MB (0%) D a10 State: up Device /dev/da14s1e Avail: 0/8682 MB (0%) D a11 State: up Device /dev/da15s1e Avail: 0/8682 MB (0%) D a12 State: up Device /dev/da16s1e Avail: 0/8682 MB (0%) D a13 State: up Device /dev/da17s1e Avail: 0/8682 MB (0%) D hotspare State: up Device /dev/da18s1e Avail: 8682/8682 MB (100%) D b1 State: up Device /dev/da19s1e Avail: 0/8682 MB (0%) D b2 State: up Device /dev/da20s1e Avail: 0/8682 MB (0%) D b3 State: up Device /dev/da21s1e Avail: 0/8682 MB (0%) D b4 State: up Device /dev/da22s1e Avail: 0/8682 MB (0%) D b5 State: up Device /dev/da23s1e Avail: 0/8682 MB (0%) D b6 State: up Device /dev/da24s1e Avail: 0/8682 MB (0%) D b7 State: up Device /dev/da25s1e Avail: 0/8682 MB (0%) D b8 State: up Device /dev/da26s1e Avail: 0/8682 MB (0%) D b9 State: up Device /dev/da27s1e Avail: 0/8682 MB (0%) D b10 State: up Device /dev/da28s1e Avail: 0/8682 MB (0%) D b11 State: up Device /dev/da29s1e Avail: 0/8682 MB (0%) D b12 State: up Device /dev/da30s1e Avail: 0/8682 MB (0%) D b13 State: up Device /dev/da31s1e Avail: 0/8682 MB (0%) 2 volumes: V mirror0 State: up Plexes: 2 Size: 3176 MB V raid01 State: up Plexes: 2 Size: 110 GB 4 plexes: P mirror0.p0 C State: up Subdisks: 1 Size: 3176 MB P mirror0.p1 C State: up Subdisks: 1 Size: 3176 MB P raid01.p0 S State: up Subdisks: 13 Size: 110 GB P raid01.p1 S State: faulty Subdisks: 13 Size: 110 GB 28 subdisks: S mirror0.p0.s0 State: up PO: 0 B Size: 3176 MB S mirror0.p1.s0 State: up PO: 0 B Size: 3176 MB S raid01.p0.s0 State: up PO: 0 B Size: 8682 MB S raid01.p0.s1 State: up PO: 512 kB Size: 8682 MB S raid01.p0.s2 State: up PO: 1024 kB Size: 8682 MB S raid01.p0.s3 State: up PO: 1536 kB Size: 8682 MB S raid01.p0.s4 State: up PO: 2048 kB Size: 8682 MB S raid01.p0.s5 State: up PO: 2560 kB Size: 8682 MB S raid01.p0.s6 State: up PO: 3072 kB Size: 8682 MB S raid01.p0.s7 State: up PO: 3584 kB Size: 8682 MB S raid01.p0.s8 State: up PO: 4096 kB Size: 8682 MB S raid01.p0.s9 State: up PO: 4608 kB Size: 8682 MB S raid01.p0.s10 State: up PO: 5120 kB Size: 8682 MB S raid01.p0.s11 State: up PO: 5632 kB Size: 8682 MB S raid01.p0.s12 State: up PO: 6144 kB Size: 8682 MB S raid01.p1.s0 State: initialized PO: 0 B Size: 8682 MB S raid01.p1.s1 State: initialized PO: 512 kB Size: 8682 MB S raid01.p1.s2 State: initialized PO: 1024 kB Size: 8682 MB S raid01.p1.s3 State: initialized PO: 1536 kB Size: 8682 MB S raid01.p1.s4 State: initialized PO: 2048 kB Size: 8682 MB S raid01.p1.s5 State: initialized PO: 2560 kB Size: 8682 MB S raid01.p1.s6 State: initialized PO: 3072 kB Size: 8682 MB S raid01.p1.s7 State: initialized PO: 3584 kB Size: 8682 MB S raid01.p1.s8 State: initialized PO: 4096 kB Size: 8682 MB S raid01.p1.s9 State: initialized PO: 4608 kB Size: 8682 MB S raid01.p1.s10 State: initialized PO: 5120 kB Size: 8682 MB S raid01.p1.s11 State: initialized PO: 5632 kB Size: 8682 MB S raid01.p1.s12 State: initialized PO: 6144 kB Size: 8682 MB remie# vinum start raid01.p1 Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s0 is reviving, not up Reviving raid01.p1.s0 in the background Reviving raid01.p1.s1 in the background Reviving raid01.p1.s2 in the background Reviving raid01.p1.s3 in the background Reviving raid01.p1.s4 in the background Reviving raid01.p1.s5 in the background Reviving raid01.p1.s6 in the background Reviving raid01.p1.s7 in the background Reviving raid01.p ERROR (81:0) (8-0-0) (1f/9f) @ (mem 8:f000ff53). sym0: regdump: da 00 00 9f 47 1f 08 03 04 08 81 00 80 00 0f 02 00 a4 25 03 02 ff ff ff. sym1:8: ERROR (81:0) (0-a7-80) (1f/9f) @ (mem 8:f000ff53). sym1: regdump: da 10 80 9f 47 1f 08 03 04 00 88 a7 80 00 07 02 00 a6 25 03 08 ff ff ff. (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. Fatal trap 12: page fault while in kernel mode mp_lock = 00000003; cpuid = 0; lapic.id = 01000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f194 stack pointer = 0x10:0xff806b28 frame pointer = 0x10:0xff806b34 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at sym_flush_comp_queue+0x1c: movl %edi,0x4(%eax) db> trace sym_flush_comp_queue(c0d7b000,e,384,c0d7b000,ff806b68) at sym_flush_comp_queue+0x1c sym_flush_busy_queue(c0d7b000,e,c0d7b000,2,3610) at sym_flush_busy_queue+0x53 sym_init(c0d7b000,1,c0235550,c0a61690,c0ec55ec) at sym_init+0xec sym_intr1(c0d7b000,ff806c04,c0210315,c0d7b000,48000040) at sym_intr1+0x119 sym_intr(c0d7b000,48000040,c0210018,c0290010,ff800010) at sym_intr+0xb Xresume16() at Xresume16+0x38 --- interrupt, eip = 0xc0225af8, esp = 0xff806be4, ebp = 0xff806c04 --- splx(c1070400,c0eb5fa0,cf,c610935c,c1043000) at splx+0x30 freerq(c1043000,c610935c,c10a4020,c0e82000,c10a4020) at freerq+0x7e complete_rqe(c10a4020,c10a4020,c0e82000,c10a7c00,c0156986) at complete_rqe+0x59e bufdone(c10a4020,ff806f84,c01289f9,c10a4020,c0e82014) at bufdone+0x55 biodone(c10a4020,c0e82014,c10a4020) at biodone+0xb dadone(c0e3a700,c10a7c00,0,0,ffffffff) at dadone+0x205 camisr(c0274c30,0,c0211493,0,ff800018) at camisr+0x1eb swi_cambio(0,ff800018,10,ffff0010,ffffffff) at swi_cambio+0xd doreti_swi() at doreti_swi+0xf db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 208 cb92aee0 ccd30000 0 89 89 000084 3 ttywri c0e7a738 syslogd 207 ccd5c920 ccd67000 0 1 192 000006 2 vinum 206 ccd5cac0 ccd64000 0 1 192 000006 3 biord c61098ec vinum 205 ccd5cc60 ccd61000 0 1 192 000006 3 biord c6109e7c vinum 204 ccd5ce00 ccd5e000 0 1 192 000006 3 biord c6108f30 vinum 203 cb929ea0 ccd56000 0 1 192 000006 3 biord c6109d18 vinum 202 cb92a040 ccd53000 0 1 192 000006 3 biord c6109788 vinum 201 cb92a1e0 ccd50000 0 1 192 000006 3 biord c6108dcc vinum 200 cb92a380 ccd4c000 0 1 192 000006 3 biord c6109094 vinum 199 cb92a520 ccd48000 0 1 192 000006 3 biord c6109bb4 vinum 198 cb92a6c0 ccd45000 0 1 192 000006 3 biord c61091f8 vinum 197 cb92a860 ccd42000 0 1 192 000006 3 biord c6109a50 vinum 196 cb92aa00 ccd3f000 0 1 192 000006 3 biord c61094c0 vinum 195 cb92aba0 ccd37000 0 1 192 000006 3 biord c6109624 vinum 185 cb92b080 ccd27000 0 1 185 004086 3 ttywai c0e7a74c csh 184 cb92b220 ccd24000 0 1 184 004086 3 ttyin c0fc8210 getty 183 cb92b3c0 ccd21000 0 1 183 004086 3 ttyin c0fc5310 getty 182 cb92b560 ccd1e000 0 1 182 004086 3 ttyin c0fc5610 getty 181 cb92b700 ccd1a000 0 1 181 004086 3 ttyin c0fc5710 getty 180 cb92b8a0 ccd17000 0 1 180 004086 3 ttyin c0fc5910 getty 179 cb92ba40 ccd14000 0 1 179 004086 3 ttyin c0fc5a10 getty 178 cb92bbe0 ccd11000 0 1 178 004086 3 ttyin c100d110 getty 177 cb92bd80 ccd0e000 0 1 177 004086 3 ttyin c0a65110 getty 176 cb92bf20 ccd0a000 65534 161 161 000184 3 accept cb801ab6 httpd 175 cb92c5a0 cccf3000 65534 161 161 000184 3 accept cb801ab6 httpd 174 cb92c260 cccfa000 65534 161 161 000184 3 accept cb801ab6 httpd 173 cb92c400 cccf7000 65534 161 161 000184 3 accept cb801ab6 httpd 172 cb92d5e0 cccc8000 65534 161 161 000184 3 accept cb801ab6 httpd 167 cb92cf60 cccd8000 0 1 167 000084 3 select c028d630 sshd1 161 cb92c0c0 ccd04000 0 1 161 000084 3 select c028d630 httpd 146 cb92d440 ccccb000 0 1 146 000084 3 select c028d630 nsrexecd 117 cb92c740 cccef000 0 1 117 2000184 3 pause cccef108 sendmail 98 cb92c8e0 ccce5000 1 1 98 000184 2 portmap 95 cb92cc20 cccdf000 0 1 95 000084 3 select c028d630 ntpd 89 cb92cdc0 cccdc000 0 1 89 000084 2 syslogd 42 cb92ca80 ccce2000 0 1 42 2000084 3 pause ccce2108 adjkerntz 39 cb92d2a0 cccd2000 0 1 39 000084 3 mfsidl cb925bc0 mount_mfs 17 cb92d100 cccd5000 0 1 17 000204 3 biowr c60fcc80 vinum 5 cb92d780 cb93a000 0 0 0 000204 3 syncer c028d5a8 syncer 4 cb92d920 cb938000 0 0 0 100204 3 psleep c0278fc0 bufdaemon 3 cb92dac0 cb936000 0 0 0 000204 3 psleep c02848a0 vmdaemon 2 cb92dc60 cb934000 0 0 0 100204 3 psleep c026b3d8 pagedaemon 1 cb92de00 cb932000 0 0 1 004284 3 wait cb92de00 init 0 c028c9a0 c02f0000 0 0 0 000204 3 sched c028c9a0 swapper db> The /var/tmp/vinum_history file doesn't say much 28 Apr 2000 16:26:42.828993 *** Created devices *** 28 Apr 2000 16:29:13.009953 *** vinum started *** 28 Apr 2000 16:29:13.010826 list 28 Apr 2000 16:29:31.623366 *** vinum started *** 28 Apr 2000 16:29:31.624173 init raid01.p1.s12 28 Apr 2000 16:29:40.365387 *** vinum started *** 28 Apr 2000 16:29:40.366247 list 28 Apr 2000 16:29:44.736436 *** vinum started *** 28 Apr 2000 16:29:44.737323 list 28 Apr 2000 16:30:07.976167 *** vinum started *** 28 Apr 2000 16:30:07.977013 list 28 Apr 2000 16:30:26.437459 *** vinum started *** 28 Apr 2000 16:30:26.438749 init raid01.p1.s11 28 Apr 2000 16:30:29.736057 *** vinum started *** 28 Apr 2000 16:30:29.738154 list 28 Apr 2000 16:30:46.081851 *** vinum started *** 28 Apr 2000 16:30:46.083944 init raid01.p1.s10 28 Apr 2000 16:30:52.755883 *** vinum started *** 28 Apr 2000 16:30:52.758210 init raid01.p1.s9 28 Apr 2000 16:30:55.668821 *** vinum started *** 28 Apr 2000 16:30:55.671033 init raid01.p1.s8 28 Apr 2000 16:30:57.444666 *** vinum started *** 28 Apr 2000 16:30:57.446780 init raid01.p1.s7 28 Apr 2000 16:30:58.764055 *** vinum started *** 28 Apr 2000 16:30:58.766224 init raid01.p1.s6 28 Apr 2000 16:31:00.019179 *** vinum started *** 28 Apr 2000 16:31:00.021637 init raid01.p1.s5 28 Apr 2000 16:31:01.305631 *** vinum started *** 28 Apr 2000 16:31:01.308699 init raid01.p1.s4 28 Apr 2000 16:31:02.507365 *** vinum started *** 28 Apr 2000 16:31:02.510444 init raid01.p1.s3 28 Apr 2000 16:31:03.773913 *** vinum started *** 28 Apr 2000 16:31:03.777102 init raid01.p1.s2 28 Apr 2000 16:31:04.869571 *** vinum started *** 28 Apr 2000 16:31:04.872345 init raid01.p1.s1 28 Apr 2000 16:31:07.645723 *** vinum started *** 28 Apr 2000 16:31:07.649611 init raid01.p1.s0 28 Apr 2000 16:31:10.554258 *** vinum started *** 28 Apr 2000 16:31:10.557767 list 28 Apr 2000 16:31:12.390798 *** vinum started *** 28 Apr 2000 16:31:12.394862 list 28 Apr 2000 16:31:14.540757 *** vinum started *** 28 Apr 2000 16:31:14.544894 list 28 Apr 2000 16:31:18.147227 *** vinum started *** 28 Apr 2000 16:31:18.150497 list 28 Apr 2000 16:31:23.528205 *** vinum started *** 28 Apr 2000 16:31:23.531344 list 28 Apr 2000 16:31:32.361464 *** vinum started *** 28 Apr 2000 16:31:32.365908 list 28 Apr 2000 16:31:40.088369 *** vinum started *** 28 Apr 2000 16:31:40.091581 list 28 Apr 2000 16:38:13.511478 *** vinum started *** 28 Apr 2000 16:38:13.515740 list 28 Apr 2000 16:39:22.130340 *** vinum started *** 28 Apr 2000 16:39:22.132851 list 28 Apr 2000 16:40:28.777395 *** vinum started *** 28 Apr 2000 16:40:28.781821 list 28 Apr 2000 16:44:31.141080 *** vinum started *** 28 Apr 2000 16:44:31.144496 list 28 Apr 2000 16:55:18.439485 *** vinum started *** 28 Apr 2000 16:55:18.442274 list 28 Apr 2000 16:55:37.009496 *** vinum started *** 28 Apr 2000 16:55:37.012238 list 28 Apr 2000 16:55:41.209519 *** vinum started *** 28 Apr 2000 16:55:41.211847 list 28 Apr 2000 16:56:00.097951 *** vinum started *** 28 Apr 2000 16:56:00.100469 list 28 Apr 2000 16:57:38.333904 *** vinum started *** 28 Apr 2000 16:57:38.334710 list 28 Apr 2000 16:57:49.088006 *** vinum started *** 28 Apr 2000 16:57:49.088815 setdaemon 0 28 Apr 2000 17:02:19.252647 *** vinum started *** 28 Apr 2000 17:02:19.261458 list 28 Apr 2000 17:02:41.611757 *** vinum started *** 28 Apr 2000 17:02:41.612555 stop raid01.p1 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 28 Apr 2000 18:16:42.285998 *** vinum started *** From /var/log/messages: Apr 28 16:23:45 remie /kernel: vinum: loaded Apr 28 16:23:45 remie /kernel: vinum: reading configuration from /dev/da2s1f Apr 28 16:23:45 remie /kernel: vinum: updating configuration from /dev/da1s1f Apr 28 16:23:45 remie /kernel: vinum: updating configuration from /dev/da22s1e Apr 28 16:23:45 remie /kernel: vinum: No space for on a1 Apr 28 16:23:45 remie /kernel: Disabling configuration updates Apr 28 16:23:45 remie /kernel: vinum: No space for on a2 Apr 28 16:23:45 remie /kernel: vinum: No space for on a3 Apr 28 16:23:45 remie /kernel: vinum: No space for on a4 Apr 28 16:23:45 remie /kernel: vinum: No space for on a5 Apr 28 16:23:45 remie /kernel: vinum: No space for on a6 Apr 28 16:23:45 remie /kernel: vinum: No space for on a7 Apr 28 16:23:45 remie /kernel: vinum: No space for on a8 Apr 28 16:23:45 remie /kernel: vinum: No space for on a9 Apr 28 16:23:45 remie /kernel: vinum: updating configuration from /dev/da21s1e Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s0 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s0 on drive a1 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s1 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s1 on drive a2 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s2 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s2 on drive a3 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s3 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s3 on drive a4 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s4 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s4 on drive a5 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s5 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s5 on drive a6 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s6 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s6 on drive a7 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s7 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s7 on drive a8 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: raid01.p0.s8 is down by force Apr 28 16:23:46 remie /kernel: vinum: No space for raid01.p0.s8 on drive a9 at offset -1 Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da18s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da19s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da20s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da17s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da14s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da15s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da16s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da10s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da11s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da12s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da13s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da7s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da8s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da9s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da5s1e Apr 28 16:23:46 remie /kernel: vinum: updating configuration from /dev/da6s1e Apr 28 16:23:46 remie /kernel: vinum: removing 3072 blocks of partial stripe at the end of raid01.p0 Apr 28 16:23:46 remie /kernel: Correcting length of raid01.p0: was 391173120, is 231146500 Apr 28 16:23:46 remie /kernel: vinum: removing 10244 blocks of partial stripe at the end of raid01.p0 Apr 28 16:23:47 remie ntpd[93]: ntpd 4.0.99b Fri Apr 28 15:31:54 CEST 2000 (1) Apr 28 16:23:47 remie ntpd[93]: using kernel phase-lock loop 2040 Apr 28 16:24:04 remie login: ROOT LOGIN (root) ON ttyd0 Apr 28 16:24:47 remie /kernel: dscheck(#da/0x2000d): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:48 remie /kernel: dscheck(#da/0x20015): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:48 remie /kernel: dscheck(#da/0x2002c): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:49 remie /kernel: dscheck(#da/0x20034): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:49 remie /kernel: dscheck(#da/0x2003c): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x20044): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x2004c): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x20054): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x2005c): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x20064): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x2006c): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x20074): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x2007c): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:50 remie /kernel: dscheck(#da/0x20084): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:51 remie /kernel: dscheck(#da/0x2008c): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:51 remie /kernel: dscheck(#da/0x20094): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:51 remie /kernel: dscheck(#da/0x2009c): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:51 remie /kernel: dscheck(#da/0x200a4): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:51 remie /kernel: dscheck(#da/0x200ac): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:51 remie /kernel: dscheck(#da/0x200b4): bio_bcount 8 is not on a sector boundary (ssize 512) Apr 28 16:24:51 remie /kernel: vinum: CONFIGURATION OBLITERATED Apr 28 16:25:00 remie /kernel: vinum: drive d1 is up Apr 28 16:25:00 remie /kernel: vinum: drive d2 is up Apr 28 16:25:00 remie /kernel: vinum: mirror0.p0.s0 is up Apr 28 16:25:01 remie /kernel: vinum: mirror0.p0 is up Apr 28 16:25:01 remie /kernel: vinum: mirror0 is up Apr 28 16:25:01 remie /kernel: vinum: mirror0.p1 is faulty Apr 28 16:26:13 remie su: ncbp to root on /dev/ttyp0 Apr 28 16:26:42 remie /kernel: vinum: drive a1 is up Apr 28 16:26:42 remie /kernel: vinum: drive a2 is up Apr 28 16:26:42 remie /kernel: vinum: drive a3 is up Apr 28 16:26:42 remie /kernel: vinum: drive a4 is up Apr 28 16:26:42 remie /kernel: vinum: drive a5 is up Apr 28 16:26:42 remie /kernel: vinum: drive a6 is up Apr 28 16:26:42 remie /kernel: vinum: drive a7 is up Apr 28 16:26:42 remie /kernel: vinum: drive a8 is up Apr 28 16:26:42 remie /kernel: vinum: drive a9 is up Apr 28 16:26:42 remie /kernel: vinum: drive a10 is up Apr 28 16:26:43 remie /kernel: vinum: drive a11 is up Apr 28 16:26:43 remie /kernel: vinum: drive a12 is up Apr 28 16:26:43 remie /kernel: vinum: drive a13 is up Apr 28 16:26:43 remie /kernel: vinum: drive hotspare is up Apr 28 16:26:43 remie /kernel: vinum: drive b1 is up Apr 28 16:26:43 remie /kernel: vinum: drive b2 is up Apr 28 16:26:43 remie /kernel: vinum: drive b3 is up Apr 28 16:26:43 remie /kernel: vinum: drive b4 is up Apr 28 16:26:43 remie /kernel: vinum: drive b5 is up Apr 28 16:26:43 remie /kernel: vinum: drive b6 is up Apr 28 16:26:43 remie /kernel: vinum: drive b7 is up Apr 28 16:26:43 remie /kernel: vinum: drive b8 is up Apr 28 16:26:43 remie /kernel: vinum: drive b9 is up Apr 28 16:26:43 remie /kernel: vinum: drive b10 is up Apr 28 16:26:44 remie /kernel: vinum: drive b11 is up Apr 28 16:26:44 remie /kernel: vinum: drive b12 is up Apr 28 16:26:44 remie /kernel: vinum: drive b13 is up Apr 28 16:26:44 remie /kernel: vinum: removing 4407 blocks of partial stripe at the end of raid01.p0 Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s0 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s1 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s2 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s3 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s4 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s5 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s6 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s7 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s8 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s9 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s10 is up Apr 28 16:26:44 remie /kernel: vinum: raid01.p0.s11 is up Apr 28 16:26:45 remie /kernel: vinum: raid01.p0.s12 is up Apr 28 16:26:45 remie /kernel: vinum: raid01.p0 is up Apr 28 16:26:45 remie /kernel: vinum: raid01 is up Apr 28 16:26:45 remie /kernel: vinum: removing 4407 blocks of partial stripe at the end of raid01.p1 Apr 28 16:26:45 remie /kernel: vinum: raid01.p1 is faulty Apr 28 16:29:10 remie su: ncbp to root on /dev/ttyp0 Apr 28 16:29:31 remie /kernel: vinum: raid01.p1.s12 is initializing by force Apr 28 16:29:31 remie /kernel: vinum: raid01.p1 is initializing Apr 28 16:30:26 remie /kernel: vinum: raid01.p1.s11 is initializing by force Apr 28 16:30:46 remie /kernel: vinum: raid01.p1.s10 is initializing by force Apr 28 16:30:52 remie /kernel: vinum: raid01.p1.s9 is initializing by force Apr 28 16:30:55 remie /kernel: vinum: raid01.p1.s8 is initializing by force Apr 28 16:30:57 remie /kernel: vinum: raid01.p1.s7 is initializing by force Apr 28 16:30:58 remie /kernel: vinum: raid01.p1.s6 is initializing by force Apr 28 16:31:00 remie /kernel: vinum: raid01.p1.s5 is initializing by force Apr 28 16:31:01 remie /kernel: vinum: raid01.p1.s4 is initializing by force Apr 28 16:31:02 remie /kernel: vinum: raid01.p1.s3 is initializing by force Apr 28 16:31:03 remie /kernel: vinum: raid01.p1.s2 is initializing by force Apr 28 16:31:04 remie /kernel: vinum: raid01.p1.s1 is initializing by force Apr 28 16:31:07 remie /kernel: vinum: raid01.p1.s0 is initializing by force Apr 28 16:49:38 remie /kernel: vinum: raid01.p1.s1 is initialized by force Apr 28 16:49:38 remie /kernel: vinum: raid01.p1.s1 is initialized Apr 28 16:49:41 remie /kernel: vinum: raid01.p1.s3 is initialized by force Apr 28 16:49:41 remie /kernel: vinum: raid01.p1.s3 is initialized Apr 28 16:49:43 remie /kernel: vinum: raid01.p1.s0 is initialized by force Apr 28 16:49:43 remie /kernel: vinum: raid01.p1.s0 is initialized Apr 28 16:49:45 remie /kernel: vinum: raid01.p1.s2 is initialized by force Apr 28 16:49:45 remie /kernel: vinum: raid01.p1.s2 is initialized Apr 28 16:52:14 remie /kernel: vinum: raid01.p1.s12 is initialized by force Apr 28 16:52:14 remie /kernel: vinum: raid01.p1.s12 is initialized Apr 28 16:55:42 remie /kernel: vinum: raid01.p1.s11 is initialized by force Apr 28 16:55:42 remie /kernel: vinum: raid01.p1.s11 is initialized Apr 28 16:56:20 remie /kernel: vinum: raid01.p1.s10 is initialized by force Apr 28 16:56:20 remie /kernel: vinum: raid01.p1.s10 is initialized Apr 28 16:56:35 remie /kernel: vinum: raid01.p1.s9 is initialized by force Apr 28 16:56:35 remie /kernel: vinum: raid01.p1.s9 is initialized Apr 28 16:56:42 remie /kernel: vinum: raid01.p1.s8 is initialized by force Apr 28 16:56:42 remie /kernel: vinum: raid01.p1.s8 is initialized Apr 28 16:56:45 remie /kernel: vinum: raid01.p1.s7 is initialized by force Apr 28 16:56:45 remie /kernel: vinum: raid01.p1.s7 is initialized Apr 28 16:56:47 remie /kernel: vinum: raid01.p1.s6 is initialized by force Apr 28 16:56:47 remie /kernel: vinum: raid01.p1.s6 is initialized Apr 28 16:56:51 remie /kernel: vinum: raid01.p1.s5 is initialized by force Apr 28 16:56:51 remie /kernel: vinum: raid01.p1.s5 is initialized Apr 28 16:56:53 remie /kernel: vinum: raid01.p1.s4 is initialized by force Apr 28 16:56:53 remie /kernel: vinum: raid01.p1 is faulty Apr 28 16:56:54 remie /kernel: vinum: raid01.p1.s4 is initialized Apr 28 16:58:03 remie login: ROOT LOGIN (root) ON ttyd0 Apr 28 16:58:23 remie shutdown: reboot by root: Apr 28 16:58:25 remie syslogd: exiting on signal 15 Apr 28 17:01:03 remie /kernel: Copyright (c) 1992-2000 The FreeBSD Project. Apr 28 17:01:03 remie /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 Apr 28 17:01:03 remie /kernel: The Regents of the University of California. All rights reserved. Apr 28 17:01:03 remie /kernel: FreeBSD 5.0-CURRENT #0: Fri Apr 28 15:00:52 CEST 2000 Apr 28 17:01:03 remie /kernel: root@remie.nms.tele.dk:/usr/src/sys/compile/REMIE Apr 28 17:01:03 remie /kernel: Timecounter "i8254" frequency 1193182 Hz Apr 28 17:01:03 remie /kernel: CPU: Pentium III/Pentium III Xeon (496.66-MHz 686-class CPU) Apr 28 17:01:03 remie /kernel: Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Apr 28 17:01:03 remie /kernel: Features=0x387fbff Apr 28 17:01:03 remie /kernel: real memory = 268369920 (262080K bytes) Apr 28 17:01:03 remie /kernel: config> q Apr 28 17:01:03 remie /kernel: avail memory = 258080768 (252032K bytes) Apr 28 17:01:03 remie /kernel: Programming 24 pins in IOAPIC #0 Apr 28 17:01:03 remie /kernel: IOAPIC #0 intpin 2 -> irq 0 Apr 28 17:01:03 remie /kernel: FreeBSD/SMP: Multiprocessor motherboard Apr 28 17:01:03 remie /kernel: cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 Apr 28 17:01:03 remie /kernel: cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 Apr 28 17:01:03 remie /kernel: io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Apr 28 17:01:03 remie /kernel: Preloaded elf kernel "kernel" at 0xc02dd000. Apr 28 17:01:03 remie /kernel: Preloaded userconfig_script "/boot/kernel.conf" at 0xc02dd09c. Apr 28 17:01:03 remie /kernel: Pentium Pro MTRR support enabled Apr 28 17:01:03 remie /kernel: md0: Malloc disk Apr 28 17:01:03 remie /kernel: npx0: on motherboard Apr 28 17:01:03 remie /kernel: npx0: INT 16 interface Apr 28 17:01:03 remie /kernel: pcib0: on motherboard Apr 28 17:01:03 remie /kernel: pci0: on pcib0 Apr 28 17:01:03 remie /kernel: sym0: <895> port 0x1400-0x14ff mem 0xfa100000-0xfa100fff,0xfa106000-0xfa1060ff irq 16 at device 11.0 on pci0 Apr 28 17:01:03 remie /kernel: sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking Apr 28 17:01:03 remie /kernel: sym1: <895> port 0x1800-0x18ff mem 0xfa101000-0xfa101fff,0xfa106400-0xfa1064ff irq 17 at device 12.0 on pci0 Apr 28 17:01:03 remie /kernel: sym1: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking Apr 28 17:01:03 remie /kernel: sym2: <875> port 0x2000-0x20ff mem 0xfa102000-0xfa102fff,0xfa106800-0xfa1068ff irq 21 at device 13.0 on pci0 Apr 28 17:01:03 remie /kernel: sym2: No NVRAM, ID 7, Fast-20, SE, parity checking Apr 28 17:01:03 remie /kernel: sym3: <875> port 0x2400-0x24ff mem 0xfa103000-0xfa103fff,0xfa106c00-0xfa106cff irq 22 at device 13.1 on pci0 Apr 28 17:01:03 remie /kernel: sym3: No NVRAM, ID 7, Fast-20, SE, parity checking Apr 28 17:01:03 remie /kernel: sym4: <895> port 0x2800-0x28ff mem 0xfa104000-0xfa104fff,0xfa107000-0xfa1070ff irq 18 at device 14.0 on pci0 Apr 28 17:01:03 remie /kernel: sym4: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking Apr 28 17:01:03 remie /kernel: fxp0: port 0x1060-0x107f mem 0xfa000000-0xfa0fffff,0xfa108000-0xfa108fff irq 20 at device 15.0 on pci0 Apr 28 17:01:03 remie /kernel: fxp0: Ethernet address 00:a0:c9:d3:53:19 Apr 28 17:01:03 remie /kernel: isab0: at device 18.0 on pci0 Apr 28 17:01:03 remie /kernel: isa0: on isab0 Apr 28 17:01:03 remie /kernel: pci0: at 18.1 Apr 28 17:01:03 remie /kernel: pci0: at 18.2 irq 22 Apr 28 17:01:03 remie /kernel: Timecounter "PIIX" frequency 3579545 Hz Apr 28 17:01:03 remie /kernel: chip1: port 0x1040-0x104f at device 18.3 on pci0 Apr 28 17:01:03 remie /kernel: pci0: at 20.0 Apr 28 17:01:04 remie /kernel: fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 Apr 28 17:01:04 remie /kernel: fdc0: FIFO enabled, 8 bytes threshold Apr 28 17:01:04 remie /kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Apr 28 17:01:04 remie /kernel: atkbdc0: at port 0x60,0x64 on isa0 Apr 28 17:01:04 remie /kernel: atkbd0: irq 1 on atkbdc0 Apr 28 17:01:04 remie /kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Apr 28 17:01:04 remie /kernel: sc0: on isa0 Apr 28 17:01:04 remie /kernel: sc0: VGA <16 virtual consoles, flags=0x0> Apr 28 17:01:04 remie /kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Apr 28 17:01:04 remie /kernel: sio0: type 16550A, console Apr 28 17:01:04 remie /kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Apr 28 17:01:04 remie /kernel: sio1: type 16550A Apr 28 17:01:04 remie /kernel: unknown0: at port 0x80,0xc00-0xc3f,0xca0-0xca3,0xca8-0xcaf iomem 0xfff00000-0xffffffff on isa0 Apr 28 17:01:04 remie /kernel: unknown1: at port 0x10-0x1f,0x24-0x25,0x28-0x29,0x2c-0x2f,0x30-0x31,0x34-0x35,0x38-0x39,0x3c-0x3d,0x50-0x53,0x63,0x65,0x67,0x72-0x7f,0x90-0x9f,0xa4-0xa5,0xa8-0xa9,0xac-0xad,0xb0-0xb5,0xb8-0xb9,0xbc-0xbd on isa0 Apr 28 17:01:04 remie /kernel: unknown2: at iomem 0-0x9ffff,0xe8000-0xfffff,0x100000-0xfffffff on isa0 Apr 28 17:01:04 remie /kernel: unknown3: at port 0-0xf,0x81-0x8f,0xc0-0xdf drq 4 on isa0 Apr 28 17:01:04 remie /kernel: unknown4: at port 0x20-0x21,0xa0-0xa1 irq 2 on isa0 Apr 28 17:01:04 remie /kernel: unknown5: at port 0x40-0x43 irq 0 on isa0 Apr 28 17:01:04 remie /kernel: unknown6: at port 0x70-0x71 irq 8 on isa0 Apr 28 17:01:04 remie /kernel: unknown: can't assign resources Apr 28 17:01:04 remie /kernel: unknown7: at port 0xf0-0xff irq 13 on isa0 Apr 28 17:01:04 remie /kernel: unknown8: at port 0x61 on isa0 Apr 28 17:01:04 remie /kernel: unknown9: at port 0xcf8-0xcff on isa0 Apr 28 17:01:04 remie /kernel: unknown10: at port 0x4d0-0x4d1,0x1000-0x103f,0x1040-0x104f on isa0 Apr 28 17:01:04 remie /kernel: unknown11: at iomem 0xfec00000-0xfec0ffff,0xfee00000-0xfee00fff on isa0 Apr 28 17:01:04 remie /kernel: unknown12: at iomem 0xcca00-0xcffff on isa0 Apr 28 17:01:04 remie /kernel: unknown: can't assign resources Apr 28 17:01:04 remie /kernel: unknown13: at irq 12 on isa0 Apr 28 17:01:04 remie /kernel: unknown: can't assign resources Apr 28 17:01:04 remie /kernel: unknown: can't assign resources Apr 28 17:01:04 remie /kernel: unknown14: at port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on isa0 Apr 28 17:01:04 remie /kernel: APIC_IO: Testing 8254 interrupt delivery Apr 28 17:01:04 remie /kernel: APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Apr 28 17:01:04 remie /kernel: Waiting 15 seconds for SCSI devices to settle Apr 28 17:01:04 remie /kernel: SMP: AP CPU #1 Launched! Apr 28 17:01:04 remie /kernel: da5 at sym0 bus 0 target 0 lun 0 Apr 28 17:01:04 remie /kernel: da5: Fixed Direct Access SCSI-3 device Apr 28 17:01:04 remie /kernel: da5: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:04 remie /kernel: da5: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:04 remie /kernel: da6 at sym0 bus 0 target 1 lun 0 Apr 28 17:01:04 remie /kernel: da6: Fixed Direct Access SCSI-3 device Apr 28 17:01:04 remie /kernel: da6: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:04 remie /kernel: da6: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:04 remie /kernel: da7 at sym0 bus 0 target 2 lun 0 Apr 28 17:01:04 remie /kernel: da7: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da7: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da7: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da8 at sym0 bus 0 target 3 lun 0 Apr 28 17:01:05 remie /kernel: da8: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da8: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da8: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da14 at sym1 bus 0 target 0 lun 0 Apr 28 17:01:05 remie /kernel: da14: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da14: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da14: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da15 at sym1 bus 0 target 1 lun 0 Apr 28 17:01:05 remie /kernel: da15: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da15: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da15: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da23 at sym4 bus 0 target 0 lun 0 Apr 28 17:01:05 remie /kernel: da23: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da23: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da23: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da4 at sym2 bus 0 target 4 lun 0 Apr 28 17:01:05 remie /kernel: da4: Fixed Direct Access SCSI-2 device Apr 28 17:01:05 remie /kernel: da4: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da4: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) Apr 28 17:01:05 remie /kernel: da16 at sym1 bus 0 target 2 lun 0 Apr 28 17:01:05 remie /kernel: da16: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da16: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da16: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da24 at sym4 bus 0 target 1 lun 0 Apr 28 17:01:05 remie /kernel: da24: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da24: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da24: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da17 at sym1 bus 0 target 3 lun 0 Apr 28 17:01:05 remie /kernel: da17: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da17: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da17: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da9 at sym0 bus 0 target 4 lun 0 Apr 28 17:01:05 remie /kernel: da9: Fixed Direct Access SCSI-3 device Apr 28 17:01:05 remie /kernel: da9: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da9: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:05 remie /kernel: da3 at sym2 bus 0 target 3 lun 0 Apr 28 17:01:05 remie /kernel: da3: Fixed Direct Access SCSI-2 device Apr 28 17:01:05 remie /kernel: da3: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled Apr 28 17:01:05 remie /kernel: da3: 2048MB (4194995 512 byte sectors: 255H 63S/T 261C) Apr 28 17:01:05 remie /kernel: da10 at sym0 bus 0 target 5 lun 0 Apr 28 17:01:05 remie /kernel: da10: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da10: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da10: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da25 at sym4 bus 0 target 2 lun 0 Apr 28 17:01:06 remie /kernel: da25: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da25: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da25: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da18 at sym1 bus 0 target 4 lun 0 Apr 28 17:01:06 remie /kernel: da18: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da18: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da18: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da26 at sym4 bus 0 target 3 lun 0 Apr 28 17:01:06 remie /kernel: da26: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da26: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da26: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da19 at sym1 bus 0 target 5 lun 0 Apr 28 17:01:06 remie /kernel: da19: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da19: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da19: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da11 at sym0 bus 0 target 6 lun 0 Apr 28 17:01:06 remie /kernel: da11: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da11: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da11: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da12 at sym0 bus 0 target 8 lun 0 Apr 28 17:01:06 remie /kernel: da12: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da12: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da12: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da27 at sym4 bus 0 target 4 lun 0 Apr 28 17:01:06 remie /kernel: da27: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da27: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da27: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da20 at sym1 bus 0 target 6 lun 0 Apr 28 17:01:06 remie /kernel: da20: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da20: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da20: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da28 at sym4 bus 0 target 5 lun 0 Apr 28 17:01:06 remie /kernel: da28: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da28: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da28: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da13 at sym0 bus 0 target 9 lun 0 Apr 28 17:01:06 remie /kernel: da13: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da13: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:06 remie /kernel: da13: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:06 remie /kernel: da21 at sym1 bus 0 target 8 lun 0 Apr 28 17:01:06 remie /kernel: da21: Fixed Direct Access SCSI-3 device Apr 28 17:01:06 remie /kernel: da21: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:07 remie /kernel: da21: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:07 remie /kernel: da29 at sym4 bus 0 target 6 lun 0 Apr 28 17:01:07 remie /kernel: da29: Fixed Direct Access SCSI-3 device Apr 28 17:01:07 remie /kernel: da29: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:07 remie /kernel: da29: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:07 remie /kernel: da22 at sym1 bus 0 target 9 lun 0 Apr 28 17:01:07 remie /kernel: da22: Fixed Direct Access SCSI-3 device Apr 28 17:01:07 remie /kernel: da22: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:07 remie /kernel: da22: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:07 remie /kernel: da30 at sym4 bus 0 target 8 lun 0 Apr 28 17:01:07 remie /kernel: da30: Fixed Direct Access SCSI-3 device Apr 28 17:01:07 remie /kernel: da30: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:07 remie /kernel: da30: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:07 remie /kernel: da31 at sym4 bus 0 target 9 lun 0 Apr 28 17:01:07 remie /kernel: da31: Fixed Direct Access SCSI-3 device Apr 28 17:01:07 remie /kernel: da31: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Apr 28 17:01:07 remie /kernel: da31: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Apr 28 17:01:07 remie /kernel: da2 at sym3 bus 0 target 2 lun 0 Apr 28 17:01:07 remie /kernel: da2: Fixed Direct Access SCSI-2 device Apr 28 17:01:07 remie /kernel: da2: 20.000MB/s transfers (20.000MHz, offset 15) Apr 28 17:01:07 remie /kernel: da2: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Apr 28 17:01:07 remie /kernel: da1 at sym3 bus 0 target 1 lun 0 Apr 28 17:01:07 remie /kernel: da1: Fixed Direct Access SCSI-2 device Apr 28 17:01:07 remie /kernel: da1: 20.000MB/s transfers (20.000MHz, offset 15) Apr 28 17:01:07 remie /kernel: da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Apr 28 17:01:07 remie /kernel: da0 at sym3 bus 0 target 0 lun 0 Apr 28 17:01:07 remie /kernel: da0: Fixed Direct Access SCSI-2 device Apr 28 17:01:07 remie /kernel: da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled Apr 28 17:01:07 remie /kernel: da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) Apr 28 17:01:07 remie /kernel: cd0 at sym3 bus 0 target 3 lun 0 Apr 28 17:01:07 remie /kernel: cd0: Removable CD-ROM SCSI-2 device Apr 28 17:01:07 remie /kernel: cd0: 5.000MB/s transfers (5.000MHz, offset 15) Apr 28 17:01:07 remie /kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Apr 28 17:01:07 remie /kernel: Mounting root from ufs:/dev/da0s1a Apr 28 17:01:07 remie /kernel: vinum: loaded Apr 28 17:01:07 remie /kernel: vinum: reading configuration from /dev/da31s1e Apr 28 17:01:07 remie /kernel: vinum: updating configuration from /dev/da30s1e Apr 28 17:01:07 remie /kernel: vinum: updating configuration from /dev/da27s1e Apr 28 17:01:07 remie /kernel: vinum: updating configuration from /dev/da29s1e Apr 28 17:01:07 remie /kernel: vinum: updating configuration from /dev/da28s1e Apr 28 17:01:07 remie /kernel: vinum: updating configuration from /dev/da24s1e Apr 28 17:01:07 remie /kernel: vinum: updating configuration from /dev/da26s1e Apr 28 17:01:07 remie /kernel: vinum: updating configuration from /dev/da25s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da23s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da21s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da22s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da20s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da17s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da16s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da18s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da19s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da13s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da15s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da14s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da12s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da10s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da11s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da9s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da5s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da8s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da7s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da6s1e Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da2s1f Apr 28 17:01:08 remie /kernel: vinum: updating configuration from /dev/da1s1f Apr 28 17:01:10 remie ntpd[95]: ntpd 4.0.99b Fri Apr 28 15:31:54 CEST 2000 (1) Apr 28 17:01:10 remie ntpd[95]: using kernel phase-lock loop 2040 Apr 28 17:01:39 remie login: ROOT LOGIN (root) ON ttyd0 Apr 28 17:02:41 remie /kernel: vinum: raid01.p1 is down Apr 28 17:02:58 remie /kernel: vinum: raid01.p1 is faulty Apr 28 17:02:58 remie /kernel: vinum: raid01.p1 is faulty Apr 28 17:02:58 remie /kernel: vinum: raid01.p1.s0 is reviving, not up Apr 28 17:02:58 remie /kernel: vinum: raid01.p1.s1 is reviving, not up Apr 28 17:02:58 remie /kernel: vinum: raid01.p1.s2 is reviving, not up Apr 28 17:02:58 remie /kernel: vinum: raid01.p1.s3 is reviving, not up Apr 28 17:02:58 remie /kernel: vinum: raid01.p1.s4 is reviving, not up ** crashed here ** ** removed redundant dmesg ** Apr 28 17:23:42 remie /kernel: Mounting root from ufs:/dev/da0s1a Apr 28 17:23:42 remie /kernel: WARNING: / was not properly dismounted Apr 28 17:23:42 remie /kernel: vinum: loaded Apr 28 17:23:42 remie /kernel: vinum: reading configuration from /dev/da6s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da5s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da2s1f Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da1s1f Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da31s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da29s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da30s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da28s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da25s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da26s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da27s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da24s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da22s1e Apr 28 17:23:42 remie /kernel: vinum: updating configuration from /dev/da23s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da21s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da18s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da19s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da20s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da14s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da15s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da16s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da17s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da11s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da12s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da13s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da9s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da7s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da8s1e Apr 28 17:23:43 remie /kernel: vinum: updating configuration from /dev/da10s1e Apr 28 17:23:45 remie ntpd[95]: ntpd 4.0.99b Fri Apr 28 15:31:54 CEST 2000 (1) Apr 28 17:23:45 remie ntpd[95]: using kernel phase-lock loop 2040 Apr 28 17:23:59 remie login: ROOT LOGIN (root) ON ttyd0 Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s0 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s1 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s2 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s3 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s4 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s5 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s6 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s7 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s8 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s9 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s10 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s11 is reviving, not up Apr 28 17:24:27 remie /kernel: vinum: raid01.p1.s12 is reviving, not up ** crashed again ** /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 9:53:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from lightship.internal.homeport.org (breakwater.homeport.org [216.67.13.2]) by hub.freebsd.org (Postfix) with ESMTP id 7F3D437B804; Fri, 28 Apr 2000 09:53:05 -0700 (PDT) (envelope-from shevett@stonekeep.com) Received: from localhost (shevett@localhost) by lightship.internal.homeport.org (8.9.3/8.9.3) with ESMTP id QAA02438; Fri, 28 Apr 2000 16:54:32 -0400 (EDT) (envelope-from shevett@stonekeep.com) X-Authentication-Warning: lightship.internal.homeport.org: shevett owned process doing -bs Date: Fri, 28 Apr 2000 16:54:32 -0400 (EDT) From: Dave Belfer-Shevett X-Sender: shevett@localhost To: Warner Losh Cc: jflowers@ezo.net, freebsd-mobile@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Problems configuring Vadem VG-469 PCMCIA controller. In-Reply-To: <200004272001.OAA53736@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Warner Losh wrote: > Add the vendor ID to pccard/pcic.c: > static struct isa_pnp_id pcic_ids[] = { > {PCIC_PNP_82365, NULL}, /* PNP0E00 */ > {PCIC_PNP_CL_PD6720, NULL}, /* PNP0E01 */ > {PCIC_PNP_VLSI_82C146, NULL}, /* PNP0E02 */ > {PCIC_PNP_82365_CARDBUS, NULL}, /* PNP0E03 */ > {0} > }; Thanks to the wonders of Mr Bill Paul and others, we are up and running beautifully. Changing that structure to: static struct isa_pnp_id pcic_ids[] = { {PCIC_PNP_82365, NULL}, /* PNP0E00 */ {PCIC_PNP_CL_PD6720, NULL}, /* PNP0E01 */ {PCIC_PNP_VLSI_82C146, NULL}, /* PNP0E02 */ {PCIC_PNP_82365_CARDBUS, NULL}, /* PNP0E03 */ {0x1802a904, NULL}, {0} }; has fixed the problem. Note that that identifier is what pnpinfo reported: Logical Device ID: AEI0218 0x1802a904 #0 Vendor register funcs 00 I/O Range 0x3e0 .. 0x3fe, alignment 0x2, len 0x2 [16-bit addr] End Tag Since we knew the controller was the same as the others (the Vadem), just adding that ID fixed thinks up. Thanks to everyone who answered, and specially to Bill who a) wrote the driver, and b) debugged the problem with me. dave -------------------. Web-based problem management: www.stonekeep.com Dave Belfer-Shevett >----------------------------------------------------. shevett@pobox.com / "I've never had major knee surgery on any other part \ ------------------< of my body." (Winston Bennett, University of | | Kentucky basketball forward) | \______________________________________________________/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 10:18:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [149.173.1.1]) by hub.freebsd.org (Postfix) with ESMTP id A81C037BF67; Fri, 28 Apr 2000 10:18:29 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [149.173.6.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id NAA01822; Fri, 28 Apr 2000 13:18:27 -0400 (EDT) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AB25101; Fri, 28 Apr 2000 13:17:56 -0400 Received: from localhost (brdean@localhost) by dean.pc.sas.com (8.9.3/8.9.1) with ESMTP id NAA82885; Fri, 28 Apr 2000 13:17:56 -0400 (EDT) (envelope-from brdean@dean.pc.sas.com) Date: Fri, 28 Apr 2000 13:17:56 -0400 (EDT) From: Brian Dean To: "David O'Brien" Cc: Chuck Robey , FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <20000424185151.A36672@hub.freebsd.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, David O'Brien wrote: > I've often traced files back to the begining of FreeBSD time (and then > continued in the CSRG SCCS tree). ^^^^^^^^^^^^^^ I've wanted to do this on occasion. Where are these pre-FreeBSD history records available? -Brian -- Brian Dean brdean@unx.sas.com SAS Institute Inc. bsd@FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 10:21:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id B9B9037BF45 for ; Fri, 28 Apr 2000 10:21:22 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA53718; Fri, 28 Apr 2000 13:21:20 -0400 (EDT) (envelope-from wollman) Date: Fri, 28 Apr 2000 13:21:20 -0400 (EDT) From: Garrett Wollman Message-Id: <200004281721.NAA53718@khavrinen.lcs.mit.edu> To: Brian Dean Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: References: <20000424185151.A36672@hub.freebsd.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > I've wanted to do this on occasion. Where are these pre-FreeBSD > history records available? You can buy them on CD-ROM, IIRC. In order to do so, however, you must first take out a SCO ``Historical UNIX Versions'' personal license. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 10:25: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 477FA37BF60 for ; Fri, 28 Apr 2000 10:24:59 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@c01-175.006.popsite.net [216.126.134.175]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id KAA60038; Fri, 28 Apr 2000 10:24:57 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id KAA03175; Fri, 28 Apr 2000 10:24:54 -0700 (PDT) (envelope-from obrien) Date: Fri, 28 Apr 2000 10:24:54 -0700 From: "David O'Brien" To: Brian Dean Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000428102453.B1594@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20000424185151.A36672@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from brdean@unx.sas.com on Fri, Apr 28, 2000 at 01:17:56PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 28, 2000 at 01:17:56PM -0400, Brian Dean wrote: > > I've often traced files back to the begining of FreeBSD time (and then > > continued in the CSRG SCCS tree). > > I've wanted to do this on occasion. Where are these pre-FreeBSD > history records available? Glad you asked. http://www.mckusick.com/csrg/index.html -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 10:57: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 2175C37B558; Fri, 28 Apr 2000 10:56:59 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: from shell-1.enteract.com (dscheidt@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id MAA73199; Fri, 28 Apr 2000 12:56:58 -0500 (CDT) (envelope-from dscheidt@enteract.com) Date: Fri, 28 Apr 2000 12:56:58 -0500 (CDT) From: David Scheidt To: "David O'Brien" Cc: Brian Dean , FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <20000428102453.B1594@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 28 Apr 2000, David O'Brien wrote: > On Fri, Apr 28, 2000 at 01:17:56PM -0400, Brian Dean wrote: > > > I've often traced files back to the begining of FreeBSD time (and then > > > continued in the CSRG SCCS tree). > > > > I've wanted to do this on occasion. Where are these pre-FreeBSD > > history records available? > > Glad you asked. http://www.mckusick.com/csrg/index.html Not incidently, SCO have waived the $100 license application fee, which means that you can get your own official Ancient UNIX(TM) Source Code License for free. This roughly cuts in half the cost of the disks for someone not covered under a orginizaitonal souce code license. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 12:47:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from goku.cl.msu.edu (goku.cl.msu.edu [35.8.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 7CA7937B68D for ; Fri, 28 Apr 2000 12:47:07 -0700 (PDT) (envelope-from dervish@goku.cl.msu.edu) Received: (from dervish@localhost) by goku.cl.msu.edu (8.9.3/8.9.3) id PAA46199; Fri, 28 Apr 2000 15:47:01 -0400 (EDT) (envelope-from dervish) Date: Fri, 28 Apr 2000 15:47:01 -0400 From: Bush Doctor To: David Scheidt Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000428154701.A46090@goku.cl.msu.edu> References: <20000428102453.B1594@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from dscheidt@enteract.com on Fri, Apr 28, 2000 at 12:56:58PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT i386 WWW-Home-Page: http://bantu.cl.msu.edu Organisation: Fraternal Order of Whipped Husbands -- (F.O.O.W.H.) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Out of da blue David Scheidt aka (dscheidt@enteract.com) said: > On Fri, 28 Apr 2000, David O'Brien wrote: > > > On Fri, Apr 28, 2000 at 01:17:56PM -0400, Brian Dean wrote: > > > > I've often traced files back to the begining of FreeBSD time (and then > > > > continued in the CSRG SCCS tree). > > > > > > I've wanted to do this on occasion. Where are these pre-FreeBSD > > > history records available? > > > > Glad you asked. http://www.mckusick.com/csrg/index.html > > Not incidently, SCO have waived the $100 license application fee, which > means that you can get your own official Ancient UNIX(TM) Source Code > License for free. This roughly cuts in half the cost of the disks for > someone not covered under a orginizaitonal souce code license. Is there a new license form to sign or do we just fill out the current form without sending the applicateion fee? > > > David Scheidt > > > #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 13:26:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id B1CB737B54D for ; Fri, 28 Apr 2000 13:26:13 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: from shell-1.enteract.com (dscheidt@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id PAA37119; Fri, 28 Apr 2000 15:26:09 -0500 (CDT) (envelope-from dscheidt@enteract.com) Date: Fri, 28 Apr 2000 15:26:05 -0500 (CDT) From: David Scheidt To: Bush Doctor Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning In-Reply-To: <20000428154701.A46090@goku.cl.msu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 28 Apr 2000, Bush Doctor wrote: > Out of da blue David Scheidt aka (dscheidt@enteract.com) said: > > > > Not incidently, SCO have waived the $100 license application fee, which > > means that you can get your own official Ancient UNIX(TM) Source Code > > License for free. This roughly cuts in half the cost of the disks for > > someone not covered under a orginizaitonal souce code license. > Is there a new license form to sign or do we just fill out the current > form without sending the applicateion fee? > I don't know. SCO just made the announcement a week or two ago -- the same time they BSD licensed cscope -- and don't appear to have made changes to their web site yet. The press release is at http://www.sco.com/press/releases/2000/6927.html It might be worthwhile to attempt to contact the contact name on the release. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 13:51:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from goku.cl.msu.edu (goku.cl.msu.edu [35.8.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 3DFA937B506 for ; Fri, 28 Apr 2000 13:51:09 -0700 (PDT) (envelope-from dervish@goku.cl.msu.edu) Received: (from dervish@localhost) by goku.cl.msu.edu (8.9.3/8.9.3) id QAA76473; Fri, 28 Apr 2000 16:50:59 -0400 (EDT) (envelope-from dervish) Date: Fri, 28 Apr 2000 16:50:59 -0400 From: Bush Doctor To: David Scheidt Cc: Bush Doctor , FreeBSD-current@FreeBSD.ORG Subject: Re: Archive pruning Message-ID: <20000428165059.A61707@goku.cl.msu.edu> References: <20000428154701.A46090@goku.cl.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from dscheidt@enteract.com on Fri, Apr 28, 2000 at 03:26:05PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT i386 WWW-Home-Page: http://bantu.cl.msu.edu Organisation: Fraternal Order of Whipped Husbands -- (F.O.O.W.H.) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Out of da blue David Scheidt aka (dscheidt@enteract.com) said: > On Fri, 28 Apr 2000, Bush Doctor wrote: > > > Out of da blue David Scheidt aka (dscheidt@enteract.com) said: > > > > > > Not incidently, SCO have waived the $100 license application fee, which > > > means that you can get your own official Ancient UNIX(TM) Source Code > > > License for free. This roughly cuts in half the cost of the disks for > > > someone not covered under a orginizaitonal souce code license. > > Is there a new license form to sign or do we just fill out the current > > form without sending the applicateion fee? > > > > I don't know. SCO just made the announcement a week or two ago -- the same > time they BSD licensed cscope -- and don't appear to have made changes to > their web site yet. > > The press release is at http://www.sco.com/press/releases/2000/6927.html > It might be worthwhile to attempt to contact the contact name on the > release. Thanxs, I'll do that. > > David > > #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 13:56:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 696B537B72D for ; Fri, 28 Apr 2000 13:56:28 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id QAA65554; Fri, 28 Apr 2000 16:56:15 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200004281721.NAA53718@khavrinen.lcs.mit.edu> References: <20000424185151.A36672@hub.freebsd.org> <200004281721.NAA53718@khavrinen.lcs.mit.edu> Date: Fri, 28 Apr 2000 16:56:18 -0400 To: Garrett Wollman , Brian Dean From: Garance A Drosihn Subject: Re: Archive pruning Cc: FreeBSD-current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:21 PM -0400 4/28/00, Garrett Wollman wrote: >< said: > > > I've wanted to do this on occasion. Where are these pre-FreeBSD > > history records available? > >You can buy them on CD-ROM, IIRC. In order to do so, however, you >must first take out a SCO ``Historical UNIX Versions'' personal >license. I don't think that's needed anymore. Check out http://www.sco.com/press/releases/2000/6927.html --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 14:23: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 227C337B939 for ; Fri, 28 Apr 2000 14:23:04 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac6.wam.umd.edu (root@rac6.wam.umd.edu [128.8.10.146]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id QAA09168 for ; Fri, 28 Apr 2000 16:51:53 -0400 (EDT) Received: from rac6.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac6.wam.umd.edu (8.9.3/8.9.3) with SMTP id QAA03778 for ; Fri, 28 Apr 2000 16:51:45 -0400 (EDT) Received: from localhost (culverk@localhost) by rac6.wam.umd.edu (8.9.3/8.9.3) with ESMTP id QAA03770 for ; Fri, 28 Apr 2000 16:51:44 -0400 (EDT) X-Authentication-Warning: rac6.wam.umd.edu: culverk owned process doing -bs Date: Fri, 28 Apr 2000 16:51:43 -0400 (EDT) From: Kenneth Wayne Culver To: freebsd-current@freebsd.org Subject: sound Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just to let someone know (I know this is -current) but some of the recent changes to the pcm driver have had some wierd effects. First, no wav file will completely play (at least not the short ones); second, xmms now takes 100% cpu, and in top, it says that 76% of this is being used by the "system" Again, just to let someone know. Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 14:23:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 95B4E37BFEB for ; Fri, 28 Apr 2000 14:23:48 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA02417 for ; Fri, 28 Apr 2000 23:23:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: PATCH: buf/bio conversion From: Poul-Henning Kamp Date: Fri, 28 Apr 2000 23:23:46 +0200 Message-ID: <2415.956957026@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Two new patches at http://phk.freebsd.dk/misc 2000-04-28 biodone.patch This patch untangles the biodone/bufdone path. This basically gives struct bio a separate mechanism for callbacks, which at the end calls into the struct buf mechanism. 2000-04-28 ccd.patch (Requires biodone.patch) Convert CCD to struct bio. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 16:25: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id B378737B723 for ; Fri, 28 Apr 2000 16:24:42 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA79777; Sat, 29 Apr 2000 08:53:24 +0930 (CST) Date: Sat, 29 Apr 2000 08:53:24 +0930 From: Greg Lehey To: Jesper Skriver Cc: current@FreeBSD.ORG Subject: Re: crash - perhaps vinum or sym related Message-ID: <20000429085324.D79469@freebie.lemis.com> References: <20000428184908.A24463@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000428184908.A24463@skriver.dk> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 28 April 2000 at 18:49:08 +0200, Jesper Skriver wrote: > > I'm not sure if this is a vinum problem, or a problem with the sym > driver, I hope someone is able to help us here. It's difficult to tell from the backtrace. The crash happens in the sym driver, but it is interrupted out of Vinum. I'd need to look at the dump. > db> trace > sym_flush_comp_queue(c0d7b000,e,384,c0d7b000,ff806b68) at sym_flush_comp_queue+0x1c > sym_flush_busy_queue(c0d7b000,e,c0d7b000,2,3610) at sym_flush_busy_queue+0x53 > sym_init(c0d7b000,1,c0235550,c0a61690,c0ec55ec) at sym_init+0xec > sym_intr1(c0d7b000,ff806c04,c0210315,c0d7b000,48000040) at sym_intr1+0x119 > sym_intr(c0d7b000,48000040,c0210018,c0290010,ff800010) at sym_intr+0xb > Xresume16() at Xresume16+0x38 > --- interrupt, eip = 0xc0225af8, esp = 0xff806be4, ebp = 0xff806c04 --- > splx(c1070400,c0eb5fa0,cf,c610935c,c1043000) at splx+0x30 > freerq(c1043000,c610935c,c10a4020,c0e82000,c10a4020) at freerq+0x7e > complete_rqe(c10a4020,c10a4020,c0e82000,c10a7c00,c0156986) at complete_rqe+0x59e > bufdone(c10a4020,ff806f84,c01289f9,c10a4020,c0e82014) at bufdone+0x55 > biodone(c10a4020,c0e82014,c10a4020) at biodone+0xb > dadone(c0e3a700,c10a7c00,0,0,ffffffff) at dadone+0x205 > camisr(c0274c30,0,c0211493,0,ff800018) at camisr+0x1eb > swi_cambio(0,ff800018,10,ffff0010,ffffffff) at swi_cambio+0xd > doreti_swi() at doreti_swi+0xf > >> From /var/log/messages: Try to trim this more in future. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 20:20:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 7183137C004 for ; Fri, 28 Apr 2000 20:20:17 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@trang.cdrom.com [204.216.28.153]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id UAA62897; Fri, 28 Apr 2000 20:20:05 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id UAA25984; Fri, 28 Apr 2000 20:20:05 -0700 (PDT) (envelope-from obrien) Date: Fri, 28 Apr 2000 20:20:05 -0700 From: "David O'Brien" To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs Message-ID: <20000428202005.A7375@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200004280132.SAA07593@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004280132.SAA07593@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Apr 27, 2000 at 06:32:24PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 27, 2000 at 06:32:24PM -0700, Matthew Dillon wrote: > A Swap-backed VN /tmp will work as well, but keep in mind that the > sector size is 4K and you should use the appropriate options to > vnconfig to pre-reserve the swap space so performance does not degrade > from fragmentation. I know you've done this before, but can you write a little recipt for your perfered way of doing a VN backed /tmp? Maybe we could get it committed to the Handbook or FAQ. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 20:59:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from web1611.mail.yahoo.com (web1611.mail.yahoo.com [128.11.23.177]) by hub.freebsd.org (Postfix) with SMTP id 725F037BA92 for ; Fri, 28 Apr 2000 20:59:27 -0700 (PDT) (envelope-from op4l@yahoo.com) Received: (qmail 6148 invoked by uid 60001); 29 Apr 2000 03:59:26 -0000 Message-ID: <20000429035926.6147.qmail@web1611.mail.yahoo.com> Received: from [203.106.65.111] by web1611.mail.yahoo.com; Fri, 28 Apr 2000 20:59:26 PDT Date: Fri, 28 Apr 2000 20:59:26 -0700 (PDT) From: "Nawfal M. Rouyan" Subject: Re:Sound problem To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I am experiencing the same problem. I am using Avance 100+ but it is detected as Avance 110. Nevertheless, the sound is working. Can anyone having Avance 100+ also check their sound card id. I checked the sbc.c code and found out that the id is used for detecting Avance 110. I am also experiencing problems of sound being lagged for about 4-6 seconds while using Realplayer 7. During 4.0 current, the sound worked fine without any lagged with the video. thanks... __________________________________________________ Do You Yahoo!? Talk to your friends online and get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 21:13:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail0.u-aizu.ac.jp (mail0.u-aizu.ac.jp [163.143.1.43]) by hub.freebsd.org (Postfix) with ESMTP id 42ACD37BA68 for ; Fri, 28 Apr 2000 21:13:36 -0700 (PDT) (envelope-from sarikaya@u-aizu.ac.jp) Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id NAA21856 for ; Sat, 29 Apr 2000 13:13:34 +0900 (JST) Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id NAA09861 for ; Sat, 29 Apr 2000 13:13:34 +0900 (JST) Message-ID: <390A616E.6DC60492@u-aizu.ac.jp> Date: Sat, 29 Apr 2000 13:13:34 +0900 From: Behcet Sarikaya Organization: University of Aizu X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: authentication for nis-user fails, only local user can login References: <39011C5A.96CAA198@u-aizu.ac.jp> Content-Type: multipart/alternative; boundary="------------3912666CF6564DA42922E653" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --------------3912666CF6564DA42922E653 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I installed FreeBSD 3.4 release and the most recent Kame v6 SNAP kernel and then configured nis. Now I have this mysterious problem. NIS and amd are working fine and I can su to the user accounts from root. Kame's inet46d invokes a telnetd with v6 support but my nis server does not support V6, could this be the problem? -- Behcet Sarikaya Computer Communications Lab. The University of Aizu --------------3912666CF6564DA42922E653 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I installed FreeBSD 3.4 release and the most recent Kame v6  SNAP kernel and then configured
nis. Now I have this mysterious problem.
NIS and amd are working fine and I can su to the user accounts from root.
  Kame's inet46d invokes a telnetd with v6 support but my nis server does not support V6, could this be
the problem? 
-- 
Behcet Sarikaya
Computer Communications Lab.
The University of Aizu
  --------------3912666CF6564DA42922E653-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 21:17: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id CA55137B9AE for ; Fri, 28 Apr 2000 21:17:01 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA29429; Sat, 29 Apr 2000 13:16:57 +0900 (JST) To: Behcet Sarikaya Cc: freebsd-current@freebsd.org In-reply-to: sarikaya's message of Sat, 29 Apr 2000 13:13:34 JST. <390A616E.6DC60492@u-aizu.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: authentication for nis-user fails, only local user can login From: itojun@iijlab.net Date: Sat, 29 Apr 2000 13:16:57 +0900 Message-ID: <29427.956981817@coconut.itojun.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I installed FreeBSD 3.4 release and the most recent Kame v6 SNAP kernel >and then configured >nis. Now I have this mysterious problem. >NIS and amd are working fine and I can su to the user accounts from >root. > Kame's inet46d invokes a telnetd with v6 support but my nis server >does not support V6, could this be >the problem? KAME libinet6 does not support NIS at all. therefore, KAME inet46d nor KAME telnetd do not. workaround: use FreeBSD telnetd (IPv4 only - does not allow IPv6 connections). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 22:29: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from mauibuilt.com (mauibuilt.com [205.166.249.50]) by hub.freebsd.org (Postfix) with ESMTP id 87AC637B718 for ; Fri, 28 Apr 2000 22:28:58 -0700 (PDT) (envelope-from freebsd@mauibuilt.com) Received: (from freebsd@localhost) by mauibuilt.com (8.9.3/8.9.3) id TAA05211; Fri, 28 Apr 2000 19:42:07 -1000 (HST) (envelope-from freebsd) From: FreeBSD MAIL Message-Id: <200004290542.TAA05211@mauibuilt.com> Subject: Re: Xircom cards In-Reply-To: <200004280631.AAA56339@harmony.village.org> from Warner Losh at "Apr 28, 2000 0:31:54 am" To: imp@village.org (Warner Losh) Date: Fri, 28 Apr 2000 19:42:07 -1000 (HST) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I cvsuped to 5.0-current and am trying the Xircom driver now. below is information on how I built my kernel and various configuration files. Upon insertion I get the below message. and although I can see the card with ifconfig or netstat -in as soon as I assign it a IP address it page faults. Also with -current my second PCMCIA controller dosn't work so I have it disabled in the kernel config. Ill keep checking for updated drivers and patches.. Hope this info helps. I have a Ricoh Majio laptop with 3 PCMCIA slots (2 controllers) which support cardbus and legacy. I have them in legacy mode. If there is any more info I should provide please let me know.. Richard Puga puga@mauibuilt.com ############/etc/pccard.conf######################## # Generally available IO ports io 0x240-0x360 # Generally available IRQs (Built-in sound-card owners remove 5) irq 3 5 10 11 13 15 # Available memory slots memory 0xd4000 96k # Xircom CreditCard Ethernet 10/100 + modem (Ethernet part) card "Xircom" "Ethernet Adapter" config auto "xe0" 9 insert logger -t pccard:$device -s Xircom CreditCard Modem inserted insert /etc/pccard_ether $device remove logger -t pccard:$device -s Xircom CreditCard Modem removed remove /sbin/ifconfig $device delete ##############INSERTING CARD BEFORE BOOT######################## xe0: xe: Probing xe0: Got version string (0x15) xe0: Got card ID (0x20) xe0: Card is Ethernet only xe0: Got MAC address (0x22) xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 9 slot 1 on pccard1 xe0: attach xe0: Xircom CE3, bonding version 0x45, 100Mbps capable xe0: DingoID = 0x444b, RevisionID = 0x1, VendorID = 0 xe0: Ethernet address 00:10:a4:f4:fa:e6 xe0: supplying EUI64: 00:10:a4:ff:fe:f4:fa:e6 xe0: BPF listener attached device_probe_and_attach: xe0 attach returned 1 ##############INSERTING CARD AFTER BOOT######################## ricoh /root 6% pccard: card inserted, slot 1 Apr 29 10:13:27 ricoh /kernel: pccard: card inserted, slot 1 Apr 29 10:13:27 ricoh /kernel: pccard: card inserted, slot 1 Apr 29 10:13:32 ricoh pccardd[45]: Card "Xircom"("Ethernet Adapter") matched "Xircom" ("Ethernet Adapter") Apr 29 10:13:32 ricoh pccardd[45]: Card "Xircom"("Ethernet Adapter") matched "Xircom" ("Ethernet Adapter") Apr 29 10:13:32 ricoh pccardd[45]: Card "Xircom"("Ethernet Adapter") matched "Xircom" ("Ethernet Adapter") xe0: xe: Probing xe0: Got version string (0x15) xe0: Got card ID (0x20) xe0: Card is Ethernet only xe0: Got MAC address (0x22) xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 9 slot 1 on pccard1 xe0: attach xe0: Cannot allocate ioport device_probe_and_attach: xe0 attach returned 12 Apr 29 10:13:38 ricoh /kernel: xe0: xe: Probing Apr 29 10:13:38 ricoh /kernel: xe0: xe: Probing Apr 29 10:13:38 ricoh /kernel: xe0: Got version string (0x15) Apr 29 10:13:38 ricoh /kernel: xe0: Got version string (0x15) Apr 29 10:13:38 ricoh /kernel: xe0: Got card ID (0x20) Apr 29 10:13:38 ricoh /kernel: xe0: Got card ID (0x20) Apr 29 10:13:38 ricoh /kernel: xe0: Card is Ethernet only Apr 29 10:13:38 ricoh /kernel: xe0: Card is Ethernet only Apr 29 10:13:38 ricoh /kernel: xe0: Got MAC address (0x22) Apr 29 10:13:38 ricoh /kernel: xe0: Got MAC address (0x22) Apr 29 10:13:38 ricoh /kernel: xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 9 slot 1 on pccard1 Apr 29 10:13:38 ricoh /kernel: xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 9 slot 1 on pccard1 Apr 29 10:13:38 ricoh /kernel: xe0: attach Apr 29 10:13:38 ricoh /kernel: xe0: attach Apr 29 10:13:38 ricoh /kernel: xe0: Cannot allocate ioport Apr 29 10:13:38 ricoh /kernel: xe0: Cannot allocate ioport Apr 29 10:13:38 ricoh /kernel: device_probe_and_attach: xe0 attach returned 12 Apr 29 10:13:38 ricoh /kernel: device_probe_and_attach: xe0 attach returned 12 Apr 29 10:13:38 ricoh pccardd[45]: driver allocation failed for Xircom(Ethernet Adapter): Cannot allocate memory Apr 29 10:13:38 ricoh pccardd[45]: driver allocation failed for Xircom(Ethernet Adapter): Cannot allocate memory Apr 29 10:13:38 ricoh pccardd[45]: driver allocation failed for Xircom(Ethernet Adapter): Cannot allocate memory ##############KERNEL CONFIG######################## # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.freebsd.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.252 2000/04/15 18:46:15 asmodai Exp $ machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC maxusers 32 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] #options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs device isa #device eisa device pci #options COMPAT_OLDISA # Old ISA driver shims #options COMPAT_OLDPCI # Old PCI driver shims # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device amd # AMD 53C974 (Teckram DC-390(T)) #device dpt # DPT Smartcache - See LINT for options! #device isp # Qlogic family #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets) #device adv0 at isa? #device adw #device bt0 at isa? #device aha0 at isa? #device aic0 at isa? # # SCSI peripherals #device scbus # SCSI bus (required) #device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) # RAID controllers #device ida # Compaq Smart RAID #device amr # AMI MegaRAID #device mlx # Mylex DAC960 family # # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? # Enable this for the pcvt (VT220 compatible) console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device tx # SMC 9432TX (83c170 ``EPIC'') #device vx # 3Com 3c590, 3c595 (``Vortex'') #device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support #device dc # DEC/Intel 21143 and various workalikes #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device ste # Sundance ST201 (D-Link DFE-550TX) #device tl # Texas Instruments ThunderLAN #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 device ex device ep # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attatement needed # and resources will always be dynamically assigned by the pccard code. device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those paremeters here. device an # BayStack 660 and others device awi # The probe order of these is presently determined by i386/isa/isa_compat.c. #device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device fe0 at isa? port 0x300 #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 irq 10 drq 0 #device cs0 at isa? port 0x300 #device sn0 at isa? port 0x300 irq 10 # Disabled because it is currently broken. device xe # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device sl 1 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device gif 4 # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device urio # Diamond Rio 500 MP3 player # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet #device sbc0 at isa? port 0x220 irq 5 drq 1 flags 0x15 device pcm options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Apr 28 23:20:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9668C37BB0B; Fri, 28 Apr 2000 23:20:15 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA21647; Fri, 28 Apr 2000 23:20:13 -0700 (PDT) (envelope-from dillon) Date: Fri, 28 Apr 2000 23:20:13 -0700 (PDT) From: Matthew Dillon Message-Id: <200004290620.XAA21647@apollo.backplane.com> To: "David O'Brien" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs References: <200004280132.SAA07593@apollo.backplane.com> <20000428202005.A7375@dragon.nuxi.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Thu, Apr 27, 2000 at 06:32:24PM -0700, Matthew Dillon wrote: :> A Swap-backed VN /tmp will work as well, but keep in mind that the :> sector size is 4K and you should use the appropriate options to :> vnconfig to pre-reserve the swap space so performance does not degrade :> from fragmentation. : :I know you've done this before, but can you write a little recipt for :your perfered way of doing a VN backed /tmp? Maybe we could get it :committed to the Handbook or FAQ. : :-- :-- David (obrien@NUXI.com) man vnconfig -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 0: 0:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail0.u-aizu.ac.jp (mail0.u-aizu.ac.jp [163.143.1.43]) by hub.freebsd.org (Postfix) with ESMTP id 3E2DA37B680 for ; Sat, 29 Apr 2000 00:00:54 -0700 (PDT) (envelope-from sarikaya@u-aizu.ac.jp) Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id QAA23712; Sat, 29 Apr 2000 16:00:52 +0900 (JST) Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id QAA10045; Sat, 29 Apr 2000 16:00:51 +0900 (JST) Message-ID: <390A88A3.AC1EA677@u-aizu.ac.jp> Date: Sat, 29 Apr 2000 16:00:51 +0900 From: Behcet Sarikaya Organization: University of Aizu X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net Cc: freebsd-current@freebsd.org Subject: Re: authentication for nis-user fails, only local user can login References: <29427.956981817@coconut.itojun.org> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes I did it but no change! I tried to remove libdescrypt.so.2 from /usr/lib then no user could login, so DES is being used but it seems only in MD5 (default FreeBSD authentication) mode. I don't know why. -- Behcet Sarikaya To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 5:21: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 6BD7A37B837 for ; Sat, 29 Apr 2000 05:20:54 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 320D33E46; Sat, 29 Apr 2000 14:20:47 +0200 (CEST) Date: Sat, 29 Apr 2000 14:20:47 +0200 From: Jesper Skriver To: Greg Lehey Cc: current@FreeBSD.ORG Subject: Re: crash - perhaps vinum or sym related Message-ID: <20000429142047.C29865@skriver.dk> References: <20000428184908.A24463@skriver.dk> <20000429085324.D79469@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000429085324.D79469@freebie.lemis.com>; from grog@lemis.com on Sat, Apr 29, 2000 at 08:53:24AM +0930 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 29, 2000 at 08:53:24AM +0930, Greg Lehey wrote: > On Friday, 28 April 2000 at 18:49:08 +0200, Jesper Skriver wrote: > > > > I'm not sure if this is a vinum problem, or a problem with the sym > > driver, I hope someone is able to help us here. > > It's difficult to tell from the backtrace. The crash happens in the > sym driver, but it is interrupted out of Vinum. I'd need to look at > the dump. The box hangs now, so I'll need to go press the reset button, when I'm there I'll reproduce the crash again - what exactly do you want ? It it what you specify at http://www.lemis.com/vinum/how-to-debug.html#panic or ? Just making sure I get the correct information to you. > >> From /var/log/messages: > > Try to trim this more in future. Will do. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 6:55:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 30DA137B9B4 for ; Sat, 29 Apr 2000 06:55:34 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 121C11CE0 for ; Sat, 29 Apr 2000 06:55:33 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: current@freebsd.org Subject: HEADS UP: module dependency metadata committed Date: Sat, 29 Apr 2000 06:55:33 -0700 From: Peter Wemm Message-Id: <20000429135533.121C11CE0@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A functional checkpoint of module metadata has been committed in -current. This is to provide a decent module-level dependency and versioning system, rather than the mostly-broken file-level system that presently exists. Not everything is in place yet, so the KMODDEPS lines in modules/*/Makefile are still there so that the current loader does the right thing still. There was work in the pipeline some time ago to implement the metadata strategy, but it's not strictly required yet. Dependency information is presently being done twice - once for loader's benefit (using KMODDEPS and DT_NEEDED), and one for the in-kernel code's benefit (using metadata in linker sets). I'm fairly sure it will work wothout causing too much trouble, I've been doing crash-and-burn testing over the last two days, and incidently, found some nasty bugs where I didn't expect to find them. The ipfw and linux kld's have a nasty habit of randomly corrupting the malloc pool on unload (even before my changes) - so don't try load/unload loops on those two. :-> See the commit message for more detail. There will be more work over the next few days, including resolving how the version numbers will be enforced. The present version numbers are ignored. The good news though.. once this is all done, the nasty suprises that turn up if you accidently get your kld's out of sync with a kernel should be a thing of the past. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 7:40:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.surf1.de (mail.Surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id 4F72B37B599 for ; Sat, 29 Apr 2000 07:40:37 -0700 (PDT) (envelope-from alex@cichlids.com) Received: from cichlids.com (p3E9D38DC.dip0.t-ipconnect.de [62.157.56.220]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id PAA31060 for ; Sat, 29 Apr 2000 15:39:32 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by cichlids.com (Postfix) with ESMTP id 24008AC2C for ; Sat, 29 Apr 2000 16:44:43 +0200 (CEST) Received: (from alex@localhost) by cichlids.cichlids.com (8.9.3/8.9.3) id QAA07788 for current@freebsd.org; Sat, 29 Apr 2000 16:40:27 +0200 (CEST) (envelope-from alex) Date: Sat, 29 Apr 2000 16:40:27 +0200 From: Alexander Langer To: current@freebsd.org Subject: MVP3 problems - current state? Message-ID: <20000429164027.A7708@cichlids.cichlids.com> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! 20000320: * * * W A R N I N G * * * The ata driver has some issues with the Apollo MVP3 chipset. Drives work only in pio mode and must be set to pio mode early int the boot process. Do not upgrade. If you must upgrade in the face of this, add /sbin/sysctl -w hw.atamodes=pio,pio,pio,pio to the start of /etc/rc.conf. Even if you do this, any and all damage to your system is at your own risk. You have been warned. * * * W A R N I N G * * * Of _course_ I own such a thing. FreeBSD 5.0-CURRENT #0: Fri Mar 31 16:52:11 CEST 2000 alex@cichlids.cichlids.com:/usr/src/sys/compile/cichlids pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 on pci0 atapci0: port 0xe000-0xe00f at device 7.1 on pci0 Two things: As you can see, my -current is from Mar 31,though I don't know exaclty if I've taken sourcs from Mar 31, but I'm kinda sure. Question is: Does the problem affect all versions? It doesn't seem so, since I'm running two disks at UDMA33 without problems: ad0: 4133MB [8959/15/63] at ata0-master using UDMA33 ad2: 6197MB [12592/16/63] at ata1-master using UDMA33 There still is a little chance that my sources wasn't from pre-03/20, so - is this problem fixed? Alex -- I need a new ~/.sig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 8: 1: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.surf1.de (mail.Surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id 954E337BE65 for ; Sat, 29 Apr 2000 08:00:57 -0700 (PDT) (envelope-from alex@cichlids.com) Received: from cichlids.com (p3E9D38DC.dip0.t-ipconnect.de [62.157.56.220]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id PAA02888 for ; Sat, 29 Apr 2000 15:59:50 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by cichlids.com (Postfix) with ESMTP id EAFADAC2C for ; Sat, 29 Apr 2000 17:05:08 +0200 (CEST) Received: (from alex@localhost) by cichlids.cichlids.com (8.9.3/8.9.3) id RAA08113 for current@FreeBSD.ORG; Sat, 29 Apr 2000 17:00:52 +0200 (CEST) (envelope-from alex) Date: Sat, 29 Apr 2000 17:00:52 +0200 From: Alexander Langer To: current@FreeBSD.ORG Subject: Re: MVP3 problems - current state? Message-ID: <20000429170052.A8047@cichlids.cichlids.com> Mail-Followup-To: current@FreeBSD.ORG References: <20000429164027.A7708@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000429164027.A7708@cichlids.cichlids.com>; from alex@big.endian.de on Sat, Apr 29, 2000 at 04:40:27PM +0200 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I spread stupidity: > There still is a little chance that my sources wasn't from pre-03/20, > so - is this problem fixed? I mean: There still is a little chance that my sources were from pre-03/20, and if I update now I'm running into problems. That's why I ask if the problem is fixed. Alex -- I need a new ~/.sig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 9:11:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id CFB3537B6C3 for ; Sat, 29 Apr 2000 09:11:10 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 16B0E3E47; Sat, 29 Apr 2000 18:11:09 +0200 (CEST) Date: Sat, 29 Apr 2000 18:11:08 +0200 From: Jesper Skriver To: Greg Lehey Cc: current@FreeBSD.ORG, Niels Christian Bank-Pedersen Subject: Re: crash - perhaps vinum or sym related Message-ID: <20000429181108.B30793@skriver.dk> References: <20000428184908.A24463@skriver.dk> <20000429085324.D79469@freebie.lemis.com> <20000429142047.C29865@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000429142047.C29865@skriver.dk>; from jesper@skriver.dk on Sat, Apr 29, 2000 at 02:20:47PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 29, 2000 at 02:20:47PM +0200, Jesper Skriver wrote: > On Sat, Apr 29, 2000 at 08:53:24AM +0930, Greg Lehey wrote: > > On Friday, 28 April 2000 at 18:49:08 +0200, Jesper Skriver wrote: > > > > > > I'm not sure if this is a vinum problem, or a problem with the sym > > > driver, I hope someone is able to help us here. > > > > It's difficult to tell from the backtrace. The crash happens in the > > sym driver, but it is interrupted out of Vinum. I'd need to look at > > the dump. > > The box hangs now, so I'll need to go press the reset button, when I'm > there I'll reproduce the crash again - what exactly do you want ? > > It it what you specify at http://www.lemis.com/vinum/how-to-debug.html#panic > or ? Just making sure I get the correct information to you. We build a debug kernel, and enabled kernel dumps, as described in the handbook (http://www.freebsd.org/handbook/kerneldebug.html#AEN20443), but it didn't write a kernel dump, can anyone see what we did wrong ? remie# dumpon -v /dev/da0s1b dumpon: crash dumps to /dev/da0s1b (13, 131073) remie# Apr 29 17:49:59 remie su: ncbp to root on /dev/ttyp0 Apr 29 17:49:59 remie su: ncbp to root on /dev/ttyp0 Apr 29 17:50:06 remie /kernel: vinum: raid01.p1.s0 is reviving, not up Apr 29 17:50:06 remie /kernel: vinum: raid01.p1.s1 is reviving, not up Apr 29 17:50:06 remie /kernel: vinum: raid01.p1.s2 is reviving, not up Apr 29 17:50:06 remie /kernel: vinum: raid01.p1.s3 is reviving, not up Apr 29 sym0:3: ERROR (81:0) (8-0-0) (1f/9f) @ (mem 8:f000ff53). sym0: regdump: da 00 00 9f 47 1f 03 03 04 08 81 00 80 00 0f 02 00 aa 7b 00 02 ff ff ff. sym1: bad DSA (8bac00) in done queue. sym1:2: ERROR (81:0) (0-a7-80) (1f/9f) @ (mem 8:f000ff53). sym1: regdump: da 10 80 9f 47 1f 02 03 0c 00 88 a7 80 00 0f 02 00 a2 7b 00 08 ff ff ff. (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at sym_flush_comp_queue+0x1c: movl %edi,0x4(%eax) db> trace sym_flush_comp_queue(c08bb000,e,384,c08bb000,c6233c1c) at sym_flush_comp_queue+0x1c sym_flush_busy_queue(c08bb000,e,c08bb000,2,c09a1bfa) at sym_flush_busy_queue+0x53 sym_init(c08bb000,1,c0235510,c05a1690,6bf8) at sym_init+0xec sym_intr1(c08bb000,c6233cc0,c02102d5,c08bb000,0) at sym_intr1+0x119 sym_intr(c08bb000,0,c6230018,c6230010,c08c0010) at sym_intr+0xb Xresume16() at Xresume16+0x38 --- interrupt, eip = 0xc0225aa8, esp = 0xc6233c98, ebp = 0xc6233cc0 --- splx(24,c09a1bc0,c8,9c00,af80) at splx+0x30 vinumstart(c1d3cc4c,1,c0bca000,13,c0bca000) at vinumstart+0x45 revive_block(13,c0bca000,c098aa00,c5cd2040,0) at revive_block+0x363 start_object(c0bca000,0,c098aa00,c5cd2040,c621f6c0) at start_object+0x10d setstate(c0bca000,c6233de4,c098aa00,c0bca000,c6233db4) at setstate+0x205 vinumioctl(c098aa00,c400464c,c0bca000,3,c5cd2040) at vinumioctl+0x4f9 spec_ioctl(c6233de4,c6233dcc,c01ec895,c6233de4,c6233e74) at spec_ioctl+0x26 spec_vnoperate(c6233de4,c6233e74,c0180f38,c6233de4,c0b353c0) at spec_vnoperate+0x15 ufs_vnoperatespec(c6233de4,c0b353c0,0,400,c0258600) at ufs_vnoperatespec+0x15 vn_ioctl(c0b353c0,c400464c,c0bca000,c5cd2040,3) at vn_ioctl+0x110 ioctl(c5cd2040,c6233f80,bfbff6c4,bfbff244,13) at ioctl+0x20b syscall2(2f,2f,2f,13,bfbff244) at syscall2+0x219 Xint0x80_syscall() at Xint0x80_syscall+0x2c db> continue Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at sym_flush_comp_queue+0x1c: movl %edi,0x4(%eax) db> continue Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at sym_flush_comp_queue+0x1c: movl %edi,0x4(%eax) db> panic panic: from debugger mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 Debugger("panic") Stopped at sym_flush_comp_queue+0x1c: movl %edi,0x4(%eax) db> continue Fatal trap 12: page fault while in kernel mode mp_lock = 01000004; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at sym_flush_comp_queue+0x1c: movl %edi,0x4(%eax) db> panic panic: from debugger mp_lock = 01000004; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 Uptime: 5m46s Where it hung again ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 10:13:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from aragorn.neomedia.it (aragorn.neomedia.it [195.103.207.6]) by hub.freebsd.org (Postfix) with ESMTP id B8A5637B58D for ; Sat, 29 Apr 2000 10:13:09 -0700 (PDT) (envelope-from bartequi@neomedia.it) Received: from bartequi.ottodomain.org (ppp3-pa5.neomedia.it [195.103.207.115]) by aragorn.neomedia.it (8.9.3/8.9.3) with SMTP id TAA12839 for ; Sat, 29 Apr 2000 19:13:06 +0200 (CEST) From: Salvo Bartolotta Date: Sat, 29 Apr 2000 18:14:53 GMT Message-ID: <20000429.18145300@mis.configured.host> Subject: ldconfig -m not configuring ? To: freebsd-current@FreeBSD.ORG X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear FreeBSD'ers I cvsup'ed -CURRENT on 25 April at about 9 GMT. I succesfully made the world apart from a couple of minor issues. In the next few days, I installed some ports and, in, particular, the linux_base-6.1 port; then I installed StarOffice5.1a (via ports). Everything seemed to work properly. I installed Acrobat Reader 4.05 (via ports) and then other ports (e.g. Apsfilter (ie teTeX), lyx, textproc/docproj, ...) and I configured=20 JADETEX & C. But when I issued "acroread4", the terminal spat out "ELF interpreter /lib/ld-linux.so.2 not found." The interpreter does exist in /usr/compat/linux/lib/ld-linux.so.2 --> ld-2.1.2.so and this is what "file ld-2.1.2.so" says: ld-2.1.2.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped. I issued a "ldconfig -r | grep ld-linux" and, actually, I found nothing. Then I issued a "ldconfig -m /usr/compat/linux/lib" and even a "ldconfig -aout -m /usr/compat/linux/lib" (paranoia.) Now ldconfig -r shows a bunch of /usr/compat/linux/lib libraries EXCEPT the one I would have liked it to save among the hints. For some obscure (to me) reason, it refuses to take ld-linux.so.2 (ie ld-2.1.2.so) into consideration. By the way, acroread is correctly brandelfed, since it was installed after remaking the -CURRENT world. Just to be paranoidly safe, I rebrandelfed it, and a diff with the .orig version (previously copied) of course showed no difference. What prevents ldconfig -m /usr/compat/linux/lib from doing its duty ? What am I missing ? Many thanks in advance and happy weekend, Salvo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 10:19:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from ucsu.Colorado.EDU (ucsu.Colorado.EDU [128.138.129.83]) by hub.freebsd.org (Postfix) with ESMTP id E3E5C37B55D for ; Sat, 29 Apr 2000 10:19:21 -0700 (PDT) (envelope-from vinson@ucsu.Colorado.EDU) Received: from localhost (vinson@localhost) by ucsu.Colorado.EDU (8.9.3/8.9.3/ITS-5.0/standard) with SMTP id LAA00325 for ; Sat, 29 Apr 2000 11:19:21 -0600 (MDT) Date: Sat, 29 Apr 2000 11:19:21 -0600 (MDT) From: VINSON WAYNE HOWARD To: freebsd-current@freebsd.org Subject: Re:Sound problem In-Reply-To: <20000429035926.6147.qmail@web1611.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hopefully I'm hiting the right thread here - This is in reply to the post about excessively high loads caused by xmms. I'm showing about 90% from xmms as well. However, I'm not sure it's real. I'm not seeing much, if any slowdown. Is top the tool I should be using to figure this out? Possible causes: I rebuild xmms and my kernel/world last night, and it showed up. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 10:45:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from corserv.corserv.com (corserv.corserv.com [206.180.159.81]) by hub.freebsd.org (Postfix) with ESMTP id F074B37B9B4 for ; Sat, 29 Apr 2000 10:45:21 -0700 (PDT) (envelope-from klyons@corserv.corserv.com) Received: (from klyons@localhost) by corserv.corserv.com (8.8.7/8.8.7) id MAA17126; Sat, 29 Apr 2000 12:54:34 -0500 (CDT) (envelope-from klyons) Date: Sat, 29 Apr 2000 12:54:34 -0500 (CDT) From: Kevin Lyons Message-Id: <200004291754.MAA17126@corserv.corserv.com> To: freebsd-current@FreeBSD.ORG, Wayne.Vinson@Colorado.EDU Subject: Re:Sound problem Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > about excessively high loads caused by xmms. I'm showing about 90% from > xmms as well. However, I'm not sure it's real. I'm not seeing much, if > any slowdown. Is top the tool I should be using to figure this out? > > Possible causes: I rebuild xmms and my kernel/world last night, and it > showed up. FYI, I have seen top report 100% usage when zombie or stopped processes were active yet a vmstat or uptime reports normal operation. I would suspect top. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 12:45:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from Quote.Twiddle.COM (mail.twiddle.nl [212.83.214.2]) by hub.freebsd.org (Postfix) with ESMTP id CB2E237B982 for ; Sat, 29 Apr 2000 12:45:22 -0700 (PDT) (envelope-from jh@efmsoftware.com) Received: from dc2-isdn2253.dial.xs4all.nl ([194.109.156.205] helo=EFMSoftware.COM) by Quote.Twiddle.COM with esmtp (Exim 3.02 #4) id 12ldIe-0005rC-00 for freebsd-current@FreeBSD.ORG; Sat, 29 Apr 2000 21:53:12 +0200 Message-ID: <390C8E8C.6050005@EFMSoftware.COM> Date: Sun, 30 Apr 2000 21:50:36 +0200 From: Jeroen Hogeveen User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.0-STABLE i386; en-US; m16) Gecko/20000428 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Subject: Re: Kde2pre: is it FreeBSD or Kde fault? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey Vallo, You can try to edit the libtool file in the kdelibs directory to set deplibs="$deplibs -lc -lgcc" (around line number 2600). This will link the __eh_rtime_match. I still get a nonworking khtm however.. : khtml (cache): CachedImage::ref() khtml (cache): Cache::notify() konqueror: KCrash: crashing.... crashRecursionCounter = 0 konqueror: KCrash: Appname = 0x8073fb0 apppath = 0x0 konqueror: Unable to start dr. konqi DCOP: unregister 'konqueror'kio (KIOConnection): read kio (kioslave): slavewrapper: Communication with app lost. Returning to slave pool. Any ideas? --jh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 13: 4:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from ucsu.Colorado.EDU (ucsu.Colorado.EDU [128.138.129.83]) by hub.freebsd.org (Postfix) with ESMTP id 7825537B98A for ; Sat, 29 Apr 2000 13:04:47 -0700 (PDT) (envelope-from vinson@ucsu.Colorado.EDU) Received: from localhost (vinson@localhost) by ucsu.Colorado.EDU (8.9.3/8.9.3/ITS-5.0/standard) with SMTP id OAA19544 for ; Sat, 29 Apr 2000 14:04:46 -0600 (MDT) Date: Sat, 29 Apr 2000 14:04:45 -0600 (MDT) From: VINSON WAYNE HOWARD To: freebsd-current@FreeBSD.ORG Subject: Re:Sound problem In-Reply-To: <200004291754.MAA17126@corserv.corserv.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I'll try to get a better handle on whether or not it's real. On Sat, 29 Apr 2000, Kevin Lyons wrote: > > about excessively high loads caused by xmms. I'm showing about 90% from > > xmms as well. However, I'm not sure it's real. I'm not seeing much, if > > any slowdown. Is top the tool I should be using to figure this out? > > > > Possible causes: I rebuild xmms and my kernel/world last night, and it > > showed up. > > FYI, I have seen top report 100% usage when zombie or stopped processes > were active yet a vmstat or uptime reports normal operation. I would suspect > top. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 13:46:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 105A437B756 for ; Sat, 29 Apr 2000 13:46:16 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 04BD33E44; Sat, 29 Apr 2000 22:46:14 +0200 (CEST) Date: Sat, 29 Apr 2000 22:46:14 +0200 From: Jesper Skriver To: Greg Lehey Cc: current@FreeBSD.ORG, Niels Christian Bank-Pedersen Subject: Re: crash - perhaps vinum or sym related Message-ID: <20000429224614.A31885@skriver.dk> References: <20000428184908.A24463@skriver.dk> <20000429085324.D79469@freebie.lemis.com> <20000429142047.C29865@skriver.dk> <20000429181108.B30793@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000429181108.B30793@skriver.dk>; from jesper@skriver.dk on Sat, Apr 29, 2000 at 06:11:08PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 29, 2000 at 06:11:08PM +0200, Jesper Skriver wrote: > On Sat, Apr 29, 2000 at 02:20:47PM +0200, Jesper Skriver wrote: > > On Sat, Apr 29, 2000 at 08:53:24AM +0930, Greg Lehey wrote: > > > On Friday, 28 April 2000 at 18:49:08 +0200, Jesper Skriver wrote: > > > > > > > > I'm not sure if this is a vinum problem, or a problem with the sym > > > > driver, I hope someone is able to help us here. > > > > > > It's difficult to tell from the backtrace. The crash happens in the > > > sym driver, but it is interrupted out of Vinum. I'd need to look at > > > the dump. > > > > The box hangs now, so I'll need to go press the reset button, when I'm > > there I'll reproduce the crash again - what exactly do you want ? > > > > It it what you specify at http://www.lemis.com/vinum/how-to-debug.html#panic > > or ? Just making sure I get the correct information to you. > > We build a debug kernel, and enabled kernel dumps, as described in the > handbook (http://www.freebsd.org/handbook/kerneldebug.html#AEN20443), > but it didn't write a kernel dump, can anyone see what we did wrong ? I don't know what happened before, but now we got a kernel dump, I'll sent you the URL's in a private email. remie# gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.0 (kgdb) core-file /var/crash/vmcore.0 SMP 2 cpus IdlePTD 3063808 initial pcb at 278820 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX panic: from debugger mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 Fatal trap 12: page fault while in kernel mode mp_lock = 01000004; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX panic: from debugger mp_lock = 01000004; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 Uptime: 5m46s (da5:sym0:0:0:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da6:sym0:0:1:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da7:sym0:0:2:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da8:sym0:0:3:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da9:sym0:0:4:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da10:sym0:0:5:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da11:sym0:0:6:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da12:sym0:0:8:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da13:sym0:0:9:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (noperiph:sym1:0:-1:-1): SCSI BUS reset detected. Fatal trap 12: page fault while in kernel mode mp_lock = 01000005; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc012197c stack pointer = 0x10:0xc6233678 frame pointer = 0x10:0xc6233680 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX panic: from debugger mp_lock = 01000005; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 Uptime: 51m3s (da5:sym0:0:0:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da6:sym0:0:1:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da7:sym0:0:2:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da8:sym0:0:3:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da9:sym0:0:4:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da10:sym0:0:5:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da11:sym0:0:6:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da12:sym0:0:8:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da13:sym0:0:9:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da14:sym1:0:0:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da15:sym1:0:1:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da16:sym1:0:2:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da17:sym1:0:3:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da19:sym1:0:5:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da20:sym1:0:6:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da21:sym1:0:8:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da22:sym1:0:9:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 sym4: bad DSA (8ba600) in done queue. sym4: bad DSA (8bae00) in done queue. sym4:8: ERROR (81:0) (0-a7-80) (1f/9f) @ (mem 8:f000ff53). sym4: regdump: da 10 80 9f 47 1f 08 03 04 00 80 a7 80 00 07 02 00 a0 7b 00 28 ff ff ff. (noperiph:sym4:0:-1:-1): SCSI BUS reset detected. Fatal trap 12: page fault while in kernel mode mp_lock = 01000006; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc62336a4 frame pointer = 0x10:0xc62336b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 222 (vinum) interrupt mask = cam <- SMP: XXX panic: from debugger mp_lock = 01000006; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 Uptime: 2h16m34s (da5:sym0:0:0:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da6:sym0:0:1:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da7:sym0:0:2:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da8:sym0:0:3:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da9:sym0:0:4:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da10:sym0:0:5:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da11:sym0:0:6:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da12:sym0:0:8:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da13:sym0:0:9:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da14:sym1:0:0:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da15:sym1:0:1:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da16:sym1:0:2:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da17:sym1:0:3:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da19:sym1:0:5:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da20:sym1:0:6:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da21:sym1:0:8:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da22:sym1:0:9:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da23:sym4:0:0:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da24:sym4:0:1:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da25:sym4:0:2:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da26:sym4:0:3:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da27:sym4:0:4:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da28:sym4:0:5:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da29:sym4:0:6:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da30:sym4:0:8:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da31:sym4:0:9:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 dumping to dev #da/0x20001, offset 393216 dump 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 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 --- #0 boot (howto=260) at ../../kern/kern_shutdown.c:302 302 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=260) at ../../kern/kern_shutdown.c:302 #1 0xc014ae1d in panic (fmt=0xc0234254 "from debugger") at ../../kern/kern_shutdown.c:552 #2 0xc01296f9 in db_panic (addr=-1072500324, have_addr=0, count=1, modif=0xc6233a40 "") at ../../ddb/db_command.c:433 #3 0xc0129699 in db_command (last_cmdp=0xc025ac7c, cmd_table=0xc025aadc, aux_cmd_tablep=0xc0274b90) at ../../ddb/db_command.c:333 #4 0xc012975e in db_command_loop () at ../../ddb/db_command.c:455 #5 0xc012b91f in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71 #6 0xc020c88c in kdb_trap (type=12, code=0, regs=0xc6233b9c) at ../../i386/i386/db_interface.c:158 #7 0xc021f4d2 in trap_fatal (frame=0xc6233b9c, eva=4) at ../../i386/i386/trap.c:922 #8 0xc021f169 in trap_pfault (frame=0xc6233b9c, usermode=0, eva=4) at ../../i386/i386/trap.c:820 #9 0xc021eccf in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1064584964, tf_esi = -1064587264, tf_ebp = -970769432, tf_isp = -970769464, tf_ebx = -1061524536, tf_edx = -1061524536, tf_ecx = -1064587264, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1072500324, tf_cs = 8, tf_eflags = 66070, tf_esp = -1061524536, tf_ss = -1064584964}) at ../../i386/i386/trap.c:426 #10 0xc012f19c in sym_flush_comp_queue (np=0xc08bb000, cam_status=14) at ../../dev/sym/sym_hipd.c:192 #11 0xc012daab in sym_flush_busy_queue (np=0xc08bb000, cam_status=14) at ../../dev/sym/sym_hipd.c:4644 #12 0xc012dba0 in sym_init (np=0xc08bb000, reason=1) at ../../dev/sym/sym_hipd.c:4705 #13 0xc012e809 in sym_intr1 (np=0xc08bb000) at ../../dev/sym/sym_hipd.c:5409 #14 0xc012e8bf in sym_intr (arg=0xc08bb000) at ../../dev/sym/sym_hipd.c:5453 #15 0xc0225aa8 in splx (ipl=3231304629) at ../../i386/isa/ipl_funcs.c:241 #16 0xc099cbb5 in ?? () #17 0xc099e117 in ?? () #18 0xc099f931 in ?? () #19 0xc099fcc1 in ?? () #20 0xc099a7d5 in ?? () #21 0xc018576e in spec_ioctl (ap=0xc6233de4) at ../../miscfs/specfs/spec_vnops.c:304 #22 0xc0185499 in spec_vnoperate (ap=0xc6233de4) at ../../miscfs/specfs/spec_vnops.c:117 #23 0xc01ec895 in ufs_vnoperatespec (ap=0xc6233de4) at ../../ufs/ufs/ufs_vnops.c:2305 #24 0xc0180f38 in vn_ioctl (fp=0xc0b353c0, com=3288352332, data=0xc0bca000 "\023", p=0xc5cd2040) at vnode_if.h:429 #25 0xc015ba6f in ioctl (p=0xc5cd2040, uap=0xc6233f80) at ../../sys/file.h:172 #26 0xc021f829 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 19, tf_esi = -1077939644, tf_ebp = -1077938428, tf_isp = -970768428, tf_ebx = -1077938492, tf_edx = 134901864, tf_ecx = -11, tf_eax = 54, tf_trapno = 7, tf_err = 2, tf_eip = 134677660, tf_cs = 31, tf_eflags = 663, tf_esp = -1077939688, tf_ss = 47}) at ../../i386/i386/trap.c:1126 #27 0xc020d22c in Xint0x80_syscall () /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 14:15:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from ucsu.Colorado.EDU (ucsu.Colorado.EDU [128.138.129.83]) by hub.freebsd.org (Postfix) with ESMTP id CCE6F37B55B for ; Sat, 29 Apr 2000 14:15:44 -0700 (PDT) (envelope-from vinson@ucsu.Colorado.EDU) Received: from localhost (vinson@localhost) by ucsu.Colorado.EDU (8.9.3/8.9.3/ITS-5.0/standard) with SMTP id PAA11489 for ; Sat, 29 Apr 2000 15:15:44 -0600 (MDT) Date: Sat, 29 Apr 2000 15:15:43 -0600 (MDT) From: VINSON WAYNE HOWARD To: freebsd-current@freebsd.org Subject: high CPU usage by xmms Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I checked, and vmstat shows cpu usage to be quite normal, about 6% while playing. What's up w/ top? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 15: 7:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from queeg.ludd.luth.se (queeg.ludd.luth.se [130.240.16.109]) by hub.freebsd.org (Postfix) with ESMTP id 985A337BA5D for ; Sat, 29 Apr 2000 15:07:48 -0700 (PDT) (envelope-from pantzer@ludd.luth.se) Received: from speedy.ludd.luth.se (pantzer@speedy.ludd.luth.se [130.240.16.164]) by queeg.ludd.luth.se (8.9.3/8.9.3) with ESMTP id AAA04009; Sun, 30 Apr 2000 00:07:43 +0200 (CEST) Message-Id: <200004292207.AAA04009@queeg.ludd.luth.se> X-Mailer: exmh version 2.1.1 10/15/1999 To: VINSON WAYNE HOWARD Cc: freebsd-current@FreeBSD.ORG Subject: Re: high CPU usage by xmms In-Reply-To: Message from VINSON WAYNE HOWARD of "Sat, 29 Apr 2000 15:15:43 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Apr 2000 00:07:43 +0200 From: Mattias Pantzare Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok, I checked, and vmstat shows cpu usage to be quite normal, about 6% > while playing. What's up w/ top? Not on my computer: pantzer@skalman ~ >vmstat -w 1 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id 4 1 0 339480 5552 131 0 0 1 147 233 0 0 288 1722 1971 6 5 89 1 1 0 339480 5532 8 0 0 0 0 0 3 1 312 34105 34350 16 84 0 1 1 0 339456 5556 5 0 0 0 6 0 0 0 321 34349 34608 10 90 0 1 1 0 339456 5552 5 0 0 0 0 0 0 1 321 34211 34484 12 88 0 If you only run vmstat you get the average since the computer started. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 15:45:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from rtp.tfd.com (rtp.tfd.com [198.79.53.206]) by hub.freebsd.org (Postfix) with ESMTP id 43E4237B57F for ; Sat, 29 Apr 2000 15:45:45 -0700 (PDT) (envelope-from kent@chapel-hill.tfd.com) Received: from chapel-hill.tfd.com (chapel-hill.tfd.com [10.20.0.40]) by rtp.tfd.com (8.9.3/8.9.3) with ESMTP id SAA16659 for ; Sat, 29 Apr 2000 18:46:26 -0400 (EDT) Received: (from root@localhost) by chapel-hill.tfd.com (8.9.3/8.9.3) id SAA41613 for current@freebsd.org; Sat, 29 Apr 2000 18:45:41 -0400 (EDT) (envelope-from kent) Date: Sat, 29 Apr 2000 18:45:41 -0400 (EDT) From: Kent Hauser Message-Id: <200004292245.SAA41613@chapel-hill.tfd.com> To: current@freebsd.org Subject: Kernel builds fail Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I can't build a kernel after CVSUP'ing today. After successfully completing a `make world', I tried to build a kernel. Edited script below. chapel-hill# cd /sys/i386/conf chapel-hill# rm -rf ../../compile/GENERIC chapel-hill# config GENERIC WARNING: Old ISA driver compatability shims present. Don't forget to do a ``make depend'' Kernel build directory is ../../compile/GENERIC chapel-hill# cd ../../compile/GENERIC chapel-hill# make -s depend all ./aicasm: 725 instructions used [[ lots of warnings deleted ]] ../../kern/vfs_bio.c:2584: warning: no previous prototype for `biowait' [[ more warnings deleted ]] linking kernel vfs_bio.o: In function `bread': vfs_bio.o(.text+0x485): undefined reference to `bufwait' vfs_bio.o: In function `breadn': vfs_bio.o(.text+0x64f): undefined reference to `bufwait' vfs_bio.o: In function `bwrite': vfs_bio.o(.text+0x87e): undefined reference to `bufwait' vfs_cluster.o: In function `cluster_read': vfs_cluster.o(.text+0x481): undefined reference to `bufwait' nfs_vnops.o: In function `nfs_writebp': nfs_vnops.o(.text+0x11951): undefined reference to `bufwait' ffs_inode.o(.text+0xc0c): more undefined references to `bufwait' follow *** Error code 1 Stop in /usr/src/sys/compile/GENERIC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 17:41:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from aragorn.neomedia.it (aragorn.neomedia.it [195.103.207.6]) by hub.freebsd.org (Postfix) with ESMTP id B4C9937BB9F for ; Sat, 29 Apr 2000 17:41:19 -0700 (PDT) (envelope-from bartequi@neomedia.it) Received: from bartequi.ottodomain.org (ppp1-pa5.neomedia.it [195.103.207.113]) by aragorn.neomedia.it (8.9.3/8.9.3) with SMTP id CAA00187 for ; Sun, 30 Apr 2000 02:41:15 +0200 (CEST) From: Salvo Bartolotta Date: Sun, 30 Apr 2000 01:43:04 GMT Message-ID: <20000430.1430400@bartequi.ottodomain.org> Subject: ldconfig not configuring NOT solved: followup (RTFM .RTFM RTFM ... ) To: freebsd-current@FreeBSD.ORG X-Mailer: SuperCalifragilis X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear FreeBSD'ers, I apologize for the previous very superficial question. I had missed the Linux mode stuff I RTFMed it. However, the problem is still there *re-sigh* I ran the Linux ldconfig, ie /usr/compat/linux/sbin/ldconfig -p | grep ld: it said that ld-linux-so.2 WAS in the hints. Then I ran=20 /usr/compat/linux/ldconfig (no options). And yet I got the same error when I launched "acroread4": ELF interpreter /lib/ld-linux.so.2 not found. I made a copy of ld-2.1.2.so (the actual file referred to by ld-linux.so.2) with suffix .orig, and I brandelfed -t Linux ld.2.1.2.so. Alas, it did NOT work either. I had a look at another slice (4-STABLE) of mine, where Acrobat Reader 4.05 works. BTW, the ld.so.cache was equal. I have not yet discovered any illuminating difference in the /usr/compat/linux subtree. **If** I fully understand the situation and if I am not missing other pieces of the puzzle, the "syntax" is all right. Therefore the problem should be "semantical". In other words, under 5-CURRENT (sources as of 25 April 9 GMT) the Linux mode does NOT work properly. Please note: StarOffice 5.1a works whereas Acrobat Reader (which requires the ld-linux.so.2 interpreter) does NOT. This problem should not be related to the brandelf issue: I installed the linux_base-6.1 and a couple of Linux-emulated ports (StarOffice, Acrobat) *after* making the 5-CURRENT world. As I said in the previous message, StarOffice works. And brandelfing acroread produces a file *equal* to the non-brandelfed acroread. What am I missing now ? Is the Linux mode just broken ? Thanks in advance again for any help and best regards, Salvo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 19: 5: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from ucsu.Colorado.EDU (ucsu.Colorado.EDU [128.138.129.83]) by hub.freebsd.org (Postfix) with ESMTP id BC3F937BB9D for ; Sat, 29 Apr 2000 19:04:58 -0700 (PDT) (envelope-from vinson@ucsu.Colorado.EDU) Received: from localhost (vinson@localhost) by ucsu.Colorado.EDU (8.9.3/8.9.3/ITS-5.0/standard) with SMTP id UAA09120 for ; Sat, 29 Apr 2000 20:04:54 -0600 (MDT) Date: Sat, 29 Apr 2000 20:04:54 -0600 (MDT) From: VINSON WAYNE HOWARD To: freebsd-current@freebsd.org Subject: Re: high CPU usage by xmms In-Reply-To: <200004292207.AAA04009@queeg.ludd.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I did reboot for that reason, but I retried it and got about 50. Mabey I didn't run the player long enough... > > Ok, I checked, and vmstat shows cpu usage to be quite normal, about 6% > > while playing. What's up w/ top? > > Not on my computer: > > pantzer@skalman ~ >vmstat -w 1 > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id > 4 1 0 339480 5552 131 0 0 1 147 233 0 0 288 1722 1971 6 5 89 > 1 1 0 339480 5532 8 0 0 0 0 0 3 1 312 34105 34350 16 84 0 > 1 1 0 339456 5556 5 0 0 0 6 0 0 0 321 34349 34608 10 90 0 > 1 1 0 339456 5552 5 0 0 0 0 0 0 1 321 34211 34484 12 88 0 > > > If you only run vmstat you get the average since the computer started. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 21:34:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from MexComUSA.Net (adsl-63-200-120-86.dsl.mtry01.pacbell.net [63.200.120.86]) by hub.freebsd.org (Postfix) with ESMTP id 8C41137B67C for ; Sat, 29 Apr 2000 21:33:13 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Received: from EnContacto.Net (adsl-63-200-120-84.dsl.mtry01.pacbell.net [63.200.120.84]) by MexComUSA.Net (8.9.3/8.9.3) with ESMTP id VAA85237 for ; Sat, 29 Apr 2000 21:33:10 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Message-ID: <390BB786.DACB600E@EnContacto.Net> Date: Sat, 29 Apr 2000 21:33:10 -0700 From: Edwin Culp Organization: MexComUSA.Net/EnContacto.Net X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "current@FreeBSD.ORG" Subject: WaveLan wi0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On today's current, I plugged in my WaveLan Card that I haven't used for about a week and it first has a problem with IRQ: wi0: No irq?! I added some others and it responded with: wi0: No I/O space?! Has something changed in the last few days that would cause this? My network card DE-660 just keeps plugging away, thank goodness:-) Thanks for any help, ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 22:23:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 03E3637B72E for ; Sat, 29 Apr 2000 22:23:35 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac5.wam.umd.edu (root@rac5.wam.umd.edu [128.8.10.145]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id BAA10707; Sun, 30 Apr 2000 01:23:35 -0400 (EDT) Received: from rac5.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac5.wam.umd.edu (8.9.3/8.9.3) with SMTP id BAA04565; Sun, 30 Apr 2000 01:23:30 -0400 (EDT) Received: from localhost (culverk@localhost) by rac5.wam.umd.edu (8.9.3/8.9.3) with ESMTP id BAA04559; Sun, 30 Apr 2000 01:23:30 -0400 (EDT) X-Authentication-Warning: rac5.wam.umd.edu: culverk owned process doing -bs Date: Sun, 30 Apr 2000 01:23:30 -0400 (EDT) From: Kenneth Wayne Culver To: VINSON WAYNE HOWARD Cc: freebsd-current@FreeBSD.ORG Subject: Re: high CPU usage by xmms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm also getting this behavior now. It's not the xmms binary that's taking all the cpu though... top reports it as "system" CPU usage. ================================================================= | Kenneth Culver | FreeBSD: The best OS around. | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Sat, 29 Apr 2000, VINSON WAYNE HOWARD wrote: > I did reboot for that reason, but I retried it and got about 50. Mabey I > didn't run the player long enough... > > > > > Ok, I checked, and vmstat shows cpu usage to be quite normal, about 6% > > > while playing. What's up w/ top? > > > > Not on my computer: > > > > pantzer@skalman ~ >vmstat -w 1 > > procs memory page disks faults cpu > > r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id > > 4 1 0 339480 5552 131 0 0 1 147 233 0 0 288 1722 1971 6 5 89 > > 1 1 0 339480 5532 8 0 0 0 0 0 3 1 312 34105 34350 16 84 0 > > 1 1 0 339456 5556 5 0 0 0 6 0 0 0 321 34349 34608 10 90 0 > > 1 1 0 339456 5552 5 0 0 0 0 0 0 1 321 34211 34484 12 88 0 > > > > > > If you only run vmstat you get the average since the computer started. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Apr 29 23: 0:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 6FC0C37BC58 for ; Sat, 29 Apr 2000 23:00:51 -0700 (PDT) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id BAA27769; Sun, 30 Apr 2000 01:56:56 -0400 (EDT) (envelope-from bsdx@looksharp.net) Date: Sun, 30 Apr 2000 01:56:56 -0400 (EDT) From: Adam To: Jonathan Lemon Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libstand ext2fs In-Reply-To: <20000429214311.A11995@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 29 Apr 2000, Jonathan Lemon wrote: >On Sun, Apr 30, 2000 at 11:15:47AM +0930, Greg Lehey wrote: >> On Saturday, 29 April 2000 at 13:44:08 -0700, Jonathan Lemon wrote: >> > jlemon 2000/04/29 13:44:08 PDT >> > >> > Added files: >> > lib/libstand ext2fs.c >> > Log: >> > Add ext2fs support to the loader. >> >> What's the need for this? > >It allows us to see linux partition types, and load from them; >I should be able to boot a freebsd kernel and memory image from >a pure linux box, although I've only used it to load the kernel >at this point. >-- >Jonathan Not sure if this is a silly question or not, but could the kernel somehow view a specific dir on a ext2fs disk as the freebsd root and boot a freebsd system from it? Also being able to access the stuff below the freebsd root on the ext2fs partition would be cool. Any idea how much work it might take someone to do this? An alternative would be mounting a file on the ext2fs via vn as the freebsd root containing a freebsd install on ffs or ext2. This way might make it easier to have access to the underlying ext2 and make it easier for the base linux system to populate / modify if linux has trouble with ffs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message