From owner-freebsd-current Sun Oct 19 02:22:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA29323 for current-outgoing; Sun, 19 Oct 1997 02:22:45 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA29311 for ; Sun, 19 Oct 1997 02:22:39 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA20574 for current@FreeBSD.ORG; Sun, 19 Oct 1997 11:22:38 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id LAA17247; Sun, 19 Oct 1997 11:11:16 +0200 (MET DST) Message-ID: <19971019111116.KG43454@uriah.heep.sax.de> Date: Sun, 19 Oct 1997 11:11:16 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: usable current SNAP References: <199710190055.SAA09391@Ilsa.StevesCafe.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710190055.SAA09391@Ilsa.StevesCafe.com>; from Steve Passe on Oct 18, 1997 18:55:43 -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Steve Passe wrote: > I need to bring up a web server this week using current. This needs to > be a "works first time" installation (to impress a client). Can someone > suggest a suitable current SNAP date that will install without hassle on: > > - 486dx2/66 > - SMC 8013 ISA ethercard > - WD caviar (E)IDE drive My system is from Oct 10, and except for the vn recursion bug (lockmgr panic) that happened during a `make release', i have yet to see much else to fail. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Oct 19 04:10:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA02382 for current-outgoing; Sun, 19 Oct 1997 04:10:42 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA02359 for ; Sun, 19 Oct 1997 04:10:31 -0700 (PDT) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id MAA24748; Sun, 19 Oct 1997 12:03:03 +0100 (BST) Message-Id: <199710191103.MAA24748@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Steve Passe cc: current@FreeBSD.ORG Subject: Re: usable current SNAP In-reply-to: Your message of "Sat, 18 Oct 1997 18:55:43 MDT." <199710190055.SAA09391@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Oct 1997 12:03:03 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > I need to bring up a web server this week using current. This needs to > be a "works first time" installation (to impress a client). Can someone > suggest a suitable current SNAP date that will install without hassle on: > > - 486dx2/66 > - SMC 8013 ISA ethercard > - WD caviar (E)IDE drive Don't use anything from Oct 6 to Oct 12 if you wanna use ppp :-( The Oct 14 one was ok in this respect though. (BTW, I agree w/ Greg, -stable is safer :-) > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Sun Oct 19 04:27:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA02962 for current-outgoing; Sun, 19 Oct 1997 04:27:55 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA02957 for ; Sun, 19 Oct 1997 04:27:51 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id MAA03807 for current@FreeBSD.ORG; Sun, 19 Oct 1997 12:15:09 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id MAA13503; Sun, 19 Oct 1997 12:42:03 +0200 (CEST) (envelope-from andreas) Message-ID: <19971019124203.49831@klemm.gtn.com> Date: Sun, 19 Oct 1997 12:42:03 +0200 From: Andreas Klemm To: current@FreeBSD.ORG Subject: make world stopped during make depend in perl/a2x (make -j 8) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I started make world with make -j 8 world ===> gnu/usr.bin/perl/usub --- curses.c --- /usr/bin/perl /home/src/gnu/usr.bin/perl/usub/mus /home/src/gnu/usr.bin/perl/usub/curses.mus > curses.c --- .depend --- rm -f .depend mkdep -f .depend -a -DDEBUGGING -I/home/src/gnu/usr.bin/perl/usub/../perl -I/usr/obj/usr/src/tmp/usr/include /home/src/gnu/usr.bin/perl/usub/../perl/array.c /home/src/gnu/usr.bin/perl/usub/../perl/cmd.c /home/src/gnu/usr.bin/perl/usub/../perl/cons.c /home/src/gnu/usr.bin/perl/usub/../perl/consarg.c /home/src/gnu/usr.bin/perl/usub/../perl/doarg.c /home/src/gnu/usr.bin/perl/usub/../perl/doio.c /home/src/gnu/usr.bin/perl/usub/../perl/dolist.c /home/src/gnu/usr.bin/perl/usub/../perl/dump.c /home/src/gnu/usr.bin/perl/usub/../perl/eval.c /home/src/gnu/usr.bin/perl/usub/../perl/form.c /home/src/gnu/usr.bin/perl/usub/../perl/hash.c /home/src/gnu/usr.bin/perl/usub/../perl/perl.c /home/src/gnu/usr.bin/perl/usub/../perl/perly.c /home/src/gnu/usr.bin/perl/usub/../perl/regcomp.c /home/src/gnu/usr.bin/perl/usub/../perl/regexec.c /home/src/gnu/usr.bin/perl/usub/../perl/stab.c /home/src/gnu/usr.bin/perl/usub/../perl/str.c /home/src/gnu/usr.bin/perl/usub/../perl/toke.c /home/src/gnu/usr.bin/! perl/usub/../perl/util.c /home/src/gnu/usr.bin/perl/usub/usersub.c curses.c cd /home/src/gnu/usr.bin/perl/usub; /usr/obj/usr/src/tmp/usr/bin/make _EXTRADEPEND --- _EXTRADEPEND --- echo curseperl: `cc -nostdinc -Wl,-f -O -pipe -DDEBUGGING -I/home/src/gnu/usr.bin/perl/usub/../perl -I/usr/obj/usr/src/tmp/usr/include -Wl,-lncurses -Wl,-lmytinfo -Wl,-lcrypt -Wl,-lm` >> .depend ===> gnu/usr.bin/perl/lib ===> gnu/usr.bin/perl/x2p --- a2p.c --- yacc -d /home/src/gnu/usr.bin/perl/x2p/a2p.y yacc: 231 shift/reduce conflicts mv y.tab.c a2p.c --- .depend --- rm -f .depend mkdep -f .depend -a -I/home/src/gnu/usr.bin/perl/x2p/../perl -I/usr/obj/usr/src/tmp/usr/include a2p.c /home/src/gnu/usr.bin/perl/x2p/hash.c /home/src/gnu/usr.bin/perl/x2p/str.c /home/src/gnu/usr.bin/perl/x2p/walk.c /home/src/gnu/usr.bin/perl/x2p/util.c cd /home/src/gnu/usr.bin/perl/x2p; /usr/obj/usr/src/tmp/usr/bin/make _EXTRADEPEND --- _EXTRADEPEND --- echo a2p: `cc -nostdinc -Wl,-f -O -pipe -I/home/src/gnu/usr.bin/perl/x2p/../perl -I/usr/obj/usr/src/tmp/usr/include -Wl,-lm` >> .depend ===> gnu/usr.sbin --- depend --- 1 error *** Error code 2 1 error *** Error code 2 1 error If I now go into /usr/src/gnu/usr.bin/perl I get no error: root{114} /usr/src/gnu/usr.bin/perl make -j 8 depend --- depend --- ===> perl ===> tperl ===> sperl ===> usub ===> lib ===> x2p -- Andreas Klemm powered by ,,symmetric multiprocessor FreeBSD'' andreas@klemm.gtn.com - http://www.freebsd.org/~fsmp/SMP/SMP.html andreas@FreeBSD.ORG - http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-current Sun Oct 19 04:45:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA03527 for current-outgoing; Sun, 19 Oct 1997 04:45:52 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA03522 for ; Sun, 19 Oct 1997 04:45:47 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id EAA08419; Sun, 19 Oct 1997 04:45:21 -0700 (PDT) Message-ID: <19971019044520.20475@hydrogen.nike.efn.org> Date: Sun, 19 Oct 1997 04:45:20 -0700 From: John-Mark Gurney To: Andreas Klemm Cc: current@FreeBSD.ORG Subject: Re: make world stopped during make depend in perl/a2x (make -j 8) References: <19971019124203.49831@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19971019124203.49831@klemm.gtn.com>; from Andreas Klemm on Sun, Oct 19, 1997 at 12:42:03PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm scribbled this message on Oct 19: > I started make world with make -j 8 world I had the same problem... update your source and make sure that awk is being built and installed... (awk.h had some problems that was fixed) I sync'd about 7 hours ago, and buildworld completed fine... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Sun Oct 19 06:35:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA06773 for current-outgoing; Sun, 19 Oct 1997 06:35:01 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA06759 for ; Sun, 19 Oct 1997 06:34:57 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id PAA25525 for ; Sun, 19 Oct 1997 15:35:05 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id PAA22998 for current@FreeBSD.ORG; Sun, 19 Oct 1997 15:34:35 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id PAA00323; Sun, 19 Oct 1997 15:33:26 +0200 (CEST) (envelope-from roberto) Message-ID: <19971019153325.26490@keltia.freenix.fr> Date: Sun, 19 Oct 1997 15:33:25 +0200 From: Ollivier Robert To: FreeBSD-Current Subject: Re: nullfs & current References: <645.877092309@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <645.877092309@critter.freebsd.dk>; from Poul-Henning Kamp on Fri, Oct 17, 1997 at 02:45:09PM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3728 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Poul-Henning Kamp: > Seriously, this should be the simplest layered filesystem possible, so > unless we can get that to work there is no hope for the rest of them, > so I hope somebody will spend some time on it. I made a similar experiment and the space is not reclaimed till the real filesystem is unmounted. 383 [22:16] root@keltia:ftp/pub# fsck -n /dev/rsd11a ** /dev/rsd11a (NO WRITE) ** Last Mounted on /x ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=15366 OWNER=roberto MODE=100644 SIZE=2380000 MTIME=Oct 17 22:13 1997 CLEAR? no UNREF FILE I=15428 OWNER=roberto MODE=100644 SIZE=4000 MTIME=Oct 17 22:13 1997 CLEAR? no ** Phase 5 - Check Cyl groups CLEAN FLAG NOT SET IN SUPERBLOCK FIX? no 5891 files, 605968 used, 31894 free (2550 frags, 3668 blocks, 0.4% fragmentation) The two files are the one I created. Now my FS is at 1 block free even though more than 2 MB are free. Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd11a 637862 605968 1 100% /x /x/ftp/pub 637862 605968 1 100% /sources /work/spare 851149 410611 372447 52% /sources/incoming I'm trying to read the source but I'm not very experienced with vnodes/VFS and such. After studying the code, we have unlink VOP_REMOVE null_bypass ufs_remove ufs_remove does remove the file from the directory but the refcount is still probably at one somewhere so the blocks are not reclaimed till umount time. I don't know where to look at now. I'll have to read more about the whole VFS/vnode business. It is too bad I don't have a second machine to use remote gdb... -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #36: Sat Oct 4 19:58:34 CEST 1997 From owner-freebsd-current Sun Oct 19 12:15:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA26772 for current-outgoing; Sun, 19 Oct 1997 12:15:53 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26756 for ; Sun, 19 Oct 1997 12:15:48 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id VAA25992 for ; Sun, 19 Oct 1997 21:15:38 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id VAA05193 for current@FreeBSD.ORG; Sun, 19 Oct 1997 21:15:10 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id UAA01407; Sun, 19 Oct 1997 20:43:32 +0200 (CEST) (envelope-from roberto) Message-ID: <19971019204331.46330@keltia.freenix.fr> Date: Sun, 19 Oct 1997 20:43:31 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: make world stopped during make depend in perl/a2x (make -j 8) References: <19971019124203.49831@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19971019124203.49831@klemm.gtn.com>; from Andreas Klemm on Sun, Oct 19, 1997 at 12:42:03PM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Andreas Klemm: > I started make world with make -j 8 world I used -j4 yesterday (on a UP system though) and got no error... -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Sun Oct 19 12:36:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA27891 for current-outgoing; Sun, 19 Oct 1997 12:36:22 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA27880; Sun, 19 Oct 1997 12:36:10 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA00522; Sun, 19 Oct 1997 21:35:14 +0200 (CEST) To: dyson@FreeBSD.ORG cc: grog@lemis.com (Greg Lehey), smp@csn.net, current@FreeBSD.ORG Subject: Re: usable current SNAP In-reply-to: Your message of "Sat, 18 Oct 1997 21:47:24 CDT." <199710190247.VAA01886@dyson.iquest.net> Date: Sun, 19 Oct 1997 21:35:14 +0200 Message-ID: <520.877289714@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199710190247.VAA01886@dyson.iquest.net>, "John S. Dyson" writes: >MFS doesn't work in -current, and I am working on it now. I have been >happiest with about Oct10 or so. I'll look at this rsn. What MFS does to protect it's "parent" vnode is pretty disgusting actually, and maybe not a good idea at all, -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Sun Oct 19 12:38:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA27998 for current-outgoing; Sun, 19 Oct 1997 12:38:30 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA27993 for ; Sun, 19 Oct 1997 12:38:26 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA00533; Sun, 19 Oct 1997 21:36:43 +0200 (CEST) To: Ollivier Robert cc: FreeBSD-Current Subject: Re: nullfs & current In-reply-to: Your message of "Sun, 19 Oct 1997 15:33:25 +0200." <19971019153325.26490@keltia.freenix.fr> Date: Sun, 19 Oct 1997 21:36:43 +0200 Message-ID: <531.877289803@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <19971019153325.26490@keltia.freenix.fr>, Ollivier Robert writes: > >I'm trying to read the source but I'm not very experienced with vnodes/VFS >and such. After studying the code, we have > >unlink > VOP_REMOVE > null_bypass > ufs_remove > >ufs_remove does remove the file from the directory but the refcount is >still probably at one somewhere so the blocks are not reclaimed till umount >time. I don't know where to look at now. I'll have to read more about the >whole VFS/vnode business. It is too bad I don't have a second machine to >use remote gdb... And then when the vnode comes down VOP_INACTIVE and VOP_RECLAIM will trigger the actual removal. (Somebody might have the file open, remember ?) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Sun Oct 19 12:47:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28463 for current-outgoing; Sun, 19 Oct 1997 12:47:31 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA28458; Sun, 19 Oct 1997 12:47:19 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id OAA04503; Sun, 19 Oct 1997 14:46:42 -0500 (EST) From: "John S. Dyson" Message-Id: <199710191946.OAA04503@dyson.iquest.net> Subject: Re: usable current SNAP In-Reply-To: <520.877289714@critter.freebsd.dk> from Poul-Henning Kamp at "Oct 19, 97 09:35:14 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Sun, 19 Oct 1997 14:46:42 -0500 (EST) Cc: dyson@FreeBSD.ORG, grog@lemis.com, smp@csn.net, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp said: > In message <199710190247.VAA01886@dyson.iquest.net>, "John S. Dyson" writes: > > >MFS doesn't work in -current, and I am working on it now. I have been > >happiest with about Oct10 or so. > > I'll look at this rsn. What MFS does to protect it's "parent" vnode > is pretty disgusting actually, and maybe not a good idea at all, > Cool. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Sun Oct 19 13:18:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA00125 for current-outgoing; Sun, 19 Oct 1997 13:18:46 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA29943 for ; Sun, 19 Oct 1997 13:16:32 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id WAA26038 for ; Sun, 19 Oct 1997 22:15:38 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id WAA06898 for current@FreeBSD.ORG; Sun, 19 Oct 1997 22:15:29 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id WAA02040; Sun, 19 Oct 1997 22:14:25 +0200 (CEST) (envelope-from roberto) Message-ID: <19971019221425.28468@keltia.freenix.fr> Date: Sun, 19 Oct 1997 22:14:25 +0200 From: Ollivier Robert To: FreeBSD-Current Subject: Re: nullfs & current References: <19971019153325.26490@keltia.freenix.fr> <531.877289803@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <531.877289803@critter.freebsd.dk>; from Poul-Henning Kamp on Sun, Oct 19, 1997 at 09:36:43PM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Poul-Henning Kamp: > And then when the vnode comes down VOP_INACTIVE and VOP_RECLAIM will > trigger the actual removal. (Somebody might have the file open, remember ?) That's how I understand it but in this case, the blocks are not reclaimed even though it is supposed to be the last close of the file. There is a refcount one higher than it should be. The nullfs is by itself very simple and I don't see where :-( -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Sun Oct 19 13:26:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA00465 for current-outgoing; Sun, 19 Oct 1997 13:26:42 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from conductor.synapse.net (conductor.synapse.net [199.84.54.18]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA00456 for ; Sun, 19 Oct 1997 13:26:34 -0700 (PDT) (envelope-from evanc@synapse.net) Received: (qmail 24564 invoked from network); 19 Oct 1997 20:25:14 -0000 Received: from cello.synapse.net (199.84.54.81) by conductor.synapse.net with SMTP; 19 Oct 1997 20:25:14 -0000 From: "Evan Champion" To: Subject: mmap()'ing from raw devices? Date: Sun, 19 Oct 1997 16:25:24 -0400 Message-ID: <01bcdccd$21159440$513654c7@cello.synapse.net> 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 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'd like to be able to mmap() from a block device (ie: /dev/sd3h). I know that 2.2 doesn't support this; can 3.0 do it, or could it be relatively easily fixed to do it? The application is on a CNFS news server. CNFS makes heavy use of mmap(), but otherwise has no use for a filesystem... Thanks. Evan From owner-freebsd-current Sun Oct 19 14:25:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA02886 for current-outgoing; Sun, 19 Oct 1997 14:25:20 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA02881 for ; Sun, 19 Oct 1997 14:25:15 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id QAA05089; Sun, 19 Oct 1997 16:21:15 -0500 (EST) From: "John S. Dyson" Message-Id: <199710192121.QAA05089@dyson.iquest.net> Subject: Re: nullfs & current In-Reply-To: <19971019221425.28468@keltia.freenix.fr> from Ollivier Robert at "Oct 19, 97 10:14:25 pm" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Sun, 19 Oct 1997 16:21:15 -0500 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert said: > According to Poul-Henning Kamp: > > And then when the vnode comes down VOP_INACTIVE and VOP_RECLAIM will > > trigger the actual removal. (Somebody might have the file open, remember ?) > > That's how I understand it but in this case, the blocks are not reclaimed > even though it is supposed to be the last close of the file. There is a > refcount one higher than it should be. The nullfs is by itself very simple > and I don't see where :-( > The VM system holds a reference. You have to do a vnode_pager_uncache when deleting a file. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Sun Oct 19 14:37:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA03379 for current-outgoing; Sun, 19 Oct 1997 14:37:09 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA03320 for ; Sun, 19 Oct 1997 14:35:56 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id XAA26162 for ; Sun, 19 Oct 1997 23:35:10 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id XAA09202 for current@FreeBSD.ORG; Sun, 19 Oct 1997 23:35:01 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id XAA03650; Sun, 19 Oct 1997 23:32:43 +0200 (CEST) (envelope-from roberto) Message-ID: <19971019233243.25894@keltia.freenix.fr> Date: Sun, 19 Oct 1997 23:32:43 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: nullfs & current References: <19971019221425.28468@keltia.freenix.fr> <199710192121.QAA05089@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710192121.QAA05089@dyson.iquest.net>; from John S. Dyson on Sun, Oct 19, 1997 at 04:21:15PM -0500 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to John S. Dyson: > The VM system holds a reference. You have to do a vnode_pager_uncache when > deleting a file. Wait... Isn't ufs_remove() supposed to do that ? ufs_remove() is called by null_bypass() by an indirect call (VCALL()) and it seemed safe to consider that the lower level was supposed to DTR. Do I have to create a null_remove() function in order to call vnode_pager_uncache inside it ? -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Sun Oct 19 16:35:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08836 for current-outgoing; Sun, 19 Oct 1997 16:35:28 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08825 for ; Sun, 19 Oct 1997 16:35:19 -0700 (PDT) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id BAA00469; Mon, 20 Oct 1997 01:41:01 +0200 (CEST) From: Mikael Karpberg Message-Id: <199710192341.BAA00469@ocean.campus.luth.se> Subject: Re: usable current SNAP In-Reply-To: <19971019114225.54861@lemis.com> from Greg Lehey at "Oct 19, 97 11:42:25 am" To: grog@lemis.com (Greg Lehey) Date: Mon, 20 Oct 1997 01:41:01 +0200 (CEST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Greg Lehey: > On Sat, Oct 18, 1997 at 08:02:08PM -0600, Steve Passe wrote: > > Hi, > > > >>> I need to bring up a web server this week using current. This needs to > >>> be a "works first time" installation (to impress a client). > >> > >> I don't understand this. This is *not* the purpose of -current. To > >> quote: > >> ... > > > > Yes, I know all this, I'm one of the people doing development work > > with 3.0-current, I won't be back complaining that xxx doesn't work! > > And your customers? > > > I have various assorted reasons, I just would like to here "I installed > > SNAP-9710xx and all went well" from someone b4 grabbing > > the tarballs... > > Oh well. The last two weeks I built -current, and it seems to be > working fine. More specifically, I supped on the 9th and the 16th. I just installed 3.0-971012-SNAP and it went very nice and smooth, except for dying in the post-installation menu when I tried to get packages. If you just install, reboot, and fix packages later, if shouldn't be a problem. :-) I had no problem with it dying either, actually, since it just meant I had to remove the disk, wait for the system to boot, and install packages later. The bug is fixed in later SNAPs, Jordan reports. But MFS is broken there. :-( /Mikael From owner-freebsd-current Sun Oct 19 17:10:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10895 for current-outgoing; Sun, 19 Oct 1997 17:10:25 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mail.inconnect.com (mail.inconnect.com [207.173.163.7] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA10880 for ; Sun, 19 Oct 1997 17:10:21 -0700 (PDT) (envelope-from gribnif@inconnect.com) Received: (qmail 8613 invoked from network); 20 Oct 1997 00:07:26 -0000 Received: from www.wasatchrecreation.com (HELO ultra1) (209.140.65.101) by mail.inconnect.com with SMTP; 20 Oct 1997 00:07:26 -0000 Date: Sun, 19 Oct 1997 18:07:26 -0600 (MDT) From: Jason Morrow X-Sender: gribnif@ultra1 To: stable@freebsd.org cc: current@freebsd.org Subject: Next release Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk when will 2.2.5 be released as current? -- Jason Morrow | UNIX, MS-Dos and Windows gribnif@inconnect.com | (the good, the bad and the ugly...) From owner-freebsd-current Sun Oct 19 17:38:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12781 for current-outgoing; Sun, 19 Oct 1997 17:38:11 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mail.uniserve.com (dns1-van.uniserve.com [204.244.163.48]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA12759; Sun, 19 Oct 1997 17:38:04 -0700 (PDT) (envelope-from tom@uniserve.com) Received: from shell.uniserve.com [204.244.210.252] by mail.uniserve.com with smtp (Exim 1.70 #1) id 0xN5r7-0007Ky-00; Sun, 19 Oct 1997 17:38:01 -0700 Date: Sun, 19 Oct 1997 17:37:56 -0700 (PDT) From: Tom To: Jason Morrow cc: stable@freebsd.org, current@freebsd.org Subject: Re: Next release In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 19 Oct 1997, Jason Morrow wrote: > when will 2.2.5 be released as current? 2.2.5 will be released in 2 days. Jordon has been posting regular updates, so I'm not why you missed them. I don't understand, "released as current". > -- > Jason Morrow | UNIX, MS-Dos and Windows > gribnif@inconnect.com | (the good, the bad and the ugly...) Tom From owner-freebsd-current Sun Oct 19 18:43:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16374 for current-outgoing; Sun, 19 Oct 1997 18:43:20 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16364 for ; Sun, 19 Oct 1997 18:43:11 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id UAA05747; Sun, 19 Oct 1997 20:43:01 -0500 (EST) From: "John S. Dyson" Message-Id: <199710200143.UAA05747@dyson.iquest.net> Subject: Re: nullfs & current In-Reply-To: <19971019233243.25894@keltia.freenix.fr> from Ollivier Robert at "Oct 19, 97 11:32:43 pm" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Sun, 19 Oct 1997 20:43:01 -0500 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert said: > According to John S. Dyson: > > The VM system holds a reference. You have to do a vnode_pager_uncache when > > deleting a file. > > Wait... Isn't ufs_remove() supposed to do that ? ufs_remove() is called by > null_bypass() by an indirect call (VCALL()) and it seemed safe to consider > that the lower level was supposed to DTR. > > Do I have to create a null_remove() function in order to call > vnode_pager_uncache inside it ? > nullfs should really share the VM object with the lower filesystem, but generally what you say is true, even if you don't share the object. The complexity is one reason that I haven't fixed it. It IS fixable reasonably though. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Sun Oct 19 23:10:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA00911 for current-outgoing; Sun, 19 Oct 1997 23:10:33 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from freebie.dcfinc.com (freebie.dcfinc.com [138.113.2.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA00906; Sun, 19 Oct 1997 23:10:29 -0700 (PDT) (envelope-from chad@freebie.dcfinc.com) Received: (from chad@localhost) by freebie.dcfinc.com (8.8.3/8.8.3a) id XAA07989; Sun, 19 Oct 1997 23:09:44 -0700 (MST) From: "Chad R. Larson" Message-Id: <199710200609.XAA07989@freebie.dcfinc.com> Subject: Re: Next release To: tom@uniserve.com (Tom) Date: Sun, 19 Oct 1997 23:09:42 -0700 (MST) Cc: gribnif@inconnect.com, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from Tom at "Oct 19, 97 05:37:56 pm" Reply-to: chad@dcfinc.com X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sun, 19 Oct 1997, Jason Morrow wrote: > > when will 2.2.5 be released as current? > 2.2.5 will be released in 2 days. Jordon has been posting regular > updates, so I'm not why you missed them. And how much later should we expect our Walnut Creek subscriptions to deliver? -crl -- Chad R. Larson (CRL22) Brother, can you paradigm? 602-953-1392 chad@dcfinc.com chad@anasazi.com crl22@aol.com DCF, Inc. - 14523 North 49th Place, Scottsdale, Arizona 85254 From owner-freebsd-current Mon Oct 20 00:14:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA04284 for current-outgoing; Mon, 20 Oct 1997 00:14:51 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04279 for ; Mon, 20 Oct 1997 00:14:48 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z13) with ESMTP id JAA29714 for ; Mon, 20 Oct 1997 09:15:16 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id JAA00300 for freebsd-current@freefall.cdrom.com; Mon, 20 Oct 1997 09:24:08 +0200 (MEST) Date: Mon, 20 Oct 1997 09:24:08 +0200 (MEST) From: Christoph Kukulies Message-Id: <199710200724.JAA00300@gil.physik.rwth-aachen.de> To: freebsd-current@freefall.FreeBSD.org Subject: bad system call - world build Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I tried to build a world again and got stuck while near being trough: uudecode < /a/src/share/tabset/xerox1730-lm.uu uudecode < /a/src/share/tabset/zenith29.uu ===> share/termcap ex - /a/src/share/termcap/termcap.src < /a/src/share/termcap/reorder > /dev/null Bad system call - core dumped *** Error code 140 Stop. *** Error code 1 (This is on a 2.2.2-RELEASE system) Is it some kind of hen-egg problem? Would building a kernel first lead to other problems? Or am I just out of sync with cvsup? -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Mon Oct 20 00:26:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA05024 for current-outgoing; Mon, 20 Oct 1997 00:26:00 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA05015; Mon, 20 Oct 1997 00:25:53 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id AAA24022; Mon, 20 Oct 1997 00:28:26 -0700 (PDT) Message-Id: <199710200728.AAA24022@implode.root.com> To: chad@dcfinc.com cc: tom@uniserve.com (Tom), gribnif@inconnect.com, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Next release In-reply-to: Your message of "Sun, 19 Oct 1997 23:09:42 PDT." <199710200609.XAA07989@freebie.dcfinc.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 20 Oct 1997 00:28:26 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> On Sun, 19 Oct 1997, Jason Morrow wrote: >> > when will 2.2.5 be released as current? >> 2.2.5 will be released in 2 days. Jordon has been posting regular >> updates, so I'm not why you missed them. > >And how much later should we expect our Walnut Creek subscriptions >to deliver? Probably about 3 weeks, although this is the busy time of year for CDROM replication so predicting this accurately is difficult. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Mon Oct 20 00:39:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA05659 for current-outgoing; Mon, 20 Oct 1997 00:39:23 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from gated.unibest.ru (gated.unibest.ru [194.87.33.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA05636 for ; Mon, 20 Oct 1997 00:39:17 -0700 (PDT) (envelope-from hole.etrust.ru!unibest.ru!osa) Received: (qmail 27848 invoked from network); 20 Oct 1997 07:39:07 -0000 Received: from gated.unibest.ru (HELO hole.etrust.ru) (root@194.87.33.5) by gated.unibest.ru with SMTP; 20 Oct 1997 07:39:07 -0000 Received: from unibest.ru by hole.etrust.ru with ESMTP id LAA00563; (8.8.4/vak/1.9) Mon, 20 Oct 1997 11:41:08 +0400 (MSD) Message-ID: <344B0B12.43295F22@unibest.ru> Date: Mon, 20 Oct 1997 11:41:06 +0400 From: Ozz Reply-To: osa@unibest.ru Organization: JSCB Unibest X-Mailer: Mozilla 4.02b7 [en] (X11; I; FreeBSD 3.0-970124-SNAP i386) MIME-Version: 1.0 To: current@FreeBSD.ORG CC: questions@FreeBSD.ORG Subject: How update from 970124 to last SNAP ???? Plz help! Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello all! Sorry for bad English... I have a old SNAP-version. Its a FreeBSD-3.0-970124-SNAP wiz soursez I wanna this version to latest SNAP. As I know I may downloaded more everydays updates... Where I can get that files... In ftp.freebsd.org/pub/FreeBSD/CTM I see updates from 25 May version of SNAP What can I do???? Plz help me. Rgds, Ozz, osa@unibest.ru FreeBSD: Turn your PC into workstation... From owner-freebsd-current Mon Oct 20 01:03:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA06978 for current-outgoing; Mon, 20 Oct 1997 01:03:39 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA06973 for ; Mon, 20 Oct 1997 01:03:34 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA14774; Mon, 20 Oct 1997 01:03:01 -0700 (PDT) Message-ID: <19971020010301.36211@hydrogen.nike.efn.org> Date: Mon, 20 Oct 1997 01:03:01 -0700 From: John-Mark Gurney To: Christoph Kukulies Cc: freebsd-current@freefall.FreeBSD.org Subject: Re: bad system call - world build References: <199710200724.JAA00300@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710200724.JAA00300@gil.physik.rwth-aachen.de>; from Christoph Kukulies on Mon, Oct 20, 1997 at 09:24:08AM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Christoph Kukulies scribbled this message on Oct 20: > > I tried to build a world again and got stuck while near being trough: > > uudecode < /a/src/share/tabset/xerox1730-lm.uu > uudecode < /a/src/share/tabset/zenith29.uu > ===> share/termcap > ex - /a/src/share/termcap/termcap.src < /a/src/share/termcap/reorder > /dev/null > Bad system call - core dumped > *** Error code 140 > > Stop. > *** Error code 1 > > > (This is on a 2.2.2-RELEASE system) > > Is it some kind of hen-egg problem? Would building a kernel first > lead to other problems? Or am I just out of sync with cvsup? well.. I you could do what I do, add an option NOTERMCAP that will prevent the build from decending into the termcap dir.. I do a buildworld on a 2.2.1-R box and haven't spent the time trying to figure out what syscall nvi is running that doesn't exist in 2.2.x... hope this helps... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Mon Oct 20 01:26:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA08361 for current-outgoing; Mon, 20 Oct 1997 01:26:27 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA08344 for ; Mon, 20 Oct 1997 01:26:22 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id KAA08695; Mon, 20 Oct 1997 10:25:50 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id JAA00222; Mon, 20 Oct 1997 09:38:59 +0200 (CEST) To: Ollivier Robert cc: FreeBSD-Current Subject: Re: nullfs & current In-reply-to: Your message of "Sun, 19 Oct 1997 22:14:25 +0200." <19971019221425.28468@keltia.freenix.fr> Date: Mon, 20 Oct 1997 09:38:58 +0200 Message-ID: <220.877333138@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <19971019221425.28468@keltia.freenix.fr>, Ollivier Robert writes: >According to Poul-Henning Kamp: >> And then when the vnode comes down VOP_INACTIVE and VOP_RECLAIM will >> trigger the actual removal. (Somebody might have the file open, remember ?) > >That's how I understand it but in this case, the blocks are not reclaimed >even though it is supposed to be the last close of the file. There is a >refcount one higher than it should be. The nullfs is by itself very simple >and I don't see where :-( You have to try to track all instances of "WILLRELE" across the nullfs bypass routine to catch this one. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Oct 20 01:26:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA08368 for current-outgoing; Mon, 20 Oct 1997 01:26:28 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA08346 for ; Mon, 20 Oct 1997 01:26:23 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id KAA08698; Mon, 20 Oct 1997 10:25:51 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id JAA00257; Mon, 20 Oct 1997 09:41:32 +0200 (CEST) To: "John S. Dyson" cc: roberto@keltia.freenix.fr (Ollivier Robert), current@FreeBSD.ORG Subject: Re: nullfs & current In-reply-to: Your message of "Sun, 19 Oct 1997 16:21:15 CDT." <199710192121.QAA05089@dyson.iquest.net> Date: Mon, 20 Oct 1997 09:41:32 +0200 Message-ID: <255.877333292@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199710192121.QAA05089@dyson.iquest.net>, "John S. Dyson" writes: >Ollivier Robert said: >> According to Poul-Henning Kamp: >> > And then when the vnode comes down VOP_INACTIVE and VOP_RECLAIM will >> > trigger the actual removal. (Somebody might have the file open, remember >?) >> >> That's how I understand it but in this case, the blocks are not reclaimed >> even though it is supposed to be the last close of the file. There is a >> refcount one higher than it should be. The nullfs is by itself very simple >> and I don't see where :-( >> >The VM system holds a reference. You have to do a vnode_pager_uncache when >deleting a file. Which in this case means VOP_RECLAIM, right ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Oct 20 01:26:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA08399 for current-outgoing; Mon, 20 Oct 1997 01:26:34 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA08345 for ; Mon, 20 Oct 1997 01:26:23 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id KAA08701; Mon, 20 Oct 1997 10:25:51 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id JAA00408; Mon, 20 Oct 1997 09:47:57 +0200 (CEST) To: "John S. Dyson" cc: roberto@keltia.freenix.fr (Ollivier Robert), current@FreeBSD.ORG Subject: Re: nullfs & current In-reply-to: Your message of "Sun, 19 Oct 1997 20:43:01 CDT." <199710200143.UAA05747@dyson.iquest.net> Date: Mon, 20 Oct 1997 09:47:57 +0200 Message-ID: <406.877333677@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199710200143.UAA05747@dyson.iquest.net>, "John S. Dyson" writes: >Ollivier Robert said: >> According to John S. Dyson: >> > The VM system holds a reference. You have to do a vnode_pager_uncache whe >n >> > deleting a file. >> >> Wait... Isn't ufs_remove() supposed to do that ? ufs_remove() is called by >> null_bypass() by an indirect call (VCALL()) and it seemed safe to consider >> that the lower level was supposed to DTR. >> >> Do I have to create a null_remove() function in order to call >> vnode_pager_uncache inside it ? >> >nullfs should really share the VM object with the lower filesystem, but genera >lly >what you say is true, even if you don't share the object. The complexity is >one reason that I haven't fixed it. It IS fixable reasonably though. No, this is wrong. Nullfs can only share the VM object if the permissions are the same, consider a read-only mounted nullfs for instance. calling vnode_pager_uncache() null_remove() would be wrong, the file may still be open. In FFS we only call vnode_pager_uncache in ffs_unmount()... Whatever needs to be done should probably be done in null_inactive(), look at sys/ufs/ufs/ufs_inode.c:ufs_inactive(). -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Oct 20 01:30:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA08805 for current-outgoing; Mon, 20 Oct 1997 01:30:32 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA08800; Mon, 20 Oct 1997 01:30:28 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id BAA07879; Mon, 20 Oct 1997 01:30:37 -0700 (PDT) To: chad@dcfinc.com cc: tom@uniserve.com (Tom), gribnif@inconnect.com, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Next release In-reply-to: Your message of "Sun, 19 Oct 1997 23:09:42 PDT." <199710200609.XAA07989@freebie.dcfinc.com> Date: Mon, 20 Oct 1997 01:30:37 -0700 Message-ID: <7875.877336237@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > On Sun, 19 Oct 1997, Jason Morrow wrote: > > > when will 2.2.5 be released as current? > > 2.2.5 will be released in 2 days. Jordon has been posting regular > > updates, so I'm not why you missed them. > > And how much later should we expect our Walnut Creek subscriptions > to deliver? That depends largely on the replicator, over whom we've next to no control. I'm certainly hoping CDs will be back and shipping by the 2nd week of November. Jordan From owner-freebsd-current Mon Oct 20 01:48:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09676 for current-outgoing; Mon, 20 Oct 1997 01:48:23 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09671 for ; Mon, 20 Oct 1997 01:48:17 -0700 (PDT) (envelope-from helbig@Informatik.BA-Stuttgart.DE) Received: (from helbig@localhost) by rvc1.informatik.ba-stuttgart.de (8.8.7/8.8.5) id KAA26936; Mon, 20 Oct 1997 10:48:14 +0200 (MET DST) From: Wolfgang Helbig Message-Id: <199710200848.KAA26936@rvc1.informatik.ba-stuttgart.de> Subject: Re: bad system call - world build In-Reply-To: <199710200724.JAA00300@gil.physik.rwth-aachen.de> from Christoph Kukulies at "Oct 20, 97 09:24:08 am" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Mon, 20 Oct 1997 10:48:14 +0200 (MET DST) Cc: freebsd-current@freefall.FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I tried to build a world again and got stuck while near being trough: > > uudecode < /a/src/share/tabset/xerox1730-lm.uu > uudecode < /a/src/share/tabset/zenith29.uu > ===> share/termcap > ex - /a/src/share/termcap/termcap.src < /a/src/share/termcap/reorder > /dev/null > Bad system call - core dumped > *** Error code 140 > > Stop. > *** Error code 1 > > > (This is on a 2.2.2-RELEASE system) > > Is it some kind of hen-egg problem? Would building a kernel first > lead to other problems? Or am I just out of sync with cvsup? I was hit by the same dump when trying to build a -current world on a 2.2.2-RELEASE system. I deleted the termcaps directory from the SUBDIR list in src/share/Makefile, saved the changed Makefile under the name makefile and build the world successfully . During install the missing network group in /etc/group stopped again the show. I add the line network:*:69: in /etc/group and installed the world successfully. Then I rebuilt the kernel from -current sources, rebooted and everything worked fine. This was on a friend's system, who wanted to try an smp kernel. He keeps on talking me into buying a multiprocessor board since then :-) Wolfgang From owner-freebsd-current Mon Oct 20 01:56:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA10090 for current-outgoing; Mon, 20 Oct 1997 01:56:17 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA10085 for ; Mon, 20 Oct 1997 01:56:13 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id SAA14627; Mon, 20 Oct 1997 18:25:54 +0930 (CST) Message-ID: <19971020182554.43127@lemis.com> Date: Mon, 20 Oct 1997 18:25:54 +0930 From: Greg Lehey To: Christoph Kukulies Cc: freebsd-current@freefall.FreeBSD.org Subject: Re: bad system call - world build References: <199710200724.JAA00300@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199710200724.JAA00300@gil.physik.rwth-aachen.de>; from Christoph Kukulies on Mon, Oct 20, 1997 at 09:24:08AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Oct 20, 1997 at 09:24:08AM +0200, Christoph Kukulies wrote: > > I tried to build a world again and got stuck while near being trough: > > uudecode < /a/src/share/tabset/xerox1730-lm.uu > uudecode < /a/src/share/tabset/zenith29.uu > ===> share/termcap > ex - /a/src/share/termcap/termcap.src < /a/src/share/termcap/reorder > /dev/null > Bad system call - core dumped > *** Error code 140 > > Stop. > *** Error code 1 > > > (This is on a 2.2.2-RELEASE system) > > Is it some kind of hen-egg problem? Would building a kernel first > lead to other problems? Or am I just out of sync with cvsup? This is almost a FAQ. Build a new kernel first, boot with it, then you should be able to continue. Greg From owner-freebsd-current Mon Oct 20 03:56:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA15067 for current-outgoing; Mon, 20 Oct 1997 03:56:02 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA15049 for ; Mon, 20 Oct 1997 03:55:55 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id FAA01099; Mon, 20 Oct 1997 05:55:35 -0500 (EST) From: "John S. Dyson" Message-Id: <199710201055.FAA01099@dyson.iquest.net> Subject: Re: nullfs & current In-Reply-To: <406.877333677@critter.freebsd.dk> from Poul-Henning Kamp at "Oct 20, 97 09:47:57 am" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Oct 1997 05:55:35 -0500 (EST) Cc: toor@dyson.iquest.net, roberto@keltia.freenix.fr, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp said: > In message <199710200143.UAA05747@dyson.iquest.net>, "John S. Dyson" writes: > >Ollivier Robert said: > >> According to John S. Dyson: > >> > The VM system holds a reference. You have to do a vnode_pager_uncache whe > >n > >> > deleting a file. > >> > >> Wait... Isn't ufs_remove() supposed to do that ? ufs_remove() is called by > >> null_bypass() by an indirect call (VCALL()) and it seemed safe to consider > >> that the lower level was supposed to DTR. > >> > >> Do I have to create a null_remove() function in order to call > >> vnode_pager_uncache inside it ? > >> > >nullfs should really share the VM object with the lower filesystem, but genera > >lly > >what you say is true, even if you don't share the object. The complexity is > >one reason that I haven't fixed it. It IS fixable reasonably though. > > No, this is wrong. Nullfs can only share the VM object if the > permissions are the same, consider a read-only mounted nullfs for > instance. > The VM object should be shared to maintain coherency. Permissions are maintained by the VM_MAP layer. Objects are mosly globs of data. For some apps, an object can be RO, and others RW. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Mon Oct 20 05:43:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA19510 for current-outgoing; Mon, 20 Oct 1997 05:43:35 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA19500 for ; Mon, 20 Oct 1997 05:43:29 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z13) with ESMTP id OAA08337; Mon, 20 Oct 1997 14:43:52 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id OAA01268; Mon, 20 Oct 1997 14:52:43 +0200 (MEST) Message-ID: <19971020145243.29303@gil.physik.rwth-aachen.de> Date: Mon, 20 Oct 1997 14:52:43 +0200 From: Christoph Kukulies To: Greg Lehey Cc: Christoph Kukulies , freebsd-current@freefall.FreeBSD.org Subject: Re: bad system call - world build References: <199710200724.JAA00300@gil.physik.rwth-aachen.de> <19971020182554.43127@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19971020182554.43127@lemis.com>; from Greg Lehey on Mon, Oct 20, 1997 at 06:25:54PM +0930 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Oct 20, 1997 at 06:25:54PM +0930, Greg Lehey wrote: > On Mon, Oct 20, 1997 at 09:24:08AM +0200, Christoph Kukulies wrote: > > > > I tried to build a world again and got stuck while near being trough: > > > > uudecode < /a/src/share/tabset/xerox1730-lm.uu > > uudecode < /a/src/share/tabset/zenith29.uu > > ===> share/termcap > > ex - /a/src/share/termcap/termcap.src < /a/src/share/termcap/reorder > /dev/null > > Bad system call - core dumped > > *** Error code 140 > > > > Stop. > > *** Error code 1 > > > > > > (This is on a 2.2.2-RELEASE system) > > > > Is it some kind of hen-egg problem? Would building a kernel first > > lead to other problems? Or am I just out of sync with cvsup? > > This is almost a FAQ. Build a new kernel first, boot with it, then > you should be able to continue. Not quite, Greg. Normally I know what to do when proc.h has been changed (ps/w etc. weirdnesses) but in this case I'm not sure whether building a new kernel (3.0-current) and booting it on top of a set of (up to then) 2.2.2-binaries would be a could remedy here. I will more likely follow the advice of your forespeaker, namely excluding the termcap subdir from the worldbuild. > > Greg -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Mon Oct 20 06:32:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA22237 for current-outgoing; Mon, 20 Oct 1997 06:32:36 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from g23.relcom.ru (g23.relcom.ru [193.125.152.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA22228 for ; Mon, 20 Oct 1997 06:32:21 -0700 (PDT) (envelope-from maxim@mas2000.msk.ru) Received: from prfbank1-dawn1.ll.relcom.ru (prfbank1-dawn1.ll.relcom.ru [193.124.250.145]) by g23.relcom.ru (8.7.5.R.ML.S/Relcom-2A) with SMTP id RAA18128 for ;Mon, 20 Oct 1997 17:18:21 +0400 (MSD) Received: from [100.0.0.52] by diamond.mas2000.msk.ru (NTMail 3.02.13) with ESMTP id ea003462 for ; Mon, 20 Oct 1997 16:15:20 +0300 Message-Id: <3.0.32.19971020051141.006a2e14@100.0.0.2> X-Sender: maxim@100.0.0.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Oct 1997 05:11:41 +0300 To: current@FreeBSD.ORG From: Maxim Surdu Subject: SMP on next release? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Will the next release support SMP ?? Thanx in advance. Maxim Surdu From owner-freebsd-current Mon Oct 20 07:38:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA26152 for current-outgoing; Mon, 20 Oct 1997 07:38:14 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA26138 for ; Mon, 20 Oct 1997 07:38:00 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id AAA01025; Tue, 21 Oct 1997 00:03:13 +0930 (CST) Message-Id: <199710201433.AAA01025@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Christoph Kukulies cc: Greg Lehey , freebsd-current@freefall.FreeBSD.org Subject: Re: bad system call - world build In-reply-to: Your message of "Mon, 20 Oct 1997 14:52:43 +0200." <19971020145243.29303@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 00:03:06 +0930 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > ===> share/termcap > > > ex - /a/src/share/termcap/termcap.src < /a/src/share/termcap/reorder > /dev/null > > > Bad system call - core dumped ... > > This is almost a FAQ. Build a new kernel first, boot with it, then > > you should be able to continue. > > Not quite, Greg. Normally I know what to do when proc.h has been changed > (ps/w etc. weirdnesses) but in this case I'm not sure whether > building a new kernel (3.0-current) and booting it on top of a > set of (up to then) 2.2.2-binaries would be a could remedy here. Funnily enough, Greg is quite right. I almost feel that I'm insulting him by backing him up, but Chris, this *is* a FAQ, and if you were reading the -current list like you're supposed to, you would know all about this. You do need a newer kernel to get past this. The issue *was*announced* when the change was made. There was some attempt made to put in place code to deal with the new system call, but it appears to have been unsuccessful and at any rate is only needed for the bootstrapping case. Going from 2.x to 3.x is going to get harder, not easier. > I will more likely follow the advice of your forespeaker, namely > excluding the termcap subdir from the worldbuild. This is stupid, and fails to address the problem. mike From owner-freebsd-current Mon Oct 20 08:55:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA00693 for current-outgoing; Mon, 20 Oct 1997 08:55:31 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA00675 for ; Mon, 20 Oct 1997 08:55:22 -0700 (PDT) (envelope-from ken@plutotech.com) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id JAA12676; Mon, 20 Oct 1997 09:55:00 -0600 (MDT) From: Kenneth Merry Message-Id: <199710201555.JAA12676@pluto.plutotech.com> Subject: Re: SMP on next release? In-Reply-To: <3.0.32.19971020051141.006a2e14@100.0.0.2> from Maxim Surdu at "Oct 20, 97 05:11:41 am" To: maxim@mas2000.msk.ru (Maxim Surdu) Date: Mon, 20 Oct 1997 09:55:00 -0600 (MDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Maxim Surdu wrote... > Will the next release support SMP ?? > Thanx in advance. Well, the next release is 2.2.5, and it will not support SMP. The first release with SMP will be 3.0. Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-current Mon Oct 20 10:43:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA08165 for current-outgoing; Mon, 20 Oct 1997 10:43:43 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA08011 for ; Mon, 20 Oct 1997 10:40:16 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id TAA30015 for ; Mon, 20 Oct 1997 19:38:42 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id TAA15273 for current@FreeBSD.ORG; Mon, 20 Oct 1997 19:38:11 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id TAA07274; Mon, 20 Oct 1997 19:35:40 +0200 (CEST) (envelope-from roberto) Message-ID: <19971020193540.39453@keltia.freenix.fr> Date: Mon, 20 Oct 1997 19:35:40 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: nullfs & current References: <199710200143.UAA05747@dyson.iquest.net> <406.877333677@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <406.877333677@critter.freebsd.dk>; from Poul-Henning Kamp on Mon, Oct 20, 1997 at 09:47:57AM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Poul-Henning Kamp: > calling vnode_pager_uncache() null_remove() would be wrong, the file > may still be open. Right. > Whatever needs to be done should probably be done in null_inactive(), > look at sys/ufs/ufs/ufs_inode.c:ufs_inactive(). Hmmm, what about an null_remove() that: 1. refuses if the nullfs is mounted read-only, 2. call VOP_REMOVE() for lowervp VOP_REMOVE() seems more right here. Except that: how am I supposed to get hold of the 3 arguments for ufs_remove() ? I can't just give it my own (null_remove) arguments... Can I call ufs_inactive (through VOP_INACTIVE()) with lowervp ? (somewhere I don't think so and I'd have to get host of the current proc pointer anyway). When is VOP_RECLAIM() supposed to be called ? In the daemon book, it is said that VOP_RECLAIM() is called by getnewvnode() when it decides to reuse a vnode. I hope I'm not too bothersome here but I'm really trying to understand how all that stuff is supposed to work... My feeling is unlink() VOP_REMOVE(vp) aka null_bypass() for now VOP_REMOVE(lowervp) aka ufs_remove() vrele(vp) I could be wrong of course. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Mon Oct 20 11:37:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA11840 for current-outgoing; Mon, 20 Oct 1997 11:37:57 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA11830 for ; Mon, 20 Oct 1997 11:37:50 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id NAA11707; Mon, 20 Oct 1997 13:37:27 -0500 (EST) From: "John S. Dyson" Message-Id: <199710201837.NAA11707@dyson.iquest.net> Subject: Re: nullfs & current In-Reply-To: <19971020193540.39453@keltia.freenix.fr> from Ollivier Robert at "Oct 20, 97 07:35:40 pm" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Mon, 20 Oct 1997 13:37:27 -0500 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert said: > According to Poul-Henning Kamp: > > calling vnode_pager_uncache() null_remove() would be wrong, the file > > may still be open. > > Right. > Not quite. I was wrong there, but the underlying object that is pointed to BOTH the nullfs layer and the underlying error should have it's reference count decreased. If the reference count of the object is ONE, and the VNODE is referred to only by that object, then the vnode_pager_uncache should be done. Please don't break coherency!!! -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Mon Oct 20 13:46:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18805 for current-outgoing; Mon, 20 Oct 1997 13:46:42 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18785; Mon, 20 Oct 1997 13:46:10 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (spork@localhost) by super-g.inch.com (8.8.7/8.8.5) with SMTP id UAA15278; Mon, 20 Oct 1997 20:42:18 -0400 (EDT) Date: Mon, 20 Oct 1997 20:42:18 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: dyson@FreeBSD.ORG cc: Greg Lehey , current@FreeBSD.ORG Subject: Re: usable current SNAP In-Reply-To: <199710190259.VAA01896@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, Since everyone's on the topic, how about this application: I need to build a big database server, and am looking to run it on a dual-processor machine. The database we need to use is mysql, which I believe can take advantage of 3.0's threads... Is this wise or not? Charles On Sat, 18 Oct 1997, John S. Dyson wrote: > Greg Lehey said: > > On Sat, Oct 18, 1997 at 06:55:43PM -0600, Steve Passe wrote: > > > Hi, > > > > > > I need to bring up a web server this week using current. This needs to > > > be a "works first time" installation (to impress a client). > > > > I don't understand this. This is *not* the purpose of -current. To > > quote: > > > (good comments from Greg deleted) > > > > > If you want to impress a customer, I would have thought that -stable > > would be a much better choice. > > > The only point that I might disagree with you on is that there are times > that there are necessary features in -current. Basically, with -current > the person who uses it is on their own. Hopefully, those who use it don't > end up giving FreeBSD a bad reputation because of the pre-Alpha/Alpha/Beta > quality of the code. Important features would be practically the only > reason for violating the "rule." -stable and -current aren't that far > away in performance (it isn't like 2.1 vs. 2.2.), 2.2 and 3.0 are pretty > close. > > My opinion is that those who use -current in production get absolutely > no sympathy from me (or most others on the team.) However, some people > who are actively contributing to FreeBSD get quite a bit more leeway (I am > willing to go further out of my way to help) than others. (They are more > likely to understand the state of the code, and are generally willing and > able to help us all more in solving problems that they encounter.) > > But, in general, I agree that it is not a very good idea to use -current > in production without understanding that the support issues are significant. > The FreeBSD group of developers are already overloaded, and simply do not > need the additional problems of supporting -current. > > There is very little more irritating than to be coerced to fix a bug that > isn't ready to be fixed yet. > > -- > John > dyson@freebsd.org > jdyson@nc.com > From owner-freebsd-current Mon Oct 20 13:59:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19632 for current-outgoing; Mon, 20 Oct 1997 13:59:22 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from chess.inetspace.com (chess.inetspace.com [206.50.163.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19624 for ; Mon, 20 Oct 1997 13:59:14 -0700 (PDT) (envelope-from kgor@chess.inetspace.com) Received: (from kgor@localhost) by chess.inetspace.com (8.8.5/8.7.3) id PAA02008; Mon, 20 Oct 1997 15:58:37 -0500 (CDT) Date: Mon, 20 Oct 1997 15:58:37 -0500 (CDT) Message-Id: <199710202058.PAA02008@chess.inetspace.com> From: "Kent S. Gordon" To: current@FreeBSD.ORG Subject: 2.2.5-BETA Hangs in Boot, 2.2.2 works Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am running 2.2.2 successfully, but when I try and boot the GENERIC boot floppy from 2.2.5-BETA (2.2.5-971018-BETA) the machine hangs after the waiting for scsi devices to settle message. I had a similar problem when running -current in april, but the problem has now migrated to the proposed STABLE release. I have no problems with either the GENERIC or custom kernels on 2.2.2. I have the dmesg output and kernel config from my current 2.2.2 kernel. dmesg output -- Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2-STABLE #0: Fri May 16 19:21:22 CDT 1997 kgor@chess.inetspace.com:/usr/src/sys/compile/CHESS Calibrating clock(s) ... i8254 clock: 1193757 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CPU: i486DX (486-class CPU) real memory = 33554432 (32768K bytes) avail memory = 30670848 (29952K bytes) Probing for devices on the ISA bus: sc0: the current keyboard controller command byte 0045 kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa sc0 at 0x60-0x6f irq 1 on motherboard sc0: BIOS video mode:3 sc0: VGA registers upon power-up 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 ff ff 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: video mode:24 sc0: VGA registers for mode:24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 5 on isa ed0: address 00:00:e8:cb:ac:1a, type NE2000 (16 bit) bpf: ed0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in bt0: Bt445S/ 0-ISA(24bit) bus bt0: Your card cannot DMA above 16MB boundary. Bounce buffering enabled. bt0: reading board settings, dma=5, int=11 bt0: version 3.36, fast sync, parity, 32 mbxs, 32 ccbs bt0: targ 0 sync rate=10.00MB/s(100ns), offset=15 bt0: targ 1 sync rate=10.00MB/s(100ns), offset=15 bt0: Using Strict Round robin scheme bt0 at 0x330 irq 11 drq 5 on isa (bt0:0:0): "DEC DSP5200S T392" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 1908MB (3907911 512 byte sectors) sd0(bt0:0:0): with 2621 cyls, 21 heads, and an average 71 sectors/track (bt0:1:0): "SEAGATE ST31200N 8648" type 0 fixed SCSI 2 sd1(bt0:1:0): Direct-Access 1006MB (2061108 512 byte sectors) sd1(bt0:1:0): with 2700 cyls, 9 heads, and an average 84 sectors/track npx0 on motherboard npx0: INT 16 interface imasks: bio c0000840, tty c003009a, net c0020020 BIOS Geometries: 0:03ff3f20 0..1023=1024 cylinders, 0..63=64 heads, 1..32=32 sectors 1:03ed3f20 0..1005=1006 cylinders, 0..63=64 heads, 1..32=32 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. changing root device to sd0a configure() finished. bpf: tun0 attached bpf: lo0 attached sd0s1: type 0xa5, start 32, end = 3907583, size 3907552 : OK sd1s1: type 0xa5, start 32, end = 2060287, size 2060256 : OK ed0: promiscuous mode enabled kernel config file -- # # GGZOO -- Cyrix 586/100 with BT controller # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: CHESS,v 1.1 1997/04/07 21:35:16 kgor Exp $ machine "i386" #cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" #cpu "I686_CPU" ident GGZOO maxusers 10 options DDB options DIAGNOSTIC options SCSIDEBUG #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem #options NFS #Network Filesystem #options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] #options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device #options SCSI_DELAY=5 #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SYSVSHM options SYSVSEM options SYSVMSG options "AUTO_EOI_1" #faster interrupts config kernel root on wd0 controller isa0 #I have a VLB, but no aha28xx cards, that think they are on a eisa bus. #controller eisa0 #controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 #tape ft0 at fdc0 drive 2 #controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr #disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 #controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 #options ATAPI #Enable ATAPI support for IDE bus #options ATAPI_STATIC #Don't do it as an LKM #device wcd0 #IDE CD-ROM # A single entry for any of these controllers (ncr, ahb, ahc) is sufficient # for any number of installed devices. #controller ncr0 #controller ahb0 #controller ahc0 controller bt0 at isa? port "IO_BT0" bio irq ? vector bt_isa_intr #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr #controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr #controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr #controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 #device od0 #See LINT for possible `od' options. #device st0 device cd0 #Only need one of these, the code dynamically grows device ch0 #SCSI media changers #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr #controller matcd0 at isa? port 0x230 bio #device scd0 at isa? port 0x230 bio # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 #options XSERVER # include code for XFree86 #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 # Mandatory, don't remove device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # #device apm0 at isa? disable # Advanced Power Management #options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS # PCCARD (PCMCIA) support #controller crd0 #device pcic0 at crd? #device pcic1 at crd? device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr #device sio2 at isa? disable port "IO_COM3" tty irq 5 vector siointr #device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr #device lpt1 at isa? port? tty #device mse0 at isa? port 0x23c tty irq 5 vector mseintr #device psm0 at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. #device de0 #device fxp0 #device vx0 #device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr #device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr device ed0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr #device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr #device ep0 at isa? port 0x300 net irq 10 vector epintr #device fe0 at isa? port 0x300 net irq ? vector feintr #device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr #device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr #device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr pseudo-device loop pseudo-device ether pseudo-device log #pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 32 pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing Any help would be appreciated. Thanks, Kent S. Gordon Senior Software Engineer iNetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com From owner-freebsd-current Mon Oct 20 14:08:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20091 for current-outgoing; Mon, 20 Oct 1997 14:08:18 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from freebie.dcfinc.com (freebie.dcfinc.com [138.113.2.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20085; Mon, 20 Oct 1997 14:08:12 -0700 (PDT) (envelope-from chad@freebie.dcfinc.com) Received: (from chad@localhost) by freebie.dcfinc.com (8.8.3/8.8.3a) id OAA08815; Mon, 20 Oct 1997 14:06:17 -0700 (MST) From: "Chad R. Larson" Message-Id: <199710202106.OAA08815@freebie.dcfinc.com> Subject: Re: Next release To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 20 Oct 1997 14:06:16 -0700 (MST) Cc: chad@dcfinc.com, tom@uniserve.com, gribnif@inconnect.com, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <7875.877336237@time.cdrom.com> from "Jordan K. Hubbard" at "Oct 20, 97 01:30:37 am" Reply-to: chad@dcfinc.com X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > On Sun, 19 Oct 1997, Jason Morrow wrote: > > > > when will 2.2.5 be released as current? > > > 2.2.5 will be released in 2 days. Jordon has been posting regular > > > updates, so I'm not why you missed them. > > > > And how much later should we expect our Walnut Creek subscriptions > > to deliver? > > That depends largely on the replicator, over whom we've next to no > control. I'm certainly hoping CDs will be back and shipping by > the 2nd week of November. Just out of curiosity, who is responsible for the duplicating and artwork? Does FreeBSD give a master to a duplicator, and then sell the completed product to Walnut Creek? Or does Walnut Creek get the master? -crl -- Chad R. Larson (CRL22) Brother, can you paradigm? 602-953-1392 chad@dcfinc.com chad@anasazi.com crl22@aol.com DCF, Inc. - 14523 North 49th Place, Scottsdale, Arizona 85254 From owner-freebsd-current Mon Oct 20 15:59:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA26509 for current-outgoing; Mon, 20 Oct 1997 15:59:41 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA26491 for ; Mon, 20 Oct 1997 15:59:27 -0700 (PDT) (envelope-from helbig@Informatik.BA-Stuttgart.DE) Received: (from helbig@localhost) by rvc1.informatik.ba-stuttgart.de (8.8.7/8.8.5) id AAA27784; Tue, 21 Oct 1997 00:28:40 +0200 (MET DST) From: Wolfgang Helbig Message-Id: <199710202228.AAA27784@rvc1.informatik.ba-stuttgart.de> Subject: Re: bad system call - world build In-Reply-To: <199710201433.AAA01025@word.smith.net.au> from Mike Smith at "Oct 21, 97 00:03:06 am" To: mike@smith.net.au (Mike Smith) Date: Tue, 21 Oct 1997 00:28:40 +0200 (MET DST) Cc: kuku@gilberto.physik.RWTH-Aachen.DE, grog@lemis.com, freebsd-current@freefall.FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > ===> share/termcap > > > > ex - /a/src/share/termcap/termcap.src < /a/src/share/termcap/reorder > /dev/null > > > > Bad system call - core dumped > ... > > > This is almost a FAQ. Build a new kernel first, boot with it, then > > > you should be able to continue. > > > > Not quite, Greg. Normally I know what to do when proc.h has been changed > > (ps/w etc. weirdnesses) but in this case I'm not sure whether > > building a new kernel (3.0-current) and booting it on top of a > > set of (up to then) 2.2.2-binaries would be a could remedy here. > > Funnily enough, Greg is quite right. I almost feel that I'm insulting > him by backing him up, but Chris, this *is* a FAQ, and if you were > reading the -current list like you're supposed to, you would know all > about this. > > You do need a newer kernel to get past this. The issue *was*announced* > when the change was made. There was some attempt made to put in place > code to deal with the new system call, but it appears to have been > unsuccessful and at any rate is only needed for the bootstrapping case. > Going from 2.x to 3.x is going to get harder, not easier. > > > I will more likely follow the advice of your forespeaker, namely > > excluding the termcap subdir from the worldbuild. > > This is stupid, and fails to address the problem. Hmm. As far as I recall, we had some interface change of mount(8) in -current about half year ago which made it impossible to successfully mount with a new kernel and old userland environmemt. So even if this is a FAQ the answer depends... Most of the time building userland first gives you less trouble than building the kernel first. Just think about outdated config(8) which is still part of userland. I don't think my suggestion is that stupid. Wolfgang From owner-freebsd-current Mon Oct 20 16:40:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA29000 for current-outgoing; Mon, 20 Oct 1997 16:40:12 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28821 for ; Mon, 20 Oct 1997 16:37:52 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id JAA02439; Tue, 21 Oct 1997 09:02:54 +0930 (CST) Message-Id: <199710202332.JAA02439@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Wolfgang Helbig cc: freebsd-current@freefall.FreeBSD.org Subject: Re: bad system call - world build In-reply-to: Your message of "Tue, 21 Oct 1997 00:28:40 +0200." <199710202228.AAA27784@rvc1.informatik.ba-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 09:02:50 +0930 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I will more likely follow the advice of your forespeaker, namely > > > excluding the termcap subdir from the worldbuild. > > > > This is stupid, and fails to address the problem. > > Hmm. As far as I recall, we had some interface change of > mount(8) in -current about half year ago which made it > impossible to successfully mount with a new kernel and old userland > environmemt. Yup. And it was announced, and lots of people *obviously* didn't read the announcement, and were yelled at, and some of them appear to have learned their lesson. It's a slow process. > So even if this is a FAQ the answer depends... No it _doesn't_. *This*particular*build*problem* is an FAQ. > I don't think my suggestion is that stupid. It's stupid because it a) ignores the published information on the problem, b) ignores the nature of the problem, and c) introduces other potential problems. Much easier just to do the right thing to begin with. mike From owner-freebsd-current Mon Oct 20 17:12:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01173 for current-outgoing; Mon, 20 Oct 1997 17:12:47 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from adsdevelop.autodebit.com (adsdevelop.autodebit.com [204.50.245.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA01167 for ; Mon, 20 Oct 1997 17:12:45 -0700 (PDT) (envelope-from davidg@autodebit.com) Received: by adsdevelop.autodebit.com with Microsoft Exchange (IMC 4.0.837.3) id <01BCDD7B.0CA64370@adsdevelop.autodebit.com>; Mon, 20 Oct 1997 17:10:22 -0700 Message-ID: From: David Green-Seed To: "'current@freebsd.org'" Subject: RE: usable current SNAP Date: Mon, 20 Oct 1997 17:10:20 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I believe that mysql uses MIT-pthreads which is a user-level threads package... This _probably_ means that the threads will run within the context of one kernel thread only - ie: only one thread runs at a time. I'm not sure, so you might want to verify this one. Dave. _________________________ David Green-Seed davidg@autodebit.com Automated Debit Systems >-----Original Message----- >From: spork [SMTP:spork@super-g.com] >Sent: Monday, October 20, 1997 5:42 PM >To: dyson@FreeBSD.ORG >Cc: Greg Lehey; current@FreeBSD.ORG >Subject: Re: usable current SNAP > >Hello, > >Since everyone's on the topic, how about this application: > >I need to build a big database server, and am looking to run it on a >dual-processor machine. The database we need to use is mysql, which I >believe can take advantage of 3.0's threads... > >Is this wise or not? > >Charles > >On Sat, 18 Oct 1997, John S. Dyson wrote: > >> Greg Lehey said: >> > On Sat, Oct 18, 1997 at 06:55:43PM -0600, Steve Passe wrote: >> > > Hi, >> > > >> > > I need to bring up a web server this week using current. This needs to >> > > be a "works first time" installation (to impress a client). >> > >> > I don't understand this. This is *not* the purpose of -current. To >> > quote: >> > >> (good comments from Greg deleted) >> >> > >> > If you want to impress a customer, I would have thought that -stable >> > would be a much better choice. >> > >> The only point that I might disagree with you on is that there are times >> that there are necessary features in -current. Basically, with -current >> the person who uses it is on their own. Hopefully, those who use it don't >> end up giving FreeBSD a bad reputation because of the pre-Alpha/Alpha/Beta >> quality of the code. Important features would be practically the only >> reason for violating the "rule." -stable and -current aren't that far >> away in performance (it isn't like 2.1 vs. 2.2.), 2.2 and 3.0 are pretty >> close. >> >> My opinion is that those who use -current in production get absolutely >> no sympathy from me (or most others on the team.) However, some people >> who are actively contributing to FreeBSD get quite a bit more leeway (I am >> willing to go further out of my way to help) than others. (They are more >> likely to understand the state of the code, and are generally willing and >> able to help us all more in solving problems that they encounter.) >> >> But, in general, I agree that it is not a very good idea to use -current >> in production without understanding that the support issues are >>significant. >> The FreeBSD group of developers are already overloaded, and simply do not >> need the additional problems of supporting -current. >> >> There is very little more irritating than to be coerced to fix a bug that >> isn't ready to be fixed yet. >> >> -- >> John >> dyson@freebsd.org >> jdyson@nc.com >> > From owner-freebsd-current Mon Oct 20 18:04:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA05367 for current-outgoing; Mon, 20 Oct 1997 18:04:49 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA05362 for ; Mon, 20 Oct 1997 18:04:43 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by earth.mat.net (8.8.7/8.6.12) with SMTP id VAA08431; Mon, 20 Oct 1997 21:04:23 -0400 (EDT) Date: Mon, 20 Oct 1997 20:04:23 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: David Green-Seed cc: "'current@freebsd.org'" Subject: RE: usable current SNAP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 20 Oct 1997, David Green-Seed wrote: > I believe that mysql uses MIT-pthreads which is a user-level threads > package... This _probably_ means that the threads will run within the > context of one kernel thread only - ie: only one thread runs at a time. > I'm not sure, so you might want to verify this one. Let's keep this reasonably close. FreeBSD does not yet have kernel threads, period. The rest of your comment is right, I think, in spirit, but don't toss the thread word around like that, not when you're already using it to refer to pthreads, which aren't kernel threads. Any thread running today on FreeBSD is (must be) running in the context of a single process at a time. Of course, that point about threads could change, tomorrow, but it's right as of this moment. > > Dave. > _________________________ > David Green-Seed > davidg@autodebit.com > Automated Debit Systems > > >-----Original Message----- > >From: spork [SMTP:spork@super-g.com] > >Sent: Monday, October 20, 1997 5:42 PM > >To: dyson@FreeBSD.ORG > >Cc: Greg Lehey; current@FreeBSD.ORG > >Subject: Re: usable current SNAP > > > >Hello, > > > >Since everyone's on the topic, how about this application: > > > >I need to build a big database server, and am looking to run it on a > >dual-processor machine. The database we need to use is mysql, which I > >believe can take advantage of 3.0's threads... > > > >Is this wise or not? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Mon Oct 20 18:39:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07356 for current-outgoing; Mon, 20 Oct 1997 18:39:34 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07337 for ; Mon, 20 Oct 1997 18:39:16 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id SAA27685; Mon, 20 Oct 1997 18:37:30 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd027680; Mon Oct 20 18:37:24 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA24623; Mon, 20 Oct 1997 18:37:21 -0700 (MST) From: Terry Lambert Message-Id: <199710210137.SAA24623@usr08.primenet.com> Subject: Re: lockmgr panic To: bde@zeta.org.au (Bruce Evans) Date: Tue, 21 Oct 1997 01:37:21 +0000 (GMT) Cc: freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de In-Reply-To: <199710160509.PAA08005@godzilla.zeta.org.au> from "Bruce Evans" at Oct 16, 97 03:09:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Speaking of bandaids, would anybody mind me committing Mr. KATO's > >fix/hack? (Of course, unless he's going to commit it himself.) The > >patch seems to solve the vn(4) lockmgr problem. > > I think it substitutes panics with deadlock possibilities. Perhaps > the deadlocks are rare. > > >I haven't made a release on a 2.2.5-BETA system lately. If the > >problem there is the same, i would vote for moving the fix there as > > I think the problem is the same but the symptoms are worse - endless > recursion and at best a panic for a double fault. The recursion is only one deep. The only failure case I could sww was if you were paging to the vn device that was locked. That's can't happen *AND* hit that code path, since that code path requires that a disklabel and a filesystem be present on the vn device (and therefore not swap). You *might* be able to trigger it by vnconfiging a vnode device on an fs on a vnode device; I haven't followed the code path in that case. I think that particular case is really unlikely. See my analysis following the original posting of the patch; I think the patch is good, and the problem is in the way the locking in VOP_ADVLOCK is implemented as a call-down interface. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Oct 20 18:41:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07577 for current-outgoing; Mon, 20 Oct 1997 18:41:49 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07570 for ; Mon, 20 Oct 1997 18:41:41 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id SAA28177; Mon, 20 Oct 1997 18:41:40 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd028168; Mon Oct 20 18:41:38 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA24915; Mon, 20 Oct 1997 18:41:28 -0700 (MST) From: Terry Lambert Message-Id: <199710210141.SAA24915@usr08.primenet.com> Subject: Re: lockmgr panic To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 21 Oct 1997 01:41:28 +0000 (GMT) Cc: bde@zeta.org.au, j@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG In-Reply-To: from "Simon Shapiro" at Oct 16, 97 00:09:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >Speaking of bandaids, would anybody mind me committing Mr. KATO's > > >fix/hack? (Of course, unless he's going to commit it himself.) The > > >patch seems to solve the vn(4) lockmgr problem. > > > > I think it substitutes panics with deadlock possibilities. Perhaps > > the deadlocks are rare. > > Nope. Easy to do. Sometimes during boot. There is a timong or hardware > component to this, as we see it in the manufacturing lab; Same disk, same > install, replace a motherboard and its gone. The patch affects only the vnconfig'ed devices. I have a hard time believing even someone as talentd as you could boot off of one of these things... ;-). There *are* deadlock conditions having to do with lockmgr races, but they are extremely unlikely. Are oyu perhaps mixing SCSI and IDE drives to trigger the problem you are seeing? Or one very fast and one very slow SCSI drive? Or multiple SCSI controllers, etc.? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Oct 20 23:21:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22324 for current-outgoing; Mon, 20 Oct 1997 23:21:45 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22310 for ; Mon, 20 Oct 1997 23:21:41 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA13852 for freebsd-current@FreeBSD.ORG; Tue, 21 Oct 1997 08:21:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id HAA16935; Tue, 21 Oct 1997 07:50:48 +0200 (MET DST) Message-ID: <19971021075048.IY27565@uriah.heep.sax.de> Date: Tue, 21 Oct 1997 07:50:48 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Subject: Re: lockmgr panic References: <199710160509.PAA08005@godzilla.zeta.org.au> <199710210137.SAA24623@usr08.primenet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710210137.SAA24623@usr08.primenet.com>; from Terry Lambert on Oct 21, 1997 01:37:21 +0000 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > See my analysis following the original posting of the patch; I think > the patch is good, and the problem is in the way the locking in VOP_ADVLOCK > is implemented as a call-down interface. Well, this your mail had just only one failure: it has been sent half an hour after the proclaimed cut-off date for 2.2.5. :) Thanks to Nate, who's got the heart to commit the patch right in time... Ok, now Mr. KATO can also commit it to -current, but that's not half as urgent. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Oct 20 23:57:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24251 for current-outgoing; Mon, 20 Oct 1997 23:57:02 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA24243 for ; Mon, 20 Oct 1997 23:56:56 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id QAA07277; Tue, 21 Oct 1997 16:51:05 +1000 Date: Tue, 21 Oct 1997 16:51:05 +1000 From: Bruce Evans Message-Id: <199710210651.QAA07277@godzilla.zeta.org.au> To: joerg_wunsch@uriah.heep.sax.de, kato@migmatite.eps.nagoya-u.ac.jp Subject: Re: lockmgr panic Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I don't have any idea to solve this problem except: > > a. rewrite delayed write stuff. > b. rewrite vn driver. > c. apply the patch included in this mail. > >The patch from 3.0-current is as follows: `isvplocked' seems to be used uninitialized. Someone committed a modified version of this to 2.2 without testing it in -current (without even committing it to -current). Bruce From owner-freebsd-current Tue Oct 21 00:42:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26690 for current-outgoing; Tue, 21 Oct 1997 00:42:45 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from eclogite.eps.nagoya-u.ac.jp (eclogite.eps.nagoya-u.ac.jp [133.6.57.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26674 for ; Tue, 21 Oct 1997 00:42:27 -0700 (PDT) (envelope-from kato@eclogite.eps.nagoya-u.ac.jp) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by eclogite.eps.nagoya-u.ac.jp (8.8.7/3.3W9) with ESMTP id QAA11910; Tue, 21 Oct 1997 16:44:39 +0900 (JST) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl5) with ESMTP id QAA13712; Tue, 21 Oct 1997 16:42:14 +0900 (JST) Message-Id: <199710210742.QAA13712@gneiss.eps.nagoya-u.ac.jp> To: bde@zeta.org.au Cc: freebsd-current@freebsd.org Subject: Re: lockmgr panic From: KATO Takenori In-Reply-To: Your message of "Tue, 21 Oct 1997 16:51:05 +1000" References: <199710210651.QAA07277@godzilla.zeta.org.au> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Oct 1997 16:42:14 +0900 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > `isvplocked' seems to be used uninitialized. Fixed in revision 1.41.2.3. > Someone committed a modified version of this to 2.2 without testing > it in -current (without even committing it to -current). I think the patch is OK and it can be in current for testing. How do you think about Terry's comment? ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Tue Oct 21 00:55:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27576 for current-outgoing; Tue, 21 Oct 1997 00:55:51 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA27570 for ; Tue, 21 Oct 1997 00:55:48 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id RAA09631 for current@freebsd.org; Tue, 21 Oct 1997 17:54:35 +1000 Date: Tue, 21 Oct 1997 17:54:35 +1000 From: Bruce Evans Message-Id: <199710210754.RAA09631@godzilla.zeta.org.au> To: current@freebsd.org Subject: Re: cvs commit: src/sbin/i386/mount_msdos Makefile Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >bde 1997/10/21 00:26:53 PDT > > Modified files: > sbin/i386/mount_msdos Makefile > Log: > Don't install mount_msdos setuid root. Lite2's mount(2) handles > permissions centrally and a setuid root mount utility just breaks > its security. There was no new breakage in practice because > mfdosfs_mount() still checks the ruid. ... but msdosfsmount() will be fixed RSN and you should reinstall mount_msdos first. Bruce From owner-freebsd-current Tue Oct 21 01:02:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28051 for current-outgoing; Tue, 21 Oct 1997 01:02:06 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28046 for ; Tue, 21 Oct 1997 01:02:03 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id SAA09840; Tue, 21 Oct 1997 18:00:39 +1000 Date: Tue, 21 Oct 1997 18:00:39 +1000 From: Bruce Evans Message-Id: <199710210800.SAA09840@godzilla.zeta.org.au> To: bde@zeta.org.au, kato@migmatite.eps.nagoya-u.ac.jp Subject: Re: lockmgr panic Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I think the patch is OK and it can be in current for testing. >How do you think about Terry's comment? Parts of it disagree with my reality :-). I've seen endless recursion in vnstrategy(). The locks stop it in -current, but in 2.2 recursive locking is sometimes allowed. I didn't think about the other parts. Bruce From owner-freebsd-current Tue Oct 21 07:12:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14475 for current-outgoing; Tue, 21 Oct 1997 07:12:54 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14260 for ; Tue, 21 Oct 1997 07:08:51 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id IAA21964; Tue, 21 Oct 1997 08:07:11 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id IAA05571; Tue, 21 Oct 1997 08:07:09 -0600 (MDT) Date: Tue, 21 Oct 1997 08:07:09 -0600 (MDT) Message-Id: <199710211407.IAA05571@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bruce Evans Cc: joerg_wunsch@uriah.heep.sax.de, kato@migmatite.eps.nagoya-u.ac.jp, freebsd-current@freebsd.org Subject: Re: lockmgr panic In-Reply-To: <199710210651.QAA07277@godzilla.zeta.org.au> References: <199710210651.QAA07277@godzilla.zeta.org.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I don't have any idea to solve this problem except: > > > > a. rewrite delayed write stuff. > > b. rewrite vn driver. > > c. apply the patch included in this mail. > > > >The patch from 3.0-current is as follows: > > `isvplocked' seems to be used uninitialized. > > Someone committed a modified version of this to 2.2 without testing > it in -current (without even committing it to -current). It was tested by quite a few people in 2.2, so that's why I committed it to only 2.2. :) Nate From owner-freebsd-current Tue Oct 21 10:50:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA28394 for current-outgoing; Tue, 21 Oct 1997 10:50:21 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from oxmail4.ox.ac.uk (oxmail4.ox.ac.uk [163.1.2.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA28366 for ; Tue, 21 Oct 1997 10:50:06 -0700 (PDT) (envelope-from neil.long@materials.oxford.ac.uk) Received: from njl2.materials.ox.ac.uk by oxmail4 with SMTP (PP); Tue, 21 Oct 1997 18:49:57 +0100 Received: by njl2.materials.ox.ac.uk (950413.SGI.8.6.12/940406.SGI) for freebsd-current@freefall.FreeBSD.org id SAA08351; Tue, 21 Oct 1997 18:49:55 +0100 From: neil.long@materials.oxford.ac.uk (Neil J Long) Message-Id: <199710211749.SAA08351@njl2.materials.ox.ac.uk> Subject: 2.2.5 GENERIC kernel problem? X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1 To: freebsd-current@freefall.freebsd.org Date: Tue, 21 Oct 1997 18:49:55 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi I think I am at 2.2.5 (cvsupd 2_2_RELENG as of Oct 21) and I was building a GENERIC kernel to install on a machine I plan to installworld from 2.1.5 - user just left, I put it off too long...) Is there a tag for 2.2.5 for cvsup? Anyway, I did the usual cd /sys/i386/conf config GENERIC cd ../../compile/GENERIC make depend cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I../../../include -DAPM_BROKEN_STATCLOCK -DFAILSAFE -DCOMPAT_43 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -DMAXUSERS=10 -UKERNEL ../../i386/i386/genassym.c cc -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I../../../include -DAPM_BROKEN_STATCLOCK -DFAILSAFE -DCOMPAT_43 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -DMAXUSERS=10 genassym.o -o genassym ./genassym >assym.s rm -f param.c cp ../../conf/param.c . sh ../../kern/vnode_if.sh ../../kern/vnode_if.src make -f ../../dev/aic7xxx/Makefile MAKESRCPATH=../../dev/aic7xxx Warning: Object directory not changed from original /sys/compile/GENERIC yacc -d ../../dev/aic7xxx/aicasm_gram.y mv y.tab.c aicasm_gram.c cc -O -I. -c aicasm_gram.c lex -t ../../dev/aic7xxx/aicasm_scan.l > aicasm_scan.c cc -O -I. -c aicasm_scan.c ../../dev/aic7xxx/aicasm_scan.l: In function `yylex': ../../dev/aic7xxx/aicasm_scan.l:68: `T_DOWNLOAD' undeclared (first use this function) ../../dev/aic7xxx/aicasm_scan.l:68: (Each undeclared identifier is reported only once ../../dev/aic7xxx/aicasm_scan.l:68: for each function it appears in.) *** Error code 1 Stop. *** Error code 1 Stop. maybe I missed something and am betwixt and between ?? I have no problem with my usual kernel which has a lot of devices configured out. Neil From owner-freebsd-current Tue Oct 21 11:40:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA02548 for current-outgoing; Tue, 21 Oct 1997 11:40:23 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA02534 for ; Tue, 21 Oct 1997 11:40:12 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id UAA00607 for ; Tue, 21 Oct 1997 20:39:30 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id UAA05658 for current@FreeBSD.ORG; Tue, 21 Oct 1997 20:39:12 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id UAA00626; Tue, 21 Oct 1997 20:38:08 +0200 (CEST) (envelope-from roberto) Message-ID: <19971021203807.51847@keltia.freenix.fr> Date: Tue, 21 Oct 1997 20:38:07 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! References: <199710200143.UAA05747@dyson.iquest.net> <406.877333677@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <406.877333677@critter.freebsd.dk>; from Poul-Henning Kamp on Mon, Oct 20, 1997 at 09:47:57AM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Poul-Henning Kamp: > Whatever needs to be done should probably be done in null_inactive(), > look at sys/ufs/ufs/ufs_inode.c:ufs_inactive(). By using the following patch, I've been able to create and delete hundreds of files in a nullfs mounted directory. No vnode leak as far as I can see from the sysctl debug.numvnodes. fsck reports no missing blocks. No panic, just works. Now that seems too easy :-) I know there is a comment in null_inactive() about doing nothing in there but it seemed logical to inform the lower layer... PS: a similar problem is in umapfs which is based on nullfs. Opinions about this ? Index: null_vnops.c =================================================================== RCS file: /spare/FreeBSD-current/src/sys/miscfs/nullfs/null_vnops.c,v retrieving revision 1.24 diff -u -2 -r1.24 null_vnops.c --- null_vnops.c 1997/10/15 10:04:31 1.24 +++ null_vnops.c 1997/10/21 18:31:52 @@ -534,4 +534,7 @@ } */ *ap; { + struct vnode *vp = ap->a_vp; + struct null_node *xp = VTONULL(vp); + struct vnode *lowervp = xp->null_lowervp; /* * Do nothing (and _don't_ bypass). @@ -546,4 +549,5 @@ * That's too much work for now. */ + VOP_INACTIVE(lowervp, ap->a_p); VOP_UNLOCK(ap->a_vp, 0, ap->a_p); return (0); -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Tue Oct 21 12:45:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05528 for current-outgoing; Tue, 21 Oct 1997 12:45:28 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05521 for ; Tue, 21 Oct 1997 12:45:14 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA00696; Tue, 21 Oct 1997 21:44:11 +0200 (CEST) To: Ollivier Robert cc: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! In-reply-to: Your message of "Tue, 21 Oct 1997 20:38:07 +0200." <19971021203807.51847@keltia.freenix.fr> Date: Tue, 21 Oct 1997 21:44:09 +0200 Message-ID: <694.877463049@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk By the powers vested in us, we hereby announce that as of this _____Tir 21 Okt 1997 21:35:09 CEST____ it has been satisfied to us that the attached email fully and entirely prove to us that the insight and persistence needed for successful VFS hacking is present in the necessary amount in _____Mr Ollivier Robert _____ and therefore let it be know that he from this day on in his good right to carry the title of _____ VFS hacker ____ with all the rights, duties, priviledges and ensignia that goes with this title. Poul-Henning Kamp PS: I trust that you commit the fix yourself ? PPS: Yes, umapfs probably also needs this. PPPS: would you mind looking at unionfs or lfs next ? please ? :-) >According to Poul-Henning Kamp: >> Whatever needs to be done should probably be done in null_inactive(), >> look at sys/ufs/ufs/ufs_inode.c:ufs_inactive(). > >By using the following patch, I've been able to create and delete hundreds >of files in a nullfs mounted directory. No vnode leak as far as I can see >from the sysctl debug.numvnodes. fsck reports no missing blocks. No panic, >just works. Now that seems too easy :-) > >I know there is a comment in null_inactive() about doing nothing in there >but it seemed logical to inform the lower layer... > >PS: a similar problem is in umapfs which is based on nullfs. > >Opinions about this ? > >Index: null_vnops.c >=================================================================== >RCS file: /spare/FreeBSD-current/src/sys/miscfs/nullfs/null_vnops.c,v >retrieving revision 1.24 >diff -u -2 -r1.24 null_vnops.c >--- null_vnops.c 1997/10/15 10:04:31 1.24 >+++ null_vnops.c 1997/10/21 18:31:52 >@@ -534,4 +534,7 @@ > } */ *ap; > { >+ struct vnode *vp = ap->a_vp; >+ struct null_node *xp = VTONULL(vp); >+ struct vnode *lowervp = xp->null_lowervp; > /* > * Do nothing (and _don't_ bypass). >@@ -546,4 +549,5 @@ > * That's too much work for now. > */ >+ VOP_INACTIVE(lowervp, ap->a_p); > VOP_UNLOCK(ap->a_vp, 0, ap->a_p); > return (0); > >-- >Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr >FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Tue Oct 21 14:14:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10035 for current-outgoing; Tue, 21 Oct 1997 14:14:42 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from oxmail4.ox.ac.uk (oxmail4.ox.ac.uk [163.1.2.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA10030 for ; Tue, 21 Oct 1997 14:14:39 -0700 (PDT) (envelope-from neil.long@materials.oxford.ac.uk) Received: from njl2.materials.ox.ac.uk by oxmail4 with SMTP (PP); Tue, 21 Oct 1997 22:14:34 +0100 Received: by njl2.materials.ox.ac.uk (950413.SGI.8.6.12/940406.SGI) for freebsd-current@freefall.freebsd.org id WAA08711; Tue, 21 Oct 1997 22:14:28 +0100 From: neil.long@materials.oxford.ac.uk (Neil J Long) Message-Id: <199710212114.WAA08711@njl2.materials.ox.ac.uk> Subject: Re: 2.2.5 GENERIC kernel problem? In-Reply-To: <199710211749.SAA08351@njl2.materials.ox.ac.uk> from "Neil J Long" at "Oct 21, 97 06:49:55 pm" X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1 To: freebsd-current@freefall.freebsd.org Date: Tue, 21 Oct 1997 22:14:28 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi The make in ../../dev/aic7xxx/ goes fine IF I run a make in that directory. That is, it wouldn't run without errors when done from the /sys/compile/GENERIC directory but once done in aic7xxx further makes above it are fine. I haven't built a GENERIC in a while and the changes in aic7xxx all post-date my last one. Cheers Neil From owner-freebsd-current Tue Oct 21 14:36:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA11363 for current-outgoing; Tue, 21 Oct 1997 14:36:10 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10733 for ; Tue, 21 Oct 1997 14:28:24 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id XAA00867 for ; Tue, 21 Oct 1997 23:27:01 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id XAA10291 for current@FreeBSD.ORG; Tue, 21 Oct 1997 23:26:29 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id XAA01685; Tue, 21 Oct 1997 23:26:17 +0200 (CEST) (envelope-from roberto) Message-ID: <19971021232617.35959@keltia.freenix.fr> Date: Tue, 21 Oct 1997 23:26:17 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! References: <19971021203807.51847@keltia.freenix.fr> <694.877463049@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <694.877463049@critter.freebsd.dk>; from Poul-Henning Kamp on Tue, Oct 21, 1997 at 09:44:09PM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Poul-Henning Kamp: > PS: I trust that you commit the fix yourself ? Done. > PPS: Yes, umapfs probably also needs this. Done. > PPPS: would you mind looking at unionfs or lfs next ? please ? :-) Union why not, but LFS is too big a fish for me to fry... I'll let John fix LFS... -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Tue Oct 21 15:23:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13827 for current-outgoing; Tue, 21 Oct 1997 15:23:16 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA13816 for ; Tue, 21 Oct 1997 15:23:11 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA23005 for freebsd-current@FreeBSD.ORG; Wed, 22 Oct 1997 00:23:10 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id AAA18599; Wed, 22 Oct 1997 00:00:53 +0200 (MET DST) Message-ID: <19971022000053.ZR34581@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 00:00:53 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Subject: Re: lockmgr panic References: <199710210651.QAA07277@godzilla.zeta.org.au> <199710210742.QAA13712@gneiss.eps.nagoya-u.ac.jp> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710210742.QAA13712@gneiss.eps.nagoya-u.ac.jp>; from KATO Takenori on Oct 21, 1997 16:42:14 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As KATO Takenori wrote: > > Someone committed a modified version of this to 2.2 without testing > > it in -current (without even committing it to -current). > > I think the patch is OK and it can be in current for testing. Unlike what Nate assumed, i'm using it on -current anyway. I've got one panic again, but now think that's because of the uninitialized variable bug. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Oct 21 16:21:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17310 for current-outgoing; Tue, 21 Oct 1997 16:21:17 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from pegas.carrier.kiev.ua (root@pegas.carrier.kiev.ua [193.193.193.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17300 for ; Tue, 21 Oct 1997 16:21:08 -0700 (PDT) (envelope-from archer@grape.carrier.kiev.ua) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.193.193.101]) by pegas.carrier.kiev.ua (8.8.5/8.Who.Cares/Open) with ESMTP id CAA00609 for ; Wed, 22 Oct 1997 02:29:58 +0300 (EEST) Received: (from uucp@localhost) by sivka.carrier.kiev.ua (8.8.7/8.8.7) with UUCP id CAA02530 for freebsd-current@freebsd.org; Wed, 22 Oct 1997 02:16:19 +0300 (EEST) Received: (from archer@localhost) by grape.carrier.kiev.ua (8.8.7/8.8.7) id CAA28244; Wed, 22 Oct 1997 02:07:31 +0300 (EEST) Message-ID: <19971022020728.32083@grape.carrier.kiev.ua> Date: Wed, 22 Oct 1997 02:07:28 +0300 From: Alexander Litvin To: freebsd-current@freebsd.org Subject: NSWAPDEV Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A little problem: 2.2-STABLE, cvsuped and built on 17 October. Previous kernel compiled with NSWAPDEV=3. After "make world" also added one the 4-th swap device, but forgot to increase NSWAPDEV. Naturally, got "/dev/sd2s1b: invalid argument". Then increased NSWAPDEV=4, config -n, make depend, make, make install. Nothing changes - still "/dev/sd2s1b: invalid argument". After "make clean" in kernel build directory and remaking kernel from scratch 4-th swap device was added without problems... -- Litvin Alexander From owner-freebsd-current Tue Oct 21 16:55:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA19116 for current-outgoing; Tue, 21 Oct 1997 16:55:26 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA19108 for ; Tue, 21 Oct 1997 16:55:21 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id RAA25772; Tue, 21 Oct 1997 17:55:18 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id RAA07966; Tue, 21 Oct 1997 17:55:17 -0600 (MDT) Date: Tue, 21 Oct 1997 17:55:17 -0600 (MDT) Message-Id: <199710212355.RAA07966@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@freebsd.org Subject: Re: lockmgr panic In-Reply-To: <19971022000053.ZR34581@uriah.heep.sax.de> References: <199710210651.QAA07277@godzilla.zeta.org.au> <199710210742.QAA13712@gneiss.eps.nagoya-u.ac.jp> <19971022000053.ZR34581@uriah.heep.sax.de> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Someone committed a modified version of this to 2.2 without testing > > > it in -current (without even committing it to -current). > > > > I think the patch is OK and it can be in current for testing. > > Unlike what Nate assumed, i'm using it on -current anyway. Others have reported to have back-ported it to 2.2, but I also did assume you used it under 2.2. Nate From owner-freebsd-current Tue Oct 21 17:43:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22309 for current-outgoing; Tue, 21 Oct 1997 17:43:34 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA22289; Tue, 21 Oct 1997 17:43:28 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id KAA17789; Wed, 22 Oct 1997 10:37:46 +1000 Date: Wed, 22 Oct 1997 10:37:46 +1000 From: Bruce Evans Message-Id: <199710220037.KAA17789@godzilla.zeta.org.au> To: dwmalone@maths.tcd.ie, gnat@frii.com Subject: Re: -STABLE reboots Cc: current@freebsd.org, freebsd-stable@freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Last time I checked any user could generate a panic >> similar to this by typing: >> mkdir /tmp/t >> mount_msdos /tmp/t /tmp/t >> Is anyone likely to have done this? This is an old problem. `mount -t any /foo /foo' always panics. Fix: don't do that. However, since mount_msdos is setuid root, anyone can do that using any = msdos. Fix in 2.2: mount_msdos should not be setuid root. The problem is more serious in -current, since mount(2) is unprivileged, so even `mount /foo /foo' panics (if the mounter is root or owns /foo). Bruce From owner-freebsd-current Tue Oct 21 17:48:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22677 for current-outgoing; Tue, 21 Oct 1997 17:48:26 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from eclogite.eps.nagoya-u.ac.jp (eclogite.eps.nagoya-u.ac.jp [133.6.57.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA22672 for ; Tue, 21 Oct 1997 17:48:22 -0700 (PDT) (envelope-from kato@eclogite.eps.nagoya-u.ac.jp) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by eclogite.eps.nagoya-u.ac.jp (8.8.7/3.3W9) with ESMTP id JAA14032; Wed, 22 Oct 1997 09:50:47 +0900 (JST) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl5) with ESMTP id JAA16017; Wed, 22 Oct 1997 09:48:18 +0900 (JST) Message-Id: <199710220048.JAA16017@gneiss.eps.nagoya-u.ac.jp> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@freebsd.org Subject: Re: lockmgr panic From: KATO Takenori In-Reply-To: Your message of "Wed, 22 Oct 1997 00:00:53 +0200" References: <19971022000053.ZR34581@uriah.heep.sax.de> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 22 Oct 1997 09:48:18 +0900 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Unlike what Nate assumed, i'm using it on -current anyway. I've got > one panic again, but now think that's because of the uninitialized > variable bug. Is panic 'ufs_unlock: recursive lock prematurely released'? If the stack where 'isvplocked' is stored is not zero, VOP_UNLOCK unlocks vnode which is not locked. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Tue Oct 21 17:48:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22710 for current-outgoing; Tue, 21 Oct 1997 17:48:44 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA22701 for ; Tue, 21 Oct 1997 17:48:41 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id KAA18036; Wed, 22 Oct 1997 10:44:57 +1000 Date: Wed, 22 Oct 1997 10:44:57 +1000 From: Bruce Evans Message-Id: <199710220044.KAA18036@godzilla.zeta.org.au> To: archer@lucky.net, freebsd-current@FreeBSD.ORG Subject: Re: NSWAPDEV Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >... >Naturally, got "/dev/sd2s1b: invalid argument". Then increased >NSWAPDEV=4, config -n, make depend, make, make install. Nothing >changes - still "/dev/sd2s1b: invalid argument". > >After "make clean" in kernel build directory and remaking kernel >from scratch 4-th swap device was added without problems... This is normal for options that aren't in /sys/conf/options or /sys/i386/conf/options.i386. They only get put in the Makefile, and there are only a few (mostly old and unnecessary) explicit dependencies on the Makefile. Bruce From owner-freebsd-current Tue Oct 21 19:02:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25912 for current-outgoing; Tue, 21 Oct 1997 19:02:08 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA25907 for ; Tue, 21 Oct 1997 19:02:05 -0700 (PDT) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id EAA05605; Wed, 22 Oct 1997 04:09:07 +0200 (CEST) From: Mikael Karpberg Message-Id: <199710220209.EAA05605@ocean.campus.luth.se> Subject: Re: -STABLE reboots In-Reply-To: <199710220037.KAA17789@godzilla.zeta.org.au> from Bruce Evans at "Oct 22, 97 10:37:46 am" To: bde@zeta.org.au (Bruce Evans) Date: Wed, 22 Oct 1997 04:09:06 +0200 (CEST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Bruce Evans: > The problem is more serious in -current, since mount(2) is unprivileged, > so even `mount /foo /foo' panics (if the mounter is root or owns /foo). Er... Isn't that easilly solvable by mount checking for the two arguments being the same? Or mount syscall (?) or mount_* programs checking if the arguments are the same, or so? Or am I missing something? /Mikael From owner-freebsd-current Tue Oct 21 19:03:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26062 for current-outgoing; Tue, 21 Oct 1997 19:03:38 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA26038 for ; Tue, 21 Oct 1997 19:03:30 -0700 (PDT) (envelope-from tlambert@usr03.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id TAA25405; Tue, 21 Oct 1997 19:03:17 -0700 (MST) Received: from usr03.primenet.com(206.165.6.203) via SMTP by smtp03.primenet.com, id smtpd025388; Tue Oct 21 19:03:10 1997 Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id TAA09608; Tue, 21 Oct 1997 19:03:11 -0700 (MST) From: Terry Lambert Message-Id: <199710220203.TAA09608@usr03.primenet.com> Subject: Re: nullfs & current UPDATE! To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Wed, 22 Oct 1997 02:03:10 +0000 (GMT) Cc: current@FreeBSD.ORG In-Reply-To: <19971021203807.51847@keltia.freenix.fr> from "Ollivier Robert" at Oct 21, 97 08:38:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Whatever needs to be done should probably be done in null_inactive(), > > look at sys/ufs/ufs/ufs_inode.c:ufs_inactive(). > > By using the following patch, I've been able to create and delete hundreds > of files in a nullfs mounted directory. No vnode leak as far as I can see > from the sysctl debug.numvnodes. fsck reports no missing blocks. No panic, > just works. Now that seems too easy :-) > > I know there is a comment in null_inactive() about doing nothing in there > but it seemed logical to inform the lower layer... > > PS: a similar problem is in umapfs which is based on nullfs. > > Opinions about this ? Using this approach sort of breaks the ability to collapse out intermediate vnode layers, since it leaves things associated with the upper level vnodes that probably ought not to be left associated. Specifically, if you look back to John's comment about vnode_pager_uncache, and then look at nullfs... Probably the "correct" way to handle this is to avoid aliases, and instead establish a null_getpage/null_putpage VOP for page access, and force it to make the reference to the underlying FS. This is actually a lot cleaner than implementing vp dereferencing ops, since it would allow you to pass the vp to the underlying FS back up in place of the vp for the covering fs. When you could do this really depends on if it's file ops, directory ops, or whatever. For example, if an open returns an alias node, then the alias dereference needs to take place on anything which could reference it. But this does not necessarily mean both files and directories would be affected. One could easily envision a UID FS that only operated on files... The main problem is the page references, and the need for the vnode pager to be able to identify the pages referenced by the underlying vnode and those referenced by the upper level vnode, but which came from the lower level vnode. Similarly, you could envision a name space extension for resource forks which would stack and have file references turn into directories, and the actual file contents go into the "default" for defined as "name/data" instead of "name". Such an extension would return the underlying vnode for the "data" for, but an alias vnode for non-"data" fork. Really, I'd like to see per FS page routines, and things like the per fs inactive left actually NULL, where possible. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Oct 21 19:09:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26350 for current-outgoing; Tue, 21 Oct 1997 19:09:45 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA26343 for ; Tue, 21 Oct 1997 19:09:42 -0700 (PDT) (envelope-from tlambert@usr03.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id TAA11618; Tue, 21 Oct 1997 19:09:29 -0700 (MST) Received: from usr03.primenet.com(206.165.6.203) via SMTP by smtp04.primenet.com, id smtpd011616; Tue Oct 21 19:09:27 1997 Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id TAA09840; Tue, 21 Oct 1997 19:09:21 -0700 (MST) From: Terry Lambert Message-Id: <199710220209.TAA09840@usr03.primenet.com> Subject: Re: nullfs & current To: toor@dyson.iquest.net (John S. Dyson) Date: Wed, 22 Oct 1997 02:09:21 +0000 (GMT) Cc: roberto@keltia.freenix.fr, current@FreeBSD.ORG In-Reply-To: <199710201837.NAA11707@dyson.iquest.net> from "John S. Dyson" at Oct 20, 97 01:37:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > calling vnode_pager_uncache() null_remove() would be wrong, the file > > > may still be open. > > > > Right. > > > Not quite. > > I was wrong there, but the underlying object that is pointed to BOTH the > nullfs layer and the underlying error should have it's reference count > decreased. If the reference count of the object is ONE, and the VNODE > is referred to only by that object, then the vnode_pager_uncache should > be done. Or.... more specifically, there needs to be per FS VOP_PUTPAGE/VOP_GETPAGE that the vnode pager can call that will either manage the pages off the upper level vnode, or refer the operation to the underlying vnode where a single instance of the backing page is referenced, instead. The vnode_pager_uncache is really a reference kludge to get around not having per PS page reference mechanisms. At worst, pages in an alias (upper level) vnode should be referenced by descriptor, not directly. You can not discard the upper level without discarding the lower level. This kind of goes back to my long ago request for a per FS VOP_VRELE... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Oct 21 19:17:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26768 for current-outgoing; Tue, 21 Oct 1997 19:17:32 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA26763 for ; Tue, 21 Oct 1997 19:17:29 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id MAA22074; Wed, 22 Oct 1997 12:13:50 +1000 Date: Wed, 22 Oct 1997 12:13:50 +1000 From: Bruce Evans Message-Id: <199710220213.MAA22074@godzilla.zeta.org.au> To: bde@zeta.org.au, karpen@ocean.campus.luth.se Subject: Re: -STABLE reboots Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The problem is more serious in -current, since mount(2) is unprivileged, >> so even `mount /foo /foo' panics (if the mounter is root or owns /foo). > >Er... Isn't that easilly solvable by mount checking for the two arguments >being the same? Of course not, or it would have been fixed years ago. `mkdir foo; ln foo bar; mount foo bar' also panics. Checking inodes isn't enough either, since `mkdir foo foo/foo; mount foo/foo foo' also panics. Bruce From owner-freebsd-current Tue Oct 21 19:41:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA28285 for current-outgoing; Tue, 21 Oct 1997 19:41:20 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28280 for ; Tue, 21 Oct 1997 19:41:17 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id MAA23169; Wed, 22 Oct 1997 12:40:50 +1000 Date: Wed, 22 Oct 1997 12:40:50 +1000 From: Bruce Evans Message-Id: <199710220240.MAA23169@godzilla.zeta.org.au> To: current@FreeBSD.ORG, roberto@keltia.freenix.fr Subject: Re: nullfs & current UPDATE! Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Opinions about this ? > >Index: null_vnops.c >=================================================================== >RCS file: /spare/FreeBSD-current/src/sys/miscfs/nullfs/null_vnops.c,v >retrieving revision 1.24 >diff -u -2 -r1.24 null_vnops.c >--- null_vnops.c 1997/10/15 10:04:31 1.24 >+++ null_vnops.c 1997/10/21 18:31:52 >@@ -534,4 +534,7 @@ > } */ *ap; > { >+ struct vnode *vp = ap->a_vp; >+ struct null_node *xp = VTONULL(vp); >+ struct vnode *lowervp = xp->null_lowervp; style.9 says not to obfuscate code by initializes variables in declarations. > /* > * Do nothing (and _don't_ bypass). It doesn't do nothing, especially now. >@@ -546,4 +549,5 @@ > * That's too much work for now. > */ >+ VOP_INACTIVE(lowervp, ap->a_p); > VOP_UNLOCK(ap->a_vp, 0, ap->a_p); It is an obfuscation to set ap->a_vp = vp above and then not use it here. I think the function is still simple enough for it to be clearer without temporary variables. `lowervp' can be written fairly concisely as VTONULL(ap->a_vp)->null_lowervp. In fact, there is already a macro NULLVPTOLOWERVP() for this. It seems to be used consistently to set `lowervp' variables that are passed to other functions and not used again, as lowervp is here. Bruce From owner-freebsd-current Tue Oct 21 22:37:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA07126 for current-outgoing; Tue, 21 Oct 1997 22:37:58 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA07121 for ; Tue, 21 Oct 1997 22:37:56 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id HAA01435 for ; Wed, 22 Oct 1997 07:38:08 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id HAA23967 for current@FreeBSD.ORG; Wed, 22 Oct 1997 07:37:44 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id HAA03509; Wed, 22 Oct 1997 07:28:19 +0200 (CEST) (envelope-from roberto) Message-ID: <19971022072818.27417@keltia.freenix.fr> Date: Wed, 22 Oct 1997 07:28:18 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! References: <199710220240.MAA23169@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710220240.MAA23169@godzilla.zeta.org.au>; from Bruce Evans on Wed, Oct 22, 1997 at 12:40:50PM +1000 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Bruce Evans: > style.9 says not to obfuscate code by initializes variables in declarations. I tried to be consistent with the code around in null_vnops.c... Do you think we should change both miscfs/nullfs and miscfs/umapfs to conform to style(9) ? The code has been like this since 4.4BSD-lite... > It doesn't do nothing, especially now. I changed the comment in the commit although I could make it clearer. > It is an obfuscation to set ap->a_vp = vp above and then not use it here. > I think the function is still simple enough for it to be clearer without > temporary variables. `lowervp' can be written fairly concisely as > VTONULL(ap->a_vp)->null_lowervp. In fact, there is already a macro > NULLVPTOLOWERVP() for this. It seems to be used consistently to set > `lowervp' variables that are passed to other functions and not used again, > as lowervp is here. It is not used consistly in nullfs :-( -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Tue Oct 21 23:14:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08870 for current-outgoing; Tue, 21 Oct 1997 23:14:30 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08861 for ; Tue, 21 Oct 1997 23:14:27 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA26732 for freebsd-current@FreeBSD.ORG; Wed, 22 Oct 1997 08:14:21 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id HAA20635; Wed, 22 Oct 1997 07:57:50 +0200 (MET DST) Message-ID: <19971022075750.IB36893@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 07:57:50 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Subject: Re: lockmgr panic References: <19971022000053.ZR34581@uriah.heep.sax.de> <199710220048.JAA16017@gneiss.eps.nagoya-u.ac.jp> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710220048.JAA16017@gneiss.eps.nagoya-u.ac.jp>; from KATO Takenori on Oct 22, 1997 09:48:18 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As KATO Takenori wrote: > I've got > > one panic again, but now think that's because of the uninitialized > > variable bug. > > Is panic 'ufs_unlock: recursive lock prematurely released'? Maybe. I didn't save that coredump, so i don't have the panic message in the syslog messages. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Oct 21 23:51:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA10844 for current-outgoing; Tue, 21 Oct 1997 23:51:01 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA10835 for ; Tue, 21 Oct 1997 23:50:57 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA26917 for current@FreeBSD.ORG; Wed, 22 Oct 1997 08:50:56 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA20854; Wed, 22 Oct 1997 08:32:38 +0200 (MET DST) Message-ID: <19971022083238.XB35355@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 08:32:38 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! References: <199710220240.MAA23169@godzilla.zeta.org.au> <19971022072818.27417@keltia.freenix.fr> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19971022072818.27417@keltia.freenix.fr>; from Ollivier Robert on Oct 22, 1997 07:28:18 +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Ollivier Robert wrote: > According to Bruce Evans: > > style.9 says not to obfuscate code by initializes variables in > > declarations. > I tried to be consistent with the code around in null_vnops.c... Do you > think we should change both miscfs/nullfs and miscfs/umapfs to conform to > style(9) ? The code has been like this since 4.4BSD-lite... We've already changed style(9) to make it less strict than it used to be. Function calls are forbidden (since they might cause ill side-effects when someone tries to make the code thread-safe for SMP). One must be cautious with macros like VTONULL() since they could actually impose a function call (even if they don't do now, someone might get the idea to change a low-level interface later, and hide it inside such a macro). Of course, for C++ code, the restriction needs to be rethought. There's often a big difference between an initializer, and a declaration followed by an assignment, in C++ (the declaration might be not useful without the initializer, depending on your constructors). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Oct 22 00:22:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA12657 for current-outgoing; Wed, 22 Oct 1997 00:22:46 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA12642 for ; Wed, 22 Oct 1997 00:22:41 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id RAA03072; Wed, 22 Oct 1997 17:18:27 +1000 Date: Wed, 22 Oct 1997 17:18:27 +1000 From: Bruce Evans Message-Id: <199710220718.RAA03072@godzilla.zeta.org.au> To: current@FreeBSD.ORG, roberto@keltia.freenix.fr Subject: Re: nullfs & current UPDATE! Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I tried to be consistent with the code around in null_vnops.c... Do you >think we should change both miscfs/nullfs and miscfs/umapfs to conform to >style(9) ? The code has been like this since 4.4BSD-lite... No, don't change old code. Just write perfect new code :-). >> temporary variables. `lowervp' can be written fairly concisely as >> VTONULL(ap->a_vp)->null_lowervp. In fact, there is already a macro >> NULLVPTOLOWERVP() for this. It seems to be used consistently to set >> `lowervp' variables that are passed to other functions and not used again, >> as lowervp is here. > >It is not used consistly in nullfs :-( It was in the Lite2 version :-). All cases except one where xp->null_lowervp is used already had xp handy. The one exception was a FreeBSD addition in null_vfsops.c:nullfs_mount(). Bruce From owner-freebsd-current Wed Oct 22 02:12:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA18563 for current-outgoing; Wed, 22 Oct 1997 02:12:27 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA18555; Wed, 22 Oct 1997 02:12:24 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from graves.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa03556; 22 Oct 97 10:08 +0100 To: Bruce Evans cc: current@freebsd.org, freebsd-stable@freebsd.org Subject: Recursive mount [ was Re: -STABLE reboots ] In-reply-to: Your message of "Wed, 22 Oct 1997 10:37:46 +1000." <199710220037.KAA17789@godzilla.zeta.org.au> Date: Wed, 22 Oct 1997 10:08:11 +0100 From: David Malone Message-ID: <9710221008.aa03556@salmon.maths.tcd.ie> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This is an old problem. `mount -t any /foo /foo' always panics. Fix: > don't do that. However, since mount_msdos is setuid root, anyone can > do that using any = msdos. Fix in 2.2: mount_msdos should not be > setuid root. I thought about tring to rewrite the mount code for the various filesystems to ask for a recursive lock, and then compare the mount point and "device", but that would require me to learn quite a bit about VFS. > The problem is more serious in -current, since mount(2) is unprivileged, > so even `mount /foo /foo' panics (if the mounter is root or owns /foo). Could someone add a sysctl to current that makes mount a privilaged syscall? David. From owner-freebsd-current Wed Oct 22 04:48:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA24154 for current-outgoing; Wed, 22 Oct 1997 04:48:59 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from oxmail4.ox.ac.uk (oxmail4.ox.ac.uk [163.1.2.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA24149 for ; Wed, 22 Oct 1997 04:48:56 -0700 (PDT) (envelope-from neil.long@materials.oxford.ac.uk) Received: from njl2.materials.ox.ac.uk by oxmail4 with SMTP (PP); Wed, 22 Oct 1997 12:48:21 +0100 Received: by njl2.materials.ox.ac.uk (950413.SGI.8.6.12/940406.SGI) for current@FreeBSD.ORG id MAA09895; Wed, 22 Oct 1997 12:48:19 +0100 Date: Wed, 22 Oct 1997 12:48:19 +0100 From: neil.long@materials.oxford.ac.uk (Neil J Long) Message-Id: <9710221248.ZM9893@njl2.materials.ox.ac.uk> X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: current@freebsd.org Subject: make installworld Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi I am using make installworld (after a successful buildworld on the host server, of course) using read-only mounts of /usr/src and /usr/obj This is still a problem even if the server has had installworld run. It fails at ===> include cd /usr/src/include; install -C -o bin -g bin -m 444 a.out.h ar.h assert.h bitstring.h ctype.h db.h dirent.h disktab.h err.h f2c.h fnmatch.h fstab.h fts.h glob.h grp.h strhash.h histedit.h kvm.h limits.h link.h locale.h malloc.h memory.h mpool.h ndbm.h netdb.h nl_types.h nlist.h paths.h pthread.h pthread_np.h pwd.h ranlib.h regex.h regexp.h resolv.h rune.h runetype.h setjmp.h sgtty.h signal.h stab.h stddef.h stdio.h stdlib.h string.h strings.h struct.h sysexits.h tar.h time.h timers.h ttyent.h unistd.h utime.h utmp.h vis.h /usr/include cd /usr/src/include/arpa; install -C -o bin -g bin -m 444 ftp.h inet.h nameser.h telnet.h tftp.h /usr/include/arpa cd /usr/src/include/protocols; install -C -o bin -g bin -m 444 dumprestore.h routed.h rwhod.h talkd.h timed.h /usr/include/protocols cd /usr/src/include/rpc; install -C -o bin -g bin -m 444 auth.h auth_unix.h clnt.h pmap_clnt.h pmap_prot.h pmap_rmt.h rpc.h rpc_msg.h svc.h svc_auth.h types.h xdr.h /usr/include/rpc rm: osreldate.h: Read-only file system *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. /usr/obj has to be mounted writeable in order that creating osreldate.h from newvers.sh . /usr/src/include/../sys/conf/newvers.sh; echo "$COPYRIGHT" > osreldate.h; echo \#'undef __FreeBSD_version' >> osreldate.h; echo \#'define __FreeBSD_version' $RELDATE >> osreldate.h install -C -o bin -g bin -m 444 osreldate.h /usr/include can proceed. Shame it breaks the idea of mounting ro Neil From owner-freebsd-current Wed Oct 22 05:48:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA26604 for current-outgoing; Wed, 22 Oct 1997 05:48:05 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from eclogite.eps.nagoya-u.ac.jp (eclogite.eps.nagoya-u.ac.jp [133.6.57.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA26581; Wed, 22 Oct 1997 05:47:58 -0700 (PDT) (envelope-from kato@eclogite.eps.nagoya-u.ac.jp) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by eclogite.eps.nagoya-u.ac.jp (8.8.7/3.3W9) with ESMTP id VAA15665; Wed, 22 Oct 1997 21:50:25 +0900 (JST) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl5) with ESMTP id VAA01644; Wed, 22 Oct 1997 21:47:53 +0900 (JST) Message-Id: <199710221247.VAA01644@gneiss.eps.nagoya-u.ac.jp> To: dwmalone@maths.tcd.ie Cc: current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Recursive mount [ was Re: -STABLE reboots ] From: KATO Takenori In-Reply-To: Your message of "Wed, 22 Oct 1997 10:08:11 +0100" References: <9710221008.aa03556@salmon.maths.tcd.ie> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 22 Oct 1997 21:47:53 +0900 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Could someone add a sysctl to current that makes > mount a privilaged syscall? How about following patch? ---------- BEGIN ---------- *** vfs_syscalls.c.ORIG Wed Oct 22 20:24:15 1997 --- vfs_syscalls.c Wed Oct 22 20:34:21 1997 *************** *** 77,82 **** --- 77,86 ---- static int change_dir __P((struct nameidata *ndp, struct proc *p)); static void checkdirs __P((struct vnode *olddp)); + static int usermount = 0; /* if 1, non-root can mount fs. */ + + SYSCTL_INT(_vfs, OID_AUTO, usermount, CTLFLAG_RW, &usermount, 0, ""); + /* * Virtual File System System Calls */ *************** *** 112,117 **** --- 116,124 ---- u_long fstypenum; struct nameidata nd; char fstypename[MFSNAMELEN]; + + if (usermount == 0 && (error = suser(p->p_ucred, &p->p_acflag))) + return (error); /* * Get vnode to be covered ---------- END ---------- ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Wed Oct 22 09:15:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA08094 for current-outgoing; Wed, 22 Oct 1997 09:15:44 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08086 for ; Wed, 22 Oct 1997 09:15:39 -0700 (PDT) (envelope-from Tor.Egge@idi.ntnu.no) Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65]) by pat.idi.ntnu.no (8.8.6/8.8.6) with ESMTP id SAA17560; Wed, 22 Oct 1997 18:15:14 +0200 (MET DST) Message-Id: <199710221615.SAA17560@pat.idi.ntnu.no> To: roberto@keltia.freenix.fr Cc: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! In-Reply-To: Your message of "Tue, 21 Oct 1997 20:38:07 +0200" References: <19971021203807.51847@keltia.freenix.fr> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 22 Oct 1997 18:15:13 +0200 From: Tor Egge Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > By using the following patch, I've been able to create and delete hundreds > of files in a nullfs mounted directory. No vnode leak as far as I can see > from the sysctl debug.numvnodes. fsck reports no missing blocks. No panic, > just works. Now that seems too easy :-) > > I know there is a comment in null_inactive() about doing nothing in there > but it seemed logical to inform the lower layer... > > PS: a similar problem is in umapfs which is based on nullfs. > > Opinions about this ? Yes. This patch causes open files to be truncated to zero length if nullfs is used to unlink the file. e.g., when A and B are different shells: A: mount -t null /tmp /mnt A. jot 1000000 1 > /tmp/test A: more /tmp/test B: rm /mnt/test # while A: is still at top of file A: # Go to bottom of file. then the last part of the file is lost. If B performes `rm /tmp/test' instead of `rm /mnt/test' then this problem does not occur. This leads me to believe that this patch has some unwanted undocumented side effects due to calling VOP_INACTIVE without regard to lowervp->usecount. An unconditional call to vrecycle (with ap->a_vp as first argument) in the end of null_inactive (after VOP_UNLOCK) might be an alternate solution with less side effects. That should cause an immediate vrele of the underlying vnode where VOP_INACTIVE is called if usecount reaches zero. - Tor Egge From owner-freebsd-current Wed Oct 22 09:19:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA08566 for current-outgoing; Wed, 22 Oct 1997 09:19:43 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from wall.jhs.no_domain (vector.muc.ditec.de [194.120.126.35]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08462; Wed, 22 Oct 1997 09:19:00 -0700 (PDT) (envelope-from jhs@freebsd.org) Received: (from jhs@localhost) by wall.jhs.no_domain (8.8.5/8.6.9) id RAA00336; Wed, 22 Oct 1997 17:22:54 +0100 (MET) Date: Wed, 22 Oct 1997 17:22:54 +0100 (MET) Message-Id: <199710221622.RAA00336@wall.jhs.no_domain> To: Richard Wackerbarth cc: current@freebsd.org, Mark Murray Subject: Here's a supplemental ctm cvs-cur.3699.fix for src/kerberosIV From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: Home: X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Web: http://www.freebsd.org/~jhs/ (Includes PGP Key) X-Tel: Home: +49.89.268616 X-Fax: Home: +49.89.2608126 X-Data: Home: +49.89.26023276 X-Company: Vector Systems Ltd, Unix & Internet Consultants. X-Mailer: EXMH 1.6.9 on FreeBSD (Unix) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Richard Wackerbarth, (cc current & Mark M) Thanks to Mark Murray who wrote: > Not necessary. You are one of the folk who (years ago) had the _old_ > kerberosIV stuff. Just blow away ncvs/src/kerberosIV and all will be > well. There has been CVS surgery. I append a hand built supplemental ctm cvs-cur.3699.fix Why ? Start from cvs-cur.1500A.gz & apply all deltas, & one consistently fails like this: Working on <................/cvs-cur.3670.gz> DM: src/kerberosIV exists. The new ctm fixes that, it: Deletes src/kerberosIV Has a ctm timestamp (in CTM_BEGIN) half way between cvs-cur.3699 & cvs-cur.3670 (in case this might help someone somehow, though I don't know how & if ctm timestamp is used): This ctm enabled me to come from cvs-cur.1500A.gz up to & inc. cvs-cur.3752 automatically, just with deltas, & no hand intervention I suggest this cvs-cur.3699.fix be added to the deltas in archive sites. I don't know if later CTM baselines had already removed src/kerberosIV, I can't check that, I only have cvs-cur.1500A.gz here, but if so the ctm is only of use to folk using old CVS base deltas, that include the unwanted src/kerberosIV (such as me). Hopefully the CTM master Richard Wackerbarth can consider this ? Thanks. Julian -- Julian H. Stacey http://www.freebsd.org/~jhs/ Tel. +49 89 268616 ============================= CTM_BEGIN 2.0 cvs-cur 3670 19970921100000Z . CTMFR src/kerberosIV/Attic/Makefile,v 7fd45c504e0025bf85cefa483ef4e7a5 CTMFR src/kerberosIV/Attic/Makefile.inc,v f618893d18f1259c6d2d804539d35379 CTMFR src/kerberosIV/acl/Attic/Makefile,v 1799ac86158bccfbba05facae8452b45 CTMFR src/kerberosIV/acl/Attic/acl_files.c,v 31576326bbb6cfd73a7f0b867ce5f0de CTMFR src/kerberosIV/acl/Attic/acl_files.doc,v 6322595967e04be4629313cd350cb79e CTMFR src/kerberosIV/compile_et/Attic/Makefile,v 48169fc27baa41efdbf7cc846b96448c CTMFR src/kerberosIV/compile_et/Attic/compile_et.c,v 5716ea606689ae69d98c156025a81c64 CTMFR src/kerberosIV/compile_et/Attic/error_message.c,v 01fc658add0787ceb0c4bfeff79dc81d CTMFR src/kerberosIV/compile_et/Attic/error_table.h,v b935cec674e103df69fb19fed63656e9 CTMFR src/kerberosIV/compile_et/Attic/error_table.y,v 14137a3ff7090efd063e071eda81a2e4 CTMFR src/kerberosIV/compile_et/Attic/et_lex.lex.l,v b6494d6d4fbb3ade9af6837a2080bc11 CTMFR src/kerberosIV/compile_et/Attic/et_name.c,v e9cac5330fbeef19fd658d4595de9820 CTMFR src/kerberosIV/compile_et/Attic/init_et.c,v fe2bedbd8f16950313315ae437d23b69 CTMFR src/kerberosIV/compile_et/Attic/mit-sipb-copyright.h,v 39ab008d67e3670bfe6879ae869eba9e CTMFR src/kerberosIV/compile_et/Attic/perror.c,v 18b4ff6d228f279cf87d8a68a1871b51 CTMFR src/kerberosIV/compile_et/test/Attic/test.c,v 0f8b4fe3804857e8c4d88aca52c123bf CTMFR src/kerberosIV/compile_et/test/Attic/test1.et,v 835aa1ac7d54d18f29dd9accb6cdb88d CTMFR src/kerberosIV/compile_et/test/Attic/test2.et,v bffb943b3199a310feaa81e7fa1d1ed9 CTMFR src/kerberosIV/des/Attic/Makefile,v 680f22be44df9538ea56f2458e5fd2a4 CTMFR src/kerberosIV/des/Attic/READ_ME,v 91bd168c87cd8be13052da4170220278 CTMFR src/kerberosIV/des/Attic/cbc_encrypt.c,v d4642beb96f99e8b052f773d66d97ba2 CTMFR src/kerberosIV/des/Attic/cksum.c,v 20216baad7a843038b68e23e04a3e501 CTMFR src/kerberosIV/des/Attic/debug_decl.c,v 8211e9661b395db24411d00459675184 CTMFR src/kerberosIV/des/Attic/des.c,v b0a3de3eb750ab4174cd9f413e168699 CTMFR src/kerberosIV/des/Attic/des_internal.h,v ce9798daee1cdb5350c002f80e6f6cb1 CTMFR src/kerberosIV/des/Attic/key_parity.c,v 5ef813c56bab3c177224399fe04924c6 CTMFR src/kerberosIV/des/Attic/key_sched.c,v 61413812aa39b8a8b4bde5769a07a10f CTMFR src/kerberosIV/des/Attic/new_rnd_key.c,v a531d84a522e588f8642d1fdfbba1e5f CTMFR src/kerberosIV/des/Attic/pcbc_encrypt.c,v 1a605f755a56a561c23c2cd624e5b74c CTMFR src/kerberosIV/des/Attic/quad_cksum.c,v 5a51313afbd467d427354f7f08334ae9 CTMFR src/kerberosIV/des/Attic/random_key.c,v f2db86a8e119fd834ee10fabdb729099 CTMFR src/kerberosIV/des/Attic/read_password.c,v 945b193548d1adda6dc492f406a5145d CTMFR src/kerberosIV/des/Attic/string_to_key.c,v 9dc1010e8607f6173819197b27b0ed54 CTMFR src/kerberosIV/des/Attic/tables.h,v b9a7faac6f4e7e1c6cc8e3a8bc03c30d CTMFR src/kerberosIV/des/Attic/util.c,v de9fdb7e6099c06c540f8e35b005b8d7 CTMFR src/kerberosIV/des/Attic/weak_key.c,v 645d3da8fd79b9b0ce9e9a0dac13138e CTMFR src/kerberosIV/des/doc/Attic/libdes.doc,v 27283ea527bac595b1362809a22b007b CTMFR src/kerberosIV/ext_srvtab/Attic/Makefile,v d0208459caaf53f692a7679ee12eaabc CTMFR src/kerberosIV/ext_srvtab/Attic/ext_srvtab.c,v 24ab5b8369a210e02a3b3ae54eaa4a7e CTMFR src/kerberosIV/include/Attic/Makefile,v 2682ad604ab850bc659721aae24fedfc CTMFR src/kerberosIV/include/Attic/addr_comp.h,v 4bec7775968274231e6df65435a3aec5 CTMFR src/kerberosIV/include/Attic/admin_server.h,v 0fbda46a5f2b9bedb7b0ea4b12e4c01b CTMFR src/kerberosIV/include/Attic/conf-bsd386i.h,v 7f2e0630b2b211e68f869eb03a80ad38 CTMFR src/kerberosIV/include/Attic/conf-bsdapollo.h,v 8bebde0b46a031fccd82a4e49223dff3 CTMFR src/kerberosIV/include/Attic/conf-bsdibm032.h,v 0809e3ed0cb619694f4dda2c7d6b0d4a CTMFR src/kerberosIV/include/Attic/conf-bsdm68k.h,v 8e4f3b9fc94e28fd7cbde06eaf9bb530 CTMFR src/kerberosIV/include/Attic/conf-bsdsparc.h,v b89f4c07898ef061d9b69a6e978f3ea3 CTMFR src/kerberosIV/include/Attic/conf-bsdtahoe.h,v b283a2c8150337f7af1302ccb7c10b9c CTMFR src/kerberosIV/include/Attic/conf-bsdvax.h,v cc86dbb60b400b21076f6799c7f65275 CTMFR src/kerberosIV/include/Attic/conf-ibm370.h,v f6c72cebd006dc25190fceac41c6fa4a CTMFR src/kerberosIV/include/Attic/conf-pc.h,v 9aca55c1ccf0879c1b3606ee66a6f05e CTMFR src/kerberosIV/include/Attic/conf-pyr.h,v 1d264363a12a53e598aa06225de8b97d CTMFR src/kerberosIV/include/Attic/conf-ultmips2.h,v c4bbce00f3f13e6330f6ceeb9a2d1ffb CTMFR src/kerberosIV/include/Attic/conf.h,v 8ea4c88b182a3757235aae1ba1c24e2f CTMFR src/kerberosIV/include/Attic/des.h,v 6c8b6e628642890508bc1e5b542bef6e CTMFR src/kerberosIV/include/Attic/des_conf.h,v 477b808bd23f908b9ab6222e7c93ac98 CTMFR src/kerberosIV/include/Attic/highc.h,v 61789937155116ea2d7b2f0b375e4059 CTMFR src/kerberosIV/include/Attic/kadm.h,v a739b6bcb2f0ae218d8edcd58990c9bc CTMFR src/kerberosIV/include/Attic/kadm_err.h,v 4ca196c71847dd1a498acbd50730bbbc CTMFR src/kerberosIV/include/Attic/kdc.h,v c57fdee95eea27b7f5b2574124563a76 CTMFR src/kerberosIV/include/Attic/klog.h,v f209f5a171374779a1799156ca6ba06c CTMFR src/kerberosIV/include/Attic/kparse.h,v 9698892ff6eafdeb36826bef9c90a2e5 CTMFR src/kerberosIV/include/Attic/krb.h,v 0b20a262de56503b72e6fa98ae2b3073 CTMFR src/kerberosIV/include/Attic/krb_conf.h,v db896a785ada156f3be9a619bdb63a70 CTMFR src/kerberosIV/include/Attic/krb_db.h,v c86a96a8c7f806ad9ccd91d2863f6ab4 CTMFR src/kerberosIV/include/Attic/krb_err.h,v 6b0c0e930bbd3446d2496a16728d0b4f CTMFR src/kerberosIV/include/Attic/lsb_addr_comp.h,v 197b6fd024fc2897ebacf2faea0bc141 CTMFR src/kerberosIV/include/Attic/mit-copyright.h,v e848de07d8c1f154ec1f28768c6282fb CTMFR src/kerberosIV/include/Attic/osconf.h,v af9ee22ee95edb6eaf6c2fa9b653de6d CTMFR src/kerberosIV/include/Attic/passwd_server.h,v 4abae9ee5f5a65c937e3dae575303e5c CTMFR src/kerberosIV/include/Attic/principal.h,v 9711da8c3d7848e3c2beee77363404c4 CTMFR src/kerberosIV/include/Attic/prot.h,v 5d13a670b346cc2255206d510617e385 CTMFR src/kerberosIV/kdb/Attic/Makefile,v 6c5c5b7b739117b5f3f39f93994abd74 CTMFR src/kerberosIV/kdb/Attic/krb_cache.c,v e80a1a129f722e0ad4f7ea210ab8f598 CTMFR src/kerberosIV/kdb/Attic/krb_dbm.c,v 0e86466de37d363699ccb2b483e80efe CTMFR src/kerberosIV/kdb/Attic/krb_kdb_utils.c,v 095559a5e07c594f9db1e7a68e48cdaa CTMFR src/kerberosIV/kdb/Attic/krb_lib.c,v 4c1a1b21d052976d072cf3bef52a2855 CTMFR src/kerberosIV/kdb/Attic/print_princ.c,v 1c579519158aed10c81d0ef972c1ad0f CTMFR src/kerberosIV/kdb_destroy/Attic/Makefile,v 18aade1729fe2559b5ca9933d00d19c1 CTMFR src/kerberosIV/kdb_destroy/Attic/kdb_destroy.c,v 38a93c807de9d3b9f17e543b3545c6b0 CTMFR src/kerberosIV/kdb_edit/Attic/Makefile,v 6d46897c1800713f14bf971361ddbe72 CTMFR src/kerberosIV/kdb_edit/Attic/kdb_edit.c,v 457eff1ee077193269987b003790829c CTMFR src/kerberosIV/kdb_edit/Attic/maketime.c,v 6ffd213df237e91cf571ee5d57de6262 CTMFR src/kerberosIV/kdb_edit/Attic/time.h,v 00d8ee80000e95d90f2517f4e8b238d1 CTMFR src/kerberosIV/kdb_init/Attic/Makefile,v 58bc7b422c09dba1681a90db43b10250 CTMFR src/kerberosIV/kdb_init/Attic/kdb_init.c,v afe10341164391891d12500ba1c3c2e3 CTMFR src/kerberosIV/kdb_util/Attic/Makefile,v 77230fff11cddd333fe0d327d0e145fe CTMFR src/kerberosIV/kdb_util/Attic/kdb_util.c,v 341ca61c2c4dcc66e805368e595bdaad CTMFR src/kerberosIV/kdestroy/Attic/Makefile,v 730658f144c39727764bfbfbe56a13e7 CTMFR src/kerberosIV/kdestroy/Attic/kdestroy.c,v cb5e2d72cab159c16b684c9787b04bad CTMFR src/kerberosIV/kerberos/Attic/Makefile,v 481271c4156b537a9dd5121252d70c73 CTMFR src/kerberosIV/kerberos/Attic/kerberos.c,v 38ab06697de6b0b1d32fbe707ac46fdc CTMFR src/kerberosIV/kinit/Attic/Makefile,v cba9987604b95d172adbb48b0925caae CTMFR src/kerberosIV/kinit/Attic/kinit.c,v 3b69525af75b9852d7a71c7b3cdb31d4 CTMFR src/kerberosIV/klist/Attic/Makefile,v ce0da0deeee41530ba4b788e88330d29 CTMFR src/kerberosIV/klist/Attic/klist.c,v a92d5e8e5568345b836703f36acfed02 CTMFR src/kerberosIV/krb/Attic/Makefile,v 6d62e76e5e06d3d56dd285eca7a1f349 CTMFR src/kerberosIV/krb/Attic/add_ticket.c,v 084a07d5929ad0b3d5ddca1b9b750790 CTMFR src/kerberosIV/krb/Attic/cr_err_reply.c,v ca81f0bbfe5f8922e2c08ca5edf6dcc6 CTMFR src/kerberosIV/krb/Attic/create_auth_reply.c,v 7b637ad5bd1cd5318b35d385622ff1bc CTMFR src/kerberosIV/krb/Attic/create_ciph.c,v 3f4f0d7d03ae98eb624d60f238f4c751 CTMFR src/kerberosIV/krb/Attic/create_death_packet.c,v 7c2dbd298509560b3f23c65d68d94555 CTMFR src/kerberosIV/krb/Attic/create_ticket.c,v ced1662decb1c7c62dc68827f2922d0f CTMFR src/kerberosIV/krb/Attic/debug_decl.c,v 825b8bcc80ada97775c98d0b24f0c3db CTMFR src/kerberosIV/krb/Attic/decomp_ticket.c,v bd4884282d482666f72be3b76c39079f CTMFR src/kerberosIV/krb/Attic/des_rw.c,v 9969051cd3732f885144c2b633ee1c24 CTMFR src/kerberosIV/krb/Attic/dest_tkt.c,v d3b873336c8a0c0fefcdf6e289ee24cb CTMFR src/kerberosIV/krb/Attic/extract_ticket.c,v 7d96474fe3d0f0830889b377138a7dee CTMFR src/kerberosIV/krb/Attic/fgetst.c,v 59594e5f2b99359448ea0baac0a7fe3c CTMFR src/kerberosIV/krb/Attic/get_ad_tkt.c,v f6a75367bde981581299f8866ffd4641 CTMFR src/kerberosIV/krb/Attic/get_admhst.c,v 225954bb07847bd8b3ad4c46fb493f2d CTMFR src/kerberosIV/krb/Attic/get_cred.c,v 92fbb339e371a429d9657037d2445b64 CTMFR src/kerberosIV/krb/Attic/get_in_tkt.c,v 88a2998a56b108d490741af6d7c634f6 CTMFR src/kerberosIV/krb/Attic/get_krbhst.c,v ddab5db4d998572e3bf2e8c2cd60e98b CTMFR src/kerberosIV/krb/Attic/get_krbrlm.c,v e833010bd3f5a94738f81cf6ab5d00ec CTMFR src/kerberosIV/krb/Attic/get_phost.c,v 15d40be48dcd245f634bea5580169ec8 CTMFR src/kerberosIV/krb/Attic/get_pw_tkt.c,v df17f6e7e814208e6b404f9fd9408e56 CTMFR src/kerberosIV/krb/Attic/get_request.c,v f96cec54f3b23c78c557e0d0f203e642 CTMFR src/kerberosIV/krb/Attic/get_svc_in_tkt.c,v 6b73f4e32d670d96f9f591eea309a41a CTMFR src/kerberosIV/krb/Attic/get_tf_fullname.c,v b701d62c2304700c4221c6bd7bf9510c CTMFR src/kerberosIV/krb/Attic/get_tf_realm.c,v 5897efee034840b4019e0d61ef8315ac CTMFR src/kerberosIV/krb/Attic/getrealm.c,v 1f4b4c8a7c97b2f6fcd593501e7c4e0a CTMFR src/kerberosIV/krb/Attic/getst.c,v 6a97486a65991bf97aacf88d7b425e92 CTMFR src/kerberosIV/krb/Attic/in_tkt.c,v fd858ab1df68b6fbf1b2efde17494acc CTMFR src/kerberosIV/krb/Attic/k_gethostname.c,v 8a2694578c943e2e468a45e887ca7a85 CTMFR src/kerberosIV/krb/Attic/klog.c,v 0ec022b977b8c33c2237967506464ff0 CTMFR src/kerberosIV/krb/Attic/kname_parse.c,v 448163fe6d67f14ca7a0a426d72047f0 CTMFR src/kerberosIV/krb/Attic/kntoln.c,v f21d7ebe19ddd7c846ab80ca5c319165 CTMFR src/kerberosIV/krb/Attic/kparse.c,v 406496291b19dd0edec49ea6f4e120ac CTMFR src/kerberosIV/krb/Attic/krb_err.et,v 77e5a296222b01934a15bf5014c55d2a CTMFR src/kerberosIV/krb/Attic/krb_err_txt.c,v d1e3cf22fe6face73a627868376f38ad CTMFR src/kerberosIV/krb/Attic/krb_get_in_tkt.c,v 82a16c6876e228d15858c4c9497249fc CTMFR src/kerberosIV/krb/Attic/krbglue.c,v 253d2d1d4dd19177ef68d998f755154f CTMFR src/kerberosIV/krb/Attic/kuserok.c,v 0bcf94ef4f0b3f3b2344ba6309770076 CTMFR src/kerberosIV/krb/Attic/log.c,v 63a40e5d90d7a6e6d68a43e0fba802d6 CTMFR src/kerberosIV/krb/Attic/mk_err.c,v f2b73e6f270428d31d2bd224c7256670 CTMFR src/kerberosIV/krb/Attic/mk_priv.c,v 025cedc3302f0f2e58fc07ff2a9f1636 CTMFR src/kerberosIV/krb/Attic/mk_req.c,v ecac242914de323ca0056e8aa978920d CTMFR src/kerberosIV/krb/Attic/mk_safe.c,v 386d3881a3fd8f1f14ffc0886c2416c5 CTMFR src/kerberosIV/krb/Attic/month_sname.c,v 21f73cad5ef2890796f195a6b68f00ae CTMFR src/kerberosIV/krb/Attic/netread.c,v 1c58134ae80ff0b502bbdca54bec2587 CTMFR src/kerberosIV/krb/Attic/netwrite.c,v a9c5cbba1547c7e224ee333cbf902da6 CTMFR src/kerberosIV/krb/Attic/one.c,v 685963b8d4b1037bafd28b30ff31b8a6 CTMFR src/kerberosIV/krb/Attic/pkt_cipher.c,v 92be32611151f97d5ec5ce1569d2d0a2 CTMFR src/kerberosIV/krb/Attic/pkt_clen.c,v 98204afcfe1712c5d4fa3cb13955ead6 CTMFR src/kerberosIV/krb/Attic/rd_err.c,v 24b0b7c89f5d8aa6631d4e92224c888c CTMFR src/kerberosIV/krb/Attic/rd_priv.c,v 65dbc719d0a4a08eb26cbb5b622f48ef CTMFR src/kerberosIV/krb/Attic/rd_req.c,v bc8079206ea1cd5fc40031b65cf6d5bf CTMFR src/kerberosIV/krb/Attic/rd_safe.c,v cc450c748717307a8013d6f6e3073bb7 CTMFR src/kerberosIV/krb/Attic/read_service_key.c,v b2ebb26b3bfc36d9c8501405c1943dbd CTMFR src/kerberosIV/krb/Attic/recvauth.c,v 57dc888ac5614b5397c2b73b3ac82ba8 CTMFR src/kerberosIV/krb/Attic/save_credentials.c,v f7bc5d3303b9da90a4d308326598f499 CTMFR src/kerberosIV/krb/Attic/send_to_kdc.c,v 055d47023efc4e14900b563f05737825 CTMFR src/kerberosIV/krb/Attic/sendauth.c,v 63447a8a236f9f1dcff0533ea7203c6a CTMFR src/kerberosIV/krb/Attic/stime.c,v 5039a8e0cb9406b1854b56796adc462b CTMFR src/kerberosIV/krb/Attic/tf_shm.c,v 152998eac9fe2f7a171cea094486db68 CTMFR src/kerberosIV/krb/Attic/tf_util.c,v 4ae635c67e5c00acb332ee99fe4b1e8f CTMFR src/kerberosIV/krb/Attic/tkt_string.c,v 194922d0009b05fe25ea68f41e29b88c CTMFR src/kerberosIV/krb/Attic/util.c,v 15c60f48e0ca658fa51098531c06d911 CTMFR src/kerberosIV/ksrvtgt/Attic/Makefile,v 50f20b3f7b4a51b352e393537b26b82b CTMFR src/kerberosIV/ksrvtgt/Attic/ksrvtgt.c,v 60a1c8e323b248da7d527cbfc182da28 CTMFR src/kerberosIV/kstash/Attic/Makefile,v 61fb557c52bc440411207298b8bbb9e0 CTMFR src/kerberosIV/kstash/Attic/kstash.c,v 663a4c4f30a2650a50753432a2af78f5 CTMFR src/kerberosIV/make_fp/Attic/Makefile,v bd6d674cec26ee93758f6b60a6b189ba CTMFR src/kerberosIV/make_fp/Attic/make_fp.c,v eccb99dcf9dca88f4b96394a92b0a437 CTMFR src/kerberosIV/make_ip/Attic/Makefile,v a937c601c5271cfaa3b9b68ec43000ca CTMFR src/kerberosIV/make_ip/Attic/make_ip.c,v 5b6b63ca5ab89e9bc8f54db80d74fc1c CTMFR src/kerberosIV/make_key_perm/Attic/Makefile,v f3c7a9ccb9d052a72dbb96c2be35005f CTMFR src/kerberosIV/make_key_perm/Attic/make_key_perm.c,v 0b440a9d9a0aaf50ba6260d70f7d2b90 CTMFR src/kerberosIV/make_key_perm/Attic/misc.c,v f0d65c76e28ecd5ac21252bdce0b06b4 CTMFR src/kerberosIV/make_keypair/Attic/Makefile,v c8e65a8bd3aa81c6d2a42a02e7a96790 CTMFR src/kerberosIV/make_keypair/Attic/make_keypair.8,v f9f41efbafd0ad3603f797bd87f86fda CTMFR src/kerberosIV/make_keypair/Attic/make_keypair.c,v 10b6af20edb4899dc9dcd82093c276cb CTMFR src/kerberosIV/make_odd/Attic/Makefile,v b3cbfbc83b408fdaa33610dffb5ad5f6 CTMFR src/kerberosIV/make_odd/Attic/make_odd.c,v 6fbbd97514377334a09a052f55cbbc26 CTMFR src/kerberosIV/make_p/Attic/Makefile,v 1f899346da3bd32c256207107370bb56 CTMFR src/kerberosIV/make_p/Attic/make_p.c,v 24a1b405bd2d4df43c62cb0994be60c8 CTMFR src/kerberosIV/make_p_table/Attic/Makefile,v 2d696f20161ec769f37ef45acf46798e CTMFR src/kerberosIV/make_p_table/Attic/make_p_table.c,v e589ad8e186e7b7ba7c4b392d69802b7 CTMFR src/kerberosIV/make_s_table/Attic/Makefile,v 20946865379ba4d3e6b8f1dea0eac792 CTMFR src/kerberosIV/make_s_table/Attic/make_s_table.c,v fbc72f41adfd374f3d843badf2e64f47 CTMFR src/kerberosIV/man/Attic/Makefile,v f70fc1213f4dea4189b912f07a3ac6ae CTMFR src/kerberosIV/man/Attic/acl_check.3,v b03141064de66005cc12e3e2eeb72818 CTMFR src/kerberosIV/man/Attic/des_crypt.3,v bbba73afe79243f61bf64f728de77372 CTMFR src/kerberosIV/man/Attic/ext_srvtab.8,v 2601b7e39dabca498c01acbf4bf7020c CTMFR src/kerberosIV/man/Attic/kdb_destroy.8,v 6e858af1bb8c9ecbdac7a22c07f185de CTMFR src/kerberosIV/man/Attic/kdb_edit.8,v ace71e550bb654bb9f99f1969c772060 CTMFR src/kerberosIV/man/Attic/kdb_init.8,v a08021a41d9b49dacda11e36c6ae7026 CTMFR src/kerberosIV/man/Attic/kdb_util.8,v 6c54bfe4be46b16f0c82e91985c1827f CTMFR src/kerberosIV/man/Attic/kdestroy.1,v d989bc583c8f6bc990a5827dd3b58646 CTMFR src/kerberosIV/man/Attic/kerberos.1,v e2fbc588cab09c0da9552012166374ae CTMFR src/kerberosIV/man/Attic/kinit.1,v 34270b73bca0f036109669d492bc5317 CTMFR src/kerberosIV/man/Attic/klist.1,v 77656b200bf14914967c0a910cdef72c CTMFR src/kerberosIV/man/Attic/krb.3,v d3669a2d732127440ab489cb57dc9f52 CTMFR src/kerberosIV/man/Attic/krb.conf.5,v 66bb23764073284ed843117714250e21 CTMFR src/kerberosIV/man/Attic/krb.realms.5,v 5414cde9c1fde48147e8aa7a040b31fa CTMFR src/kerberosIV/man/Attic/krb_realmofhost.3,v f47d75f5216a57381cc5c2df5cf19d91 CTMFR src/kerberosIV/man/Attic/krb_sendauth.3,v 736faac70cc9a1a75f996ef40f8cdb82 CTMFR src/kerberosIV/man/Attic/krb_set_tkt_string.3,v 0e33b28b31829add4d784fd7e06fc518 CTMFR src/kerberosIV/man/Attic/ksrvtgt.1,v 4cf5d67bed4a4d14dcd85d7b5be08f63 CTMFR src/kerberosIV/man/Attic/kstash.8,v 4702d8dcfbd9491fb44f2b305bfe6e10 CTMFR src/kerberosIV/man/Attic/kuserok.3,v 16c20e9bf6c8a4129a61ff2e4422304b CTMFR src/kerberosIV/man/Attic/tf_util.3,v e5124cf4d84b0333eb452706b55664e1 CTMFR src/kerberosIV/register/Attic/Makefile,v a42ac762dca35aa8b042a2d68686c792 CTMFR src/kerberosIV/register/Attic/pathnames.h,v 9d1304b4da05c66b93b01471972c2abf CTMFR src/kerberosIV/register/Attic/register.1,v 3040967b2ec5bb061b1571379dbc7914 CTMFR src/kerberosIV/register/Attic/register.c,v 8507c6df9e769ebff80850eb0d8c58f4 CTMFR src/kerberosIV/register/Attic/register_proto.h,v 3997e26c80acdd089ff5aed49c4a70cc CTMFR src/kerberosIV/registerd/Attic/Makefile,v 1035a0d74a37ed573f0e0ea5a53ab335 CTMFR src/kerberosIV/registerd/Attic/registerd.8,v 1972115e9399ce08e69650abc7ef65d4 CTMFR src/kerberosIV/registerd/Attic/registerd.c,v 0db727065eaa57d35aaecfd750117b06 CTMDR src/kerberosIV/Attic CTMDR src/kerberosIV/acl/Attic CTMDR src/kerberosIV/acl CTMDR src/kerberosIV/compile_et/Attic CTMDR src/kerberosIV/compile_et/test/Attic CTMDR src/kerberosIV/compile_et/test CTMDR src/kerberosIV/compile_et CTMDR src/kerberosIV/des/Attic CTMDR src/kerberosIV/des/doc/Attic CTMDR src/kerberosIV/des/doc CTMDR src/kerberosIV/des CTMDR src/kerberosIV/ext_srvtab/Attic CTMDR src/kerberosIV/ext_srvtab CTMDR src/kerberosIV/include/Attic CTMDR src/kerberosIV/include CTMDR src/kerberosIV/kdb/Attic CTMDR src/kerberosIV/kdb CTMDR src/kerberosIV/kdb_destroy/Attic CTMDR src/kerberosIV/kdb_destroy CTMDR src/kerberosIV/kdb_edit/Attic CTMDR src/kerberosIV/kdb_edit CTMDR src/kerberosIV/kdb_init/Attic CTMDR src/kerberosIV/kdb_init CTMDR src/kerberosIV/kdb_util/Attic CTMDR src/kerberosIV/kdb_util CTMDR src/kerberosIV/kdestroy/Attic CTMDR src/kerberosIV/kdestroy CTMDR src/kerberosIV/kerberos/Attic CTMDR src/kerberosIV/kerberos CTMDR src/kerberosIV/kinit/Attic CTMDR src/kerberosIV/kinit CTMDR src/kerberosIV/klist/Attic CTMDR src/kerberosIV/klist CTMDR src/kerberosIV/krb/Attic CTMDR src/kerberosIV/krb CTMDR src/kerberosIV/ksrvtgt/Attic CTMDR src/kerberosIV/ksrvtgt CTMDR src/kerberosIV/kstash/Attic CTMDR src/kerberosIV/kstash CTMDR src/kerberosIV/make_fp/Attic CTMDR src/kerberosIV/make_fp CTMDR src/kerberosIV/make_ip/Attic CTMDR src/kerberosIV/make_ip CTMDR src/kerberosIV/make_key_perm/Attic CTMDR src/kerberosIV/make_key_perm CTMDR src/kerberosIV/make_keypair/Attic CTMDR src/kerberosIV/make_keypair CTMDR src/kerberosIV/make_odd/Attic CTMDR src/kerberosIV/make_odd CTMDR src/kerberosIV/make_p/Attic CTMDR src/kerberosIV/make_p CTMDR src/kerberosIV/make_p_table/Attic CTMDR src/kerberosIV/make_p_table CTMDR src/kerberosIV/make_s_table/Attic CTMDR src/kerberosIV/make_s_table CTMDR src/kerberosIV/man/Attic CTMDR src/kerberosIV/man CTMDR src/kerberosIV/register/Attic CTMDR src/kerberosIV/register CTMDR src/kerberosIV/registerd/Attic CTMDR src/kerberosIV/registerd CTMDR src/kerberosIV CTM_END 4841b496543d752f3c7f2fc719c10374 ==================== Julian -- Julian H. Stacey http://www.freebsd.org/~jhs/ Tel. +49 89 268616 From owner-freebsd-current Wed Oct 22 12:34:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA21056 for current-outgoing; Wed, 22 Oct 1997 12:34:30 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA21049 for ; Wed, 22 Oct 1997 12:34:27 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xO6Xw-0007fd-00; Wed, 22 Oct 1997 13:34:24 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.7/8.8.3) with ESMTP id NAA13768; Wed, 22 Oct 1997 13:34:15 -0600 (MDT) Message-Id: <199710221934.NAA13768@harmony.village.org> To: Poul-Henning Kamp Subject: Re: nullfs & current UPDATE! Cc: Ollivier Robert , current@freebsd.org In-reply-to: Your message of "Tue, 21 Oct 1997 21:44:09 +0200." <694.877463049@critter.freebsd.dk> References: <694.877463049@critter.freebsd.dk> Date: Wed, 22 Oct 1997 13:34:15 -0600 From: Warner Losh Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <694.877463049@critter.freebsd.dk> Poul-Henning Kamp writes: : PPPS: would you mind looking at unionfs or lfs next ? please ? :-) Pretty pretty please with sugar on top :-) Warner From owner-freebsd-current Wed Oct 22 14:03:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA27660 for current-outgoing; Wed, 22 Oct 1997 14:03:13 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from chess.inetspace.com (chess.inetspace.com [206.50.163.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA27646 for ; Wed, 22 Oct 1997 14:03:03 -0700 (PDT) (envelope-from kgor@chess.inetspace.com) Received: (from kgor@localhost) by chess.inetspace.com (8.8.5/8.7.3) id QAA00219; Wed, 22 Oct 1997 16:02:22 -0500 (CDT) Date: Wed, 22 Oct 1997 16:02:22 -0500 (CDT) Message-Id: <199710222102.QAA00219@chess.inetspace.com> From: "Kent S. Gordon" To: current@FreeBSD.ORG Subject: 2.2.5 identying SCSI disk as Unknown device Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have done some additional investigation since my previous message (2.2.5BETA hanging in Boot). I have compiled a custom kernel using the RELENG_2_2_5_RELEASE tag that is identifing my root disk as an unknown device and hanging in the boot. This is on a machines that work great with custom kernel using the same config file on 2.2.2. I have changed scsi/scsi_debug.h to define DEBUGTARG to 0. Can anyone suggest where I should look to find out what is the probe to fail? The following in my copy of messages (I copy by hand so some mistakes are possible) that appear on the screen during boot bt0: Bt445S/ 0-ISA(24bit) bus bt0: Your card cannot DMA above 16MB boundary. Bounce buffering enabled. bt0: reading board settings, dma=5, int=11 bt0: version 3.36, fast sync, parity, 32 mbxs, 32 ccbs bt0: targ 0 sync rate=10.00MB/s(100ns), offset=15 bt0: targ 1 sync rate=10.00MB/s(100ns), offset=15 bt0: Using Strict Round robin scheme bt0: Using Strict Round robin scheme bt0 at 0x330 irq 11 drq 5 on isa bt0 waiting for scsi devices to settle probe0(bt0:0:0) : scsi_cmd probe0(bt0:0:0) : scsi_done (bt0:0:0) command 0,0,0,0,0,0-[0 bytes] probe0(bt0:0:0) : scsi_cmd probe0(bt0:0:0) : scsi_done (bt0:0:0) command 12,0,0,0,2c,0-[44 bytes] ------ 0: 00 00 00 00 .. 16: 00 00 00 00 .. 32: 00 00 00 00 .. ------ (bt0:0:0): "unknown unknown ????" type 13 fixed SCSI 0 uk0(bt0:0:0) :uk0attach: uk0(bt0:0:0): Unknown bt0: not taking commands! stopped at _Debugger 0x35 The stack trace from the debugger was (I was to lazy to write down arguments to the function, if needed I can easily get the arguments). Debugger bt_time_out bt_poll bt_scsi_cmd scsi_scsi_cmd scsi_test_unit_ready scsi_probedev scsi_probe_bus scsi_attachdevs bt_attach bt_isa_attach config_isadev_c config_isadev isa_configure configure main This is a copy of the kernel config file used. # # GGZOO -- Cyrix 586/100 with BT controller # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: CHESS,v 1.1 1997/04/07 21:35:16 kgor Exp $ machine "i386" #cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" #cpu "I686_CPU" ident GGZOO maxusers 10 options DDB options DIAGNOSTIC options SCSIDEBUG #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem #options NFS #Network Filesystem #options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] #options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options SCSI_DELAY=5 #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SYSVSHM options SYSVSEM options SYSVMSG options "AUTO_EOI_1" #faster interrupts config kernel root on wd0 controller isa0 #I have a VLB, but no aha28xx cards, that think they are on a eisa bus. #controller eisa0 #controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 #tape ft0 at fdc0 drive 2 #controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr #disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 #controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 #options ATAPI #Enable ATAPI support for IDE bus #options ATAPI_STATIC #Don't do it as an LKM #device wcd0 #IDE CD-ROM # A single entry for any of these controllers (ncr, ahb, ahc) is sufficient # for any number of installed devices. #controller ncr0 #controller ahb0 #controller ahc0 controller bt0 at isa? port "IO_BT0" bio irq ? vector bt_isa_intr #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr #controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr #controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr #controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 #device od0 #See LINT for possible `od' options. #device st0 device cd0 #Only need one of these, the code dynamically grows device ch0 #SCSI media changers #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr #controller matcd0 at isa? port 0x230 bio #device scd0 at isa? port 0x230 bio # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 #options XSERVER # include code for XFree86 #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 # Mandatory, don't remove device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # #device apm0 at isa? disable # Advanced Power Management #options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS # PCCARD (PCMCIA) support #controller crd0 #device pcic0 at crd? #device pcic1 at crd? device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr #device sio2 at isa? disable port "IO_COM3" tty irq 5 vector siointr #device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr #device lpt1 at isa? port? tty #device mse0 at isa? port 0x23c tty irq 5 vector mseintr #device psm0 at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. #device de0 #device fxp0 #device vx0 #device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr #device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr device ed0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr #device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr #device ep0 at isa? port 0x300 net irq 10 vector epintr #device fe0 at isa? port 0x300 net irq ? vector feintr #device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr #device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr #device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr pseudo-device loop pseudo-device ether pseudo-device log #pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 32 pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing This is a copy of the dmesg output from a kernel using RELENG_2_2_2_RELEASE. Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.2-RELEASE #0: Thu Oct 9 08:43:27 CDT 1997 kgor@chess.inetspace.com:/usr/src/sys/compile/CHESS Calibrating clock(s) ... i8254 clock: 1193747 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CPU: i486DX (486-class CPU) real memory = 33554432 (32768K bytes) avail memory = 30666752 (29948K bytes) Probing for devices on the ISA bus: sc0: the current keyboard controller command byte 0045 kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa sc0 at 0x60-0x6f irq 1 on motherboard sc0: BIOS video mode:3 sc0: VGA registers upon power-up 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 ff ff 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: video mode:24 sc0: VGA registers for mode:24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 5 on isa ed0: address 00:00:e8:cb:ac:1a, type NE2000 (16 bit) bpf: ed0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in bt0: Bt445S/ 0-ISA(24bit) bus bt0: Your card cannot DMA above 16MB boundary. Bounce buffering enabled. bt0: reading board settings, dma=5, int=11 bt0: version 3.36, fast sync, parity, 32 mbxs, 32 ccbs bt0: targ 0 sync rate=10.00MB/s(100ns), offset=15 bt0: targ 1 sync rate=10.00MB/s(100ns), offset=15 bt0: Using Strict Round robin scheme bt0 at 0x330 irq 11 drq 5 on isa bt0 waiting for scsi devices to settle (bt0:0:0): "DEC DSP5200S T392" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 1908MB (3907911 512 byte sectors) sd0(bt0:0:0): with 2621 cyls, 21 heads, and an average 71 sectors/track (bt0:1:0): "SEAGATE ST31200N 8648" type 0 fixed SCSI 2 sd1(bt0:1:0): Direct-Access 1006MB (2061108 512 byte sectors) sd1(bt0:1:0): with 2700 cyls, 9 heads, and an average 84 sectors/track npx0 on motherboard npx0: INT 16 interface imasks: bio c0000840, tty c003009a, net c0020020 BIOS Geometries: 0:03ff3f20 0..1023=1024 cylinders, 0..63=64 heads, 1..32=32 sectors 1:03ed3f20 0..1005=1006 cylinders, 0..63=64 heads, 1..32=32 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. changing root device to sd0a configure() finished. bpf: tun0 attached bpf: lo0 attached sd0s1: type 0xa5, start 32, end = 3907583, size 3907552 : OK sd1s1: type 0xa5, start 32, end = 2060287, size 2060256 : OK Thanks, Kent S. Gordon Senior Software Engineer iNetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com From owner-freebsd-current Wed Oct 22 15:04:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02792 for current-outgoing; Wed, 22 Oct 1997 15:04:18 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02664 for ; Wed, 22 Oct 1997 15:03:40 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id AAA03825 for ; Thu, 23 Oct 1997 00:01:20 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id AAA20705 for current@FreeBSD.ORG; Thu, 23 Oct 1997 00:01:15 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id XAA06026; Wed, 22 Oct 1997 23:53:53 +0200 (CEST) (envelope-from roberto) Message-ID: <19971022235352.22444@keltia.freenix.fr> Date: Wed, 22 Oct 1997 23:53:52 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! References: <19971021203807.51847@keltia.freenix.fr> <199710220203.TAA09608@usr03.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710220203.TAA09608@usr03.primenet.com>; from Terry Lambert on Wed, Oct 22, 1997 at 02:03:10AM +0000 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Terry Lambert: > Probably the "correct" way to handle this is to avoid aliases, and > instead establish a null_getpage/null_putpage VOP for page access, > and force it to make the reference to the underlying FS. Something I don't understand is why the vnode layer should be aware of things like pages ? We're talking about files, vnodes and such, not pages. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Wed Oct 22 17:06:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11508 for current-outgoing; Wed, 22 Oct 1997 17:06:47 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11502 for ; Wed, 22 Oct 1997 17:06:44 -0700 (PDT) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id CAA07555; Thu, 23 Oct 1997 02:14:12 +0200 (CEST) From: Mikael Karpberg Message-Id: <199710230014.CAA07555@ocean.campus.luth.se> Subject: Re: -STABLE reboots In-Reply-To: <199710220213.MAA22074@godzilla.zeta.org.au> from Bruce Evans at "Oct 22, 97 12:13:50 pm" To: bde@zeta.org.au (Bruce Evans) Date: Thu, 23 Oct 1997 02:14:12 +0200 (CEST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Bruce Evans: > >> The problem is more serious in -current, since mount(2) is unprivileged, > >> so even `mount /foo /foo' panics (if the mounter is root or owns /foo). > > > >Er... Isn't that easilly solvable by mount checking for the two arguments > >being the same? > > Of course not, or it would have been fixed years ago. `mkdir foo; ln foo Thought that there might be such problems... > bar; mount foo bar' also panics. Checking inodes isn't enough either, Umm, but I thought hardlinking of directories were historic things used nowadays only to scare children with? > since `mkdir foo foo/foo; mount foo/foo foo' also panics. Ack, the last example never occured to me. Wouldn't it help to loop through arg1's part by part, from the root, and check the inodes against arg2's inode, then? cd /a/b/x/ mkdir y mount y x -> inode(a) == inode(x)? inode(b) == inode(x)? inode(x) == inode(x)? Yupp! Abort. Or is there a problem with this too? Except speed maybe? But that shouldn't matter THAT much in mount, should it? /Mikael From owner-freebsd-current Wed Oct 22 17:49:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14257 for current-outgoing; Wed, 22 Oct 1997 17:49:58 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from gaia.coppe.ufrj.br ([146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14225; Wed, 22 Oct 1997 17:49:33 -0700 (PDT) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id WAA07837; Wed, 22 Oct 1997 22:49:21 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199710230049.WAA07837@gaia.coppe.ufrj.br> Subject: Re: Info about MFS In-Reply-To: <199710190245.VAA01206@dyson.iquest.net> from "John S. Dyson" at "Oct 18, 97 09:45:22 pm" To: dyson@FreeBSD.ORG Date: Wed, 22 Oct 1997 22:49:21 -0200 (EDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(John S. Dyson) // My first-cut attempt of fixing MFS only helped a little. It is broken, // and please don't bother using it until I, PHK or someone else fixes it. // I am working on it right now. Talking about MFS remembered me about this. How hard would it be to implement Sun's tmpfs ? It's lots more efficient in terms of memory use and speed than mfs. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-current Wed Oct 22 18:39:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA18151 for current-outgoing; Wed, 22 Oct 1997 18:39:47 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA18137; Wed, 22 Oct 1997 18:39:34 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id UAA11904; Wed, 22 Oct 1997 20:39:25 -0500 (EST) From: "John S. Dyson" Message-Id: <199710230139.UAA11904@dyson.iquest.net> Subject: Re: Info about MFS In-Reply-To: <199710230049.WAA07837@gaia.coppe.ufrj.br> from Joao Carlos Mendes Luis at "Oct 22, 97 10:49:21 pm" To: jonny@coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Wed, 22 Oct 1997 20:39:24 -0500 (EST) Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joao Carlos Mendes Luis said: > #define quoting(John S. Dyson) > // My first-cut attempt of fixing MFS only helped a little. It is broken, > // and please don't bother using it until I, PHK or someone else fixes it. > // I am working on it right now. > > Talking about MFS remembered me about this. > > How hard would it be to implement Sun's tmpfs ? It's lots more > efficient in terms of memory use and speed than mfs. > I have been thinking about something like that (except more of a cross between the two.) Maybe I'll do something this week (I am ill.) -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Wed Oct 22 20:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA23927 for current-outgoing; Wed, 22 Oct 1997 20:17:26 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA23920 for ; Wed, 22 Oct 1997 20:17:22 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id NAA13948; Thu, 23 Oct 1997 13:14:59 +1000 Date: Thu, 23 Oct 1997 13:14:59 +1000 From: Bruce Evans Message-Id: <199710230314.NAA13948@godzilla.zeta.org.au> To: bde@zeta.org.au, karpen@ocean.campus.luth.se Subject: Re: -STABLE reboots Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Of course not, or it would have been fixed years ago. `mkdir foo; ln foo > >Thought that there might be such problems... > >> bar; mount foo bar' also panics. Checking inodes isn't enough either, > >Umm, but I thought hardlinking of directories were historic things used >nowadays only to scare children with? True. I should have said `ln -s foo bar' or used an alias for the name, e.g. ../tmp/foo where foo is in /tmp. >> since `mkdir foo foo/foo; mount foo/foo foo' also panics. > >Ack, the last example never occured to me. Wouldn't it help to loop through >arg1's part by part, from the root, and check the inodes against arg2's >inode, then? > > cd /a/b/x/ > mkdir y > > mount y x -> inode(a) == inode(x)? > inode(b) == inode(x)? > inode(x) == inode(x)? Yupp! Abort. > >Or is there a problem with this too? Only implementation difficulties (deadlock and races), I think. [ufs_]rename() has to do something like this. It unlocks in ufs_checkpath() to avoid deadlock and has some race bugs (it is possible (but very unlikely) for ufs_checkpath() to block and the tree to change in a harmful way). Bruce From owner-freebsd-current Thu Oct 23 00:18:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA05117 for current-outgoing; Thu, 23 Oct 1997 00:18:06 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA05110; Thu, 23 Oct 1997 00:17:59 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id JAA29759; Thu, 23 Oct 1997 09:17:26 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id IAA00366; Thu, 23 Oct 1997 08:36:17 +0200 (CEST) To: Joao Carlos Mendes Luis cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Info about MFS In-reply-to: Your message of "Wed, 22 Oct 1997 22:49:21 -0200." <199710230049.WAA07837@gaia.coppe.ufrj.br> Date: Thu, 23 Oct 1997 08:36:17 +0200 Message-ID: <364.877588577@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199710230049.WAA07837@gaia.coppe.ufrj.br>, Joao Carlos Mendes Luis writes: >#define quoting(John S. Dyson) >// My first-cut attempt of fixing MFS only helped a little. It is broken, >// and please don't bother using it until I, PHK or someone else fixes it. >// I am working on it right now. > >Talking about MFS remembered me about this. > >How hard would it be to implement Sun's tmpfs ? It's lots more >efficient in terms of memory use and speed than mfs. speed wise it's the same, memory use it's a lot better. Not very hard actually. All you have to do is to take a copy of sys/ufs/ffs/* and make it store it all on the swap-space. Many people have talked about this (me included), but nobody have done it so far. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Thu Oct 23 02:03:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA12326 for current-outgoing; Thu, 23 Oct 1997 02:03:13 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from ns2.accesscom.com (ns2.accesscom.com [205.226.156.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA12303 for ; Thu, 23 Oct 1997 02:03:08 -0700 (PDT) (envelope-from reneem@ns2.accesscom.com) From: reneem@ns2.accesscom.com Received: from Default (user8.accesscom.com [205.226.158.8]) by ns2.accesscom.com (8.8.7/8.8.7) with SMTP id CAA09062 for ; Thu, 23 Oct 1997 02:03:03 -0700 Message-Id: <199710230903.CAA09062@ns2.accesscom.com> To: reneem@accesscom.com Date: Thu, 23 Oct 1997 02:01:55 PDT Subject: Pre-launch Opportunity Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This message is being brought to you by EMAIL BLASTER 2.5 software. If you would like a FREE copy of this software or any of our other HOT programs ABSOLTELY FREE call our FAX ON DEMAND number at 213-960-7822. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dear: Friend Promotors needed for a unique new program in pre-launch. Get in now at the very top, don't let this one pass you by. Recruit other promotors and customers. The product and the program are something you will not find anywhere else on the web. We offer free expert information. That's right, in the privacy of your own home you can have an expert respond with an answer, all for FREE!! Our experts are trained professionals. Lawyers, Doctors, Accountants, Real Estate and Banking just to name a few, there are many other professions covered also. Now, how hard can it be to recruit promotors and customers for a FREE service like this? This is a win/win program. Now is the time to join us and tell all your friends about this too. If you would like more information on this FREE opportunity please e-mail me at the following: reneem@accesscom.com Thank you for your time and please forgive me if this e-mail has caused you any inconvience. From owner-freebsd-current Thu Oct 23 04:28:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA19902 for current-outgoing; Thu, 23 Oct 1997 04:28:45 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA19897 for ; Thu, 23 Oct 1997 04:28:42 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id GAA01033; Thu, 23 Oct 1997 06:28:24 -0500 (EST) From: "John S. Dyson" Message-Id: <199710231128.GAA01033@dyson.iquest.net> Subject: Re: nullfs & current UPDATE! In-Reply-To: <19971022235352.22444@keltia.freenix.fr> from Ollivier Robert at "Oct 22, 97 11:53:52 pm" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Thu, 23 Oct 1997 06:28:24 -0500 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert said: > According to Terry Lambert: > > Probably the "correct" way to handle this is to avoid aliases, and > > instead establish a null_getpage/null_putpage VOP for page access, > > and force it to make the reference to the underlying FS. > > Something I don't understand is why the vnode layer should be aware of > things like pages ? We're talking about files, vnodes and such, not pages. > and objects. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Thu Oct 23 08:17:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA03248 for current-outgoing; Thu, 23 Oct 1997 08:17:08 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA03241 for ; Thu, 23 Oct 1997 08:17:04 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id AAA00747; Fri, 24 Oct 1997 00:43:17 +0930 (CST) Message-Id: <199710231513.AAA00747@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: John-Mark Gurney cc: FreeBSD Current Subject: Re: Doug Rabson's kernel linker code.. In-reply-to: Your message of "Sat, 18 Oct 1997 01:47:31 MST." <19971018014731.31913@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 00:43:15 +0930 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry about the delay here. > well.. I was reading through the code to get a better understand of > it.. and I think that we need to export the make variable LOAD_ADDRESS > from the Makefile to kernel, as the file kern/link_aout.c has this same > value hard coded in it... > > should something like: > load_address.h: > echo "#define LOAD_ADDRESS ${LOAD_ADDRESS}" > ${.TARGET} > > and include it from kern_link_aout.c? Do you want to do this, or set it at runtime based on the real load address? I realise that at the moment the load address is fixed by the link phase... mike From owner-freebsd-current Thu Oct 23 09:10:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06690 for current-outgoing; Thu, 23 Oct 1997 09:10:37 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from wall.jhs.no_domain (vector.muc.ditec.de [194.120.126.35]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA06680; Thu, 23 Oct 1997 09:10:20 -0700 (PDT) (envelope-from jhs@wall.jhs.no_domain) Received: from wall.jhs.no_domain (localhost [127.0.0.1]) by wall.jhs.no_domain (8.8.5/8.6.9) with ESMTP id VAA01788; Wed, 22 Oct 1997 21:14:19 +0100 (MET) Message-Id: <199710222014.VAA01788@wall.jhs.no_domain> To: Richard Wackerbarth cc: current@FreeBSD.ORG Subject: Re: Notice of Temporary Suspension of Updates From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: Home: Customer: X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Web: http://www.freebsd.org/~jhs/ (including PGP key) X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Tel: Home: +49.89.268616 Work: +49.89.607.29788 X-Fax: Home: +49.89.2608126 Work: +49.89.607.32158 X-Data: Home: +49.89.26023276 X-Company: Vector Systems Ltd, Unix & Internet Consultants X-Mailer: EXMH 1.6.9 on FreeBSD (Unix) In-reply-to: Your message of "Tue, 21 Oct 1997 20:21:31 CDT." Date: Wed, 22 Oct 1997 22:14:19 +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Reference: > From: Richard Wackerbarth > Date: Tue, 21 Oct 1997 20:21:31 -0500 > Message-id: > To: ctm-announce@FreeBSD.ORG I'm following up to current@ to avoid flooding the low traffic announce@ ... Hi, Richard Wackerbarth wrote: > This notice affects all "domestic" (US) CTM feeds; cvs-cur, src-cur, > src-2_2, src-2_1, and ports-cur are all affected. > > All updates are SUSPENDED to allow us to bring them into conformity with > the soon-to-be-released > FreeBSD 2.2.5 CD. As soon as the "rush" copy of the CD arrives, I will > update each feed to match the information on the CD. Then I will resume the > normally scheduled distribution of deltas. I do not expect this to be a > significant delay. The CD is already in transit. > > I have chosen to do this because the advantage of being able to use the > 2.2.5 CD for a baseline > outweighs the disadvantage caused by the slight delay. > > I encourage everyone to obtain the 2.2.5 Release CD. Those using CTM or > CVSUP to update can > significantly reduce the huge file transfer involved in starting the update > process. > > My apologies to anyone that this may inconvenience. > > Richard Wackerbarth > CTM-Meister > > ctm@freebsd.org > Sorry, am I missing something ? I can't see the necessity of forcing people to either { wait to get their CD, or ftp a set of mega large base deltas } if they have old CTM baselines that are still serving well; I for instance am still using these ancient bases: src-cur.1900A.gz ports-cur.1200A.gz cvs-cur.1500A.gz gnats.0100A.gz + all subsequent deltas. OK, they take a while to build, but its better than ftp'ing monster files, & rebuilds are rare. It'd be really nice if you just kept pumping out the deltas for now, please, & after the CD's arrive, we can make up much smaller ctm to cd &/or cd to ctm conversion tars or whatever the collective wisdom decides is needed. I'm expecting a CD (not a rush, just a standard, & that across the Atlantic), I have 4 gig spare right now, & a 200 5MMX 64 with mostly spare cycles, so would be happy to help out generating stuff (I'm dial up though, so after generating I'd upload to {http://www.freebsd.org/~jhs/ &/or ftp/incoming} to distribute it.) Let me know if & how I can be of help. PS I also have a trusted mature tree stripping (& comparing) program available: http://www.freebsd.org/~jhs/src/bsd/jhs/bin/public/cmpd/cmpd.c It's never yet burnt my fingers (& is 10 years old!). Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Thu Oct 23 09:41:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA09235 for current-outgoing; Thu, 23 Oct 1997 09:41:47 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09225 for ; Thu, 23 Oct 1997 09:41:42 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id JAA17015; Thu, 23 Oct 1997 09:41:20 -0700 (PDT) Message-ID: <19971023094120.57364@hydrogen.nike.efn.org> Date: Thu, 23 Oct 1997 09:41:20 -0700 From: John-Mark Gurney To: Mike Smith Cc: FreeBSD Current Subject: Re: Doug Rabson's kernel linker code.. References: <19971018014731.31913@hydrogen.nike.efn.org> <199710231513.AAA00747@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710231513.AAA00747@word.smith.net.au>; from Mike Smith on Fri, Oct 24, 1997 at 12:43:15AM +0930 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Smith scribbled this message on Oct 24: > > Sorry about the delay here. > > > well.. I was reading through the code to get a better understand of > > it.. and I think that we need to export the make variable LOAD_ADDRESS > > from the Makefile to kernel, as the file kern/link_aout.c has this same > > value hard coded in it... > > > > should something like: > > load_address.h: > > echo "#define LOAD_ADDRESS ${LOAD_ADDRESS}" > ${.TARGET} > > > > and include it from kern_link_aout.c? > > Do you want to do this, or set it at runtime based on the real load > address? I realise that at the moment the load address is fixed by the > link phase... actually... I need the information about the kernel's address and the size of it... right now it just uses a constant of 0xf0100000 and the size is the negative of that... I'm not sure if this information is actually used, or is just kept for consistancy... and I don't need the information till SI_SUB_KMEM... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Oct 23 09:56:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10265 for current-outgoing; Thu, 23 Oct 1997 09:56:25 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10250 for ; Thu, 23 Oct 1997 09:56:14 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id CAA01365; Fri, 24 Oct 1997 02:22:30 +0930 (CST) Message-Id: <199710231652.CAA01365@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: John-Mark Gurney cc: Mike Smith , FreeBSD Current Subject: Re: Doug Rabson's kernel linker code.. In-reply-to: Your message of "Thu, 23 Oct 1997 09:41:20 MST." <19971023094120.57364@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 02:22:27 +0930 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > well.. I was reading through the code to get a better understand of > > > it.. and I think that we need to export the make variable LOAD_ADDRESS > > > from the Makefile to kernel, as the file kern/link_aout.c has this same > > > value hard coded in it... ... > > Do you want to do this, or set it at runtime based on the real load > > address? I realise that at the moment the load address is fixed by the > > link phase... > > actually... I need the information about the kernel's address and the > size of it... right now it just uses a constant of 0xf0100000 and the > size is the negative of that... I'm not sure if this information is > actually used, or is just kept for consistancy... and I don't need the > information till SI_SUB_KMEM... You really... leave me hanging on... your every phrase... as though it might be your last... 8) It should be possible at that stage to reference the various symbols set when the kernel is loaded and started; looking at create_pagetables in i386/i386/locore.S I see that KERNend is set to the end of the kernel plus any symbol table. Note that other space is allocated after this. As far as I can tell, btext is going to be the lowest symbol in the kernel, so you can prettymuch be sure that: extern void *btext; extern long KERNend; will give you some numbers that you can work with. The types are bogus; I'm not sure this is worth worrying about. Bruce may have more to say on the topic; this is from inspection only. mike From owner-freebsd-current Thu Oct 23 11:13:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15700 for current-outgoing; Thu, 23 Oct 1997 11:13:47 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15676 for ; Thu, 23 Oct 1997 11:13:28 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id TAA28149 for current@FreeBSD.ORG; Thu, 23 Oct 1997 19:00:52 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id TAA24761; Thu, 23 Oct 1997 19:33:16 +0200 (CEST) (envelope-from andreas) Message-ID: <19971023193316.42240@klemm.gtn.com> Date: Thu, 23 Oct 1997 19:33:16 +0200 From: Andreas Klemm To: current@FreeBSD.ORG Subject: make world: usr.sbin/ppp/timer.c:233: conflicting types for `usleep' Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Can't build the world as of yesterday. -- Andreas Klemm powered by ,,symmetric multiprocessor FreeBSD'' From owner-freebsd-current Thu Oct 23 11:22:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16344 for current-outgoing; Thu, 23 Oct 1997 11:22:56 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16337; Thu, 23 Oct 1997 11:22:53 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA16609; Thu, 23 Oct 1997 11:22:50 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd016600; Thu Oct 23 11:22:40 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA29050; Thu, 23 Oct 1997 11:22:29 -0700 (MST) From: Terry Lambert Message-Id: <199710231822.LAA29050@usr02.primenet.com> Subject: Re: Recursive mount [ was Re: -STABLE reboots ] To: kato@migmatite.eps.nagoya-u.ac.jp (KATO Takenori) Date: Thu, 23 Oct 1997 18:22:29 +0000 (GMT) Cc: dwmalone@maths.tcd.ie, current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <199710221247.VAA01644@gneiss.eps.nagoya-u.ac.jp> from "KATO Takenori" at Oct 22, 97 09:47:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Could someone add a sysctl to current that makes > > mount a privilaged syscall? > > How about following patch? [ ... ] Makeing mount priveledged is a kludge. Is this a production environment patch? If so, I'll let the discussion go... otherwise, the mount code needs changed. Specifically, the mapping into the hierarchy and the NFS export management should be in the upper level code instead of per VFS. There's not really any conceptual difference between root and non-root mounts, once the greation of a mount struct instance is abstracted from it's mapping into the FS hierarchy by moving the latter into common code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Oct 23 11:29:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16753 for current-outgoing; Thu, 23 Oct 1997 11:29:38 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16747 for ; Thu, 23 Oct 1997 11:29:31 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id LAA02700; Thu, 23 Oct 1997 11:29:18 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd002681; Thu Oct 23 11:29:09 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA29304; Thu, 23 Oct 1997 11:28:40 -0700 (MST) From: Terry Lambert Message-Id: <199710231828.LAA29304@usr02.primenet.com> Subject: Re: nullfs & current UPDATE! To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Thu, 23 Oct 1997 18:28:35 +0000 (GMT) Cc: current@FreeBSD.ORG In-Reply-To: <19971022235352.22444@keltia.freenix.fr> from "Ollivier Robert" at Oct 22, 97 11:53:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Probably the "correct" way to handle this is to avoid aliases, and > > instead establish a null_getpage/null_putpage VOP for page access, > > and force it to make the reference to the underlying FS. > > Something I don't understand is why the vnode layer should be aware of > things like pages ? We're talking about files, vnodes and such, not pages. It shouldn't. Rather, it should know which vnode the cached pages are hung off, so it can tell the vnode pager, so the vnode pager doesn't have to have specific knowledge of nullfs, unionfs, uidfs, cryptfs, etc., etc.. What you are saying is "give me the underlying vnode backing the object I am referencing: I know it might be one you have proxied instead of one of yours". This is very different than the SVR4/Solaris VOP_GETPAGE/VOP_PUTPAGE; the intent of *that* code is to maintain coherency between the VM and buffer cache for memory mapped files. The BSD version of the code would not be for cache coherency, it would be for alias avoidance for the current page alias problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Oct 23 11:33:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA17031 for current-outgoing; Thu, 23 Oct 1997 11:33:15 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA17026 for ; Thu, 23 Oct 1997 11:33:09 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id LAA03011; Thu, 23 Oct 1997 11:33:08 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd003008; Thu Oct 23 11:33:07 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA29634; Thu, 23 Oct 1997 11:33:03 -0700 (MST) From: Terry Lambert Message-Id: <199710231833.LAA29634@usr02.primenet.com> Subject: Re: nullfs & current UPDATE! To: Tor.Egge@idi.ntnu.no (Tor Egge) Date: Thu, 23 Oct 1997 18:33:03 +0000 (GMT) Cc: roberto@keltia.freenix.fr, current@FreeBSD.ORG In-Reply-To: <199710221615.SAA17560@pat.idi.ntnu.no> from "Tor Egge" at Oct 22, 97 06:15:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > By using the following patch, I've been able to create and delete hundreds > > of files in a nullfs mounted directory. No vnode leak as far as I can see > > from the sysctl debug.numvnodes. fsck reports no missing blocks. No panic, > > just works. Now that seems too easy :-) [ ... ] > > Opinions about this ? > > Yes. > > This patch causes open files to be truncated to zero length if nullfs > is used to unlink the file. > > e.g., when A and B are different shells: > > A: mount -t null /tmp /mnt > A. jot 1000000 1 > /tmp/test > A: more /tmp/test > B: rm /mnt/test # while A: is still at top of file > A: # Go to bottom of file. > > then the last part of the file is lost. If B performes `rm /tmp/test' > instead of `rm /mnt/test' then this problem does not occur. > > This leads me to believe that this patch has some unwanted > undocumented side effects due to calling VOP_INACTIVE without regard > to lowervp->usecount. I should have realized this as well; it's an obvious side effect of the destruction of the alias reference before the destruction of the object. I really think the idea of reference needs to be revisited. For example, I would like to see the name cache entry treated as a reference instance as well. To do both of these right requires some changes to the vnode recycling code. 8-(. It would be easier to do if vclean would just die... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Oct 23 13:03:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23641 for current-outgoing; Thu, 23 Oct 1997 13:03:55 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA23598 for ; Thu, 23 Oct 1997 13:03:32 -0700 (PDT) (envelope-from wosch@cs.tu-berlin.de) Received: from panke.panke.de (anonymous229.ppp.cs.tu-berlin.de [130.149.17.229]) by mail.cs.tu-berlin.de (8.8.6/8.8.7) with ESMTP id VAA08394; Thu, 23 Oct 1997 21:59:24 +0200 (MET DST) Received: (from wosch@localhost) by panke.panke.de (8.8.5/8.6.12) id VAA01795; Thu, 23 Oct 1997 21:54:17 +0200 (MET DST) To: Bruce Evans Cc: karpen@ocean.campus.luth.se, current@FreeBSD.ORG Subject: Re: -STABLE reboots References: <199710220213.MAA22074@godzilla.zeta.org.au> From: Wolfram Schneider Date: 23 Oct 1997 21:54:14 +0200 In-Reply-To: Bruce Evans's message of Wed, 22 Oct 1997 12:13:50 +1000 Message-ID: Lines: 15 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: > >> The problem is more serious in -current, since mount(2) is unprivileged, > >> so even `mount /foo /foo' panics (if the mounter is root or owns /foo). > > > >Er... Isn't that easilly solvable by mount checking for the two arguments > >being the same? > > Of course not, or it would have been fixed years ago. `mkdir foo; ln foo > bar; mount foo bar' also panics. Checking inodes isn't enough either, > since `mkdir foo foo/foo; mount foo/foo foo' also panics. But it would fix the problem for *users* in most cases. -- Wolfram Schneider http://www.apfel.de/~wosch/ From owner-freebsd-current Thu Oct 23 13:04:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23641 for current-outgoing; Thu, 23 Oct 1997 13:03:55 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA23598 for ; Thu, 23 Oct 1997 13:03:32 -0700 (PDT) (envelope-from wosch@cs.tu-berlin.de) Received: from panke.panke.de (anonymous229.ppp.cs.tu-berlin.de [130.149.17.229]) by mail.cs.tu-berlin.de (8.8.6/8.8.7) with ESMTP id VAA08394; Thu, 23 Oct 1997 21:59:24 +0200 (MET DST) Received: (from wosch@localhost) by panke.panke.de (8.8.5/8.6.12) id VAA01795; Thu, 23 Oct 1997 21:54:17 +0200 (MET DST) To: Bruce Evans Cc: karpen@ocean.campus.luth.se, current@FreeBSD.ORG Subject: Re: -STABLE reboots References: <199710220213.MAA22074@godzilla.zeta.org.au> From: Wolfram Schneider Date: 23 Oct 1997 21:54:14 +0200 In-Reply-To: Bruce Evans's message of Wed, 22 Oct 1997 12:13:50 +1000 Message-ID: Lines: 15 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: > >> The problem is more serious in -current, since mount(2) is unprivileged, > >> so even `mount /foo /foo' panics (if the mounter is root or owns /foo). > > > >Er... Isn't that easilly solvable by mount checking for the two arguments > >being the same? > > Of course not, or it would have been fixed years ago. `mkdir foo; ln foo > bar; mount foo bar' also panics. Checking inodes isn't enough either, > since `mkdir foo foo/foo; mount foo/foo foo' also panics. But it would fix the problem for *users* in most cases. -- Wolfram Schneider http://www.apfel.de/~wosch/ From owner-freebsd-current Thu Oct 23 13:12:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24467 for current-outgoing; Thu, 23 Oct 1997 13:12:20 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24461 for ; Thu, 23 Oct 1997 13:12:16 -0700 (PDT) (envelope-from Tor.Egge@idi.ntnu.no) Received: from idt.unit.no (tegge@presis.idi.ntnu.no [129.241.111.173]) by pat.idi.ntnu.no (8.8.6/8.8.6) with ESMTP id WAA00277; Thu, 23 Oct 1997 22:12:07 +0200 (MET DST) Message-Id: <199710232012.WAA00277@pat.idi.ntnu.no> To: Tor.Egge@idi.ntnu.no Cc: roberto@keltia.freenix.fr, current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! In-Reply-To: Your message of "Wed, 22 Oct 1997 18:15:13 +0200" References: <199710221615.SAA17560@pat.idi.ntnu.no> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 23 Oct 1997 20:12:07 +0000 From: Tor Egge Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I wrote: > An unconditional call to vrecycle (with ap->a_vp as first argument) in > the end of null_inactive (after VOP_UNLOCK) might be an alternate > solution with less side effects. That should cause an immediate vrele > of the underlying vnode where VOP_INACTIVE is called if usecount > reaches zero. I'm currently using the following patch, which seems to work. Index: sys/miscfs/nullfs/null_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/nullfs/null_vnops.c,v retrieving revision 1.25 diff -c -r1.25 null_vnops.c *** null_vnops.c 1997/10/21 21:01:34 1.25 --- null_vnops.c 1997/10/23 18:58:30 *************** *** 184,189 **** --- 184,191 ---- #include #include #include + #include + #include static int null_bug_bypass = 0; /* for debugging: enables bypass printf'ing */ SYSCTL_INT(_debug, OID_AUTO, nullfs_bug_bypass, CTLFLAG_RW, *************** *** 200,205 **** --- 202,209 ---- static int null_setattr __P((struct vop_setattr_args *ap)); static int null_strategy __P((struct vop_strategy_args *ap)); static int null_unlock __P((struct vop_unlock_args *ap)); + static int null_rename __P((struct vop_rename_args *ap)); + static int null_remove __P((struct vop_remove_args *ap)); /* * This is the 10-Apr-92 bypass routine. *************** *** 533,548 **** struct proc *a_p; } */ *ap; { - struct vnode *vp = ap->a_vp; - struct null_node *xp = VTONULL(vp); - struct vnode *lowervp = xp->null_lowervp; /* * Do nothing (and _don't_ bypass). * Wait to vrele lowervp until reclaim, * so that until then our null_node is in the * cache and reusable. - * We still have to tell the lower layer the vnode - * is now inactive though. * * NEEDSWORK: Someday, consider inactive'ing * the lowervp and then trying to reactivate it --- 537,547 ---- *************** *** 550,557 **** * like they do in the name lookup cache code. * That's too much work for now. */ - VOP_INACTIVE(lowervp, ap->a_p); VOP_UNLOCK(ap->a_vp, 0, ap->a_p); return (0); } --- 549,556 ---- * like they do in the name lookup cache code. * That's too much work for now. */ VOP_UNLOCK(ap->a_vp, 0, ap->a_p); + vrecycle(ap->a_vp, (struct simplelock *) 0, ap->a_p); return (0); } *************** *** 580,585 **** --- 579,626 ---- } static int + null_rename(ap) + struct vop_rename_args /* { + struct vnodeop_desc *a_desc; + struct vnode *a_fdvp; + struct vnode *a_fvp; + struct componentname *a_fcnp; + struct vnode *a_tdvp; + struct vnode *a_tvp; + struct componentname *a_tcnp; + } */ *ap; + { + /* + * XXX: + * The rename system call calls vnode_pager_uncache on + * the upper vnode. Propagate this to lower layers. + */ + if (ap->a_tvp) + (void) vnode_pager_uncache(NULLVPTOLOWERVP(ap->a_tvp), + ap->a_tcnp->cn_proc); + return null_bypass((struct vop_generic_args *) ap); + } + + static int + null_remove(ap) + struct vop_remove_args /* { + struct vnodeop_desc *a_desc; + struct vnode *a_dvp; + struct vnode *a_vp; + struct componentname *a_cnp; + } */ *ap; + { + /* + * XXX: + * The unlink system call calls vnode_pager_uncache on + * the upper vnode. Propagate this to lower layers. + */ + (void) vnode_pager_uncache(NULLVPTOLOWERVP(ap->a_vp), + ap->a_cnp->cn_proc); + return null_bypass((struct vop_generic_args *) ap); + } + + static int null_print(ap) struct vop_print_args /* { struct vnode *a_vp; *************** *** 654,659 **** --- 695,702 ---- { &vop_lookup_desc, (vop_t *) null_lookup }, { &vop_print_desc, (vop_t *) null_print }, { &vop_reclaim_desc, (vop_t *) null_reclaim }, + { &vop_remove_desc, (vop_t *) null_remove }, + { &vop_rename_desc, (vop_t *) null_rename }, { &vop_setattr_desc, (vop_t *) null_setattr }, { &vop_strategy_desc, (vop_t *) null_strategy }, { &vop_unlock_desc, (vop_t *) null_unlock }, - Tor Egge From owner-freebsd-current Thu Oct 23 14:54:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA00650 for current-outgoing; Thu, 23 Oct 1997 14:54:26 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA00640 for ; Thu, 23 Oct 1997 14:54:24 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id OAA15545; Thu, 23 Oct 1997 14:54:22 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd015527; Thu Oct 23 14:54:14 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA08264; Thu, 23 Oct 1997 14:54:00 -0700 (MST) From: Terry Lambert Message-Id: <199710232154.OAA08264@usr05.primenet.com> Subject: Re: nullfs & current UPDATE! To: Tor.Egge@idi.ntnu.no (Tor Egge) Date: Thu, 23 Oct 1997 21:54:00 +0000 (GMT) Cc: Tor.Egge@idi.ntnu.no, roberto@keltia.freenix.fr, current@FreeBSD.ORG In-Reply-To: <199710232012.WAA00277@pat.idi.ntnu.no> from "Tor Egge" at Oct 23, 97 08:12:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > An unconditional call to vrecycle (with ap->a_vp as first argument) in > > the end of null_inactive (after VOP_UNLOCK) might be an alternate > > solution with less side effects. That should cause an immediate vrele > > of the underlying vnode where VOP_INACTIVE is called if usecount > > reaches zero. > > I'm currently using the following patch, which seems to work. [ ... ] Let me repeat my objection, this time in laymans terms: If you start filling in the funtion table, your nullfs is not very NULL, now is it? This is *not* the right approach to solving this problem; it's a kludge, and it shouldn't be perpetuated. Also: try deleting the file backing a running application with this new patch and you unconditional vrecycle() call... see what happens? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Oct 23 17:01:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA07285 for current-outgoing; Thu, 23 Oct 1997 17:01:46 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA07270 for ; Thu, 23 Oct 1997 17:01:40 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id RAA17722; Thu, 23 Oct 1997 17:01:30 -0700 (PDT) Message-ID: <19971023170130.55831@hydrogen.nike.efn.org> Date: Thu, 23 Oct 1997 17:01:30 -0700 From: John-Mark Gurney To: Mike Smith Cc: FreeBSD Current Subject: Re: Doug Rabson's kernel linker code.. References: <19971023094120.57364@hydrogen.nike.efn.org> <199710231652.CAA01365@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710231652.CAA01365@word.smith.net.au>; from Mike Smith on Fri, Oct 24, 1997 at 02:22:27AM +0930 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Smith scribbled this message on Oct 24: > > > > well.. I was reading through the code to get a better understand of > > > > it.. and I think that we need to export the make variable LOAD_ADDRESS > > > > from the Makefile to kernel, as the file kern/link_aout.c has this same > > > > value hard coded in it... > ... > > > Do you want to do this, or set it at runtime based on the real load > > > address? I realise that at the moment the load address is fixed by the > > > link phase... > > > > actually... I need the information about the kernel's address and the > > size of it... right now it just uses a constant of 0xf0100000 and the > > size is the negative of that... I'm not sure if this information is > > actually used, or is just kept for consistancy... and I don't need the > > information till SI_SUB_KMEM... > > It should be possible at that stage to reference the various symbols > set when the kernel is loaded and started; looking at create_pagetables > in i386/i386/locore.S I see that KERNend is set to the end of the > kernel plus any symbol table. hmm.. any machine independant way to get this information? > Note that other space is allocated after this. > > As far as I can tell, btext is going to be the lowest symbol in the > kernel, so you can prettymuch be sure that: > > extern void *btext; > extern long KERNend; > > will give you some numbers that you can work with. The types are > bogus; I'm not sure this is worth worrying about. Bruce may have more > to say on the topic; this is from inspection only. yeh.. well.. as I stated about.. the file that needs this is kern/link_aout.c... and I don't really want to reference machine specific symbols... unless we require all machines to contain these symbols.. the other option is to do something were we move the running of SYSINIT into kern_linker.c... and then at boot time we simply "link" in the kernel as we do with kld modules... this would require extensions to kern_linker.c to support linking of a memory address.. but this wouldn't be hard to do... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Oct 23 20:03:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA16059 for current-outgoing; Thu, 23 Oct 1997 20:03:39 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA16053 for ; Thu, 23 Oct 1997 20:03:32 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id MAA00673; Fri, 24 Oct 1997 12:28:55 +0930 (CST) Message-Id: <199710240258.MAA00673@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: John-Mark Gurney cc: Mike Smith , FreeBSD Current Subject: Re: Doug Rabson's kernel linker code.. In-reply-to: Your message of "Thu, 23 Oct 1997 17:01:30 MST." <19971023170130.55831@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 12:28:55 +0930 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It should be possible at that stage to reference the various symbols > > set when the kernel is loaded and started; looking at create_pagetables > > in i386/i386/locore.S I see that KERNend is set to the end of the > > kernel plus any symbol table. > > hmm.. any machine independant way to get this information? Not really, no. It's reasonably dependant on the load format and technique used by a particular architecture. > yeh.. well.. as I stated about.. the file that needs this is > kern/link_aout.c... and I don't really want to reference machine specific > symbols... unless we require all machines to contain these symbols.. This is no better or worse than using a compile-time manifest constant. > the other option is to do something were we move the running of SYSINIT > into kern_linker.c... and then at boot time we simply "link" in the > kernel as we do with kld modules... this would require extensions to > kern_linker.c to support linking of a memory address.. but this wouldn't > be hard to do... If I read you correctly here, this is basically the first step in making the kernel boot-time linkable. I think that everyone that's ever been interested in this issue is standing on their chairs yelling "GO!" at you about now... mike From owner-freebsd-current Fri Oct 24 02:07:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA04676 for current-outgoing; Fri, 24 Oct 1997 02:07:27 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA04668 for ; Fri, 24 Oct 1997 02:07:23 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id CAA22506; Fri, 24 Oct 1997 02:07:21 -0700 (PDT) Message-ID: <19971024020720.16884@hydrogen.nike.efn.org> Date: Fri, 24 Oct 1997 02:07:20 -0700 From: John-Mark Gurney To: FreeBSD Current Subject: vfs patch to make vfs kld friendly... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well... I've gotten a patch to make the VFS layer kld friendly... it works fine over here.. and as an included bonus you can continue to use lkm's... :) url: http://freefall.freebsd.org/~jmg/vfs.patch review/comments/suggestions welcome overview: The kld system is based upon the idea that everything is initalized through SYSINIT. As it stands, there are a few routines that do inital VFS layer work, but it does all the work for the staticly compiled VFS layers. This isn't compatible with kld system. These patches simply rework how initalization of the VFS layer happens and adds a SYSINIT to initalize each layer. I modified vfs_opv_init to operate on one struct vnodeopv_desc instead of a NULL terminated array of pointers to vnodeopv_desc. These changes have no visable effect on a non-kld system. I had to add a function vfs_mod_handler that handles the module load/unload events that the kld system requires/deliveres. Even on a non-kld system, a module load event will be delivered to staticly compiled objects, but I'm running a normal kernel with these patches without problems. P.S. Anybody have a good idea of what I should do upon MOD_SHUTDOWN? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Fri Oct 24 03:12:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA06947 for current-outgoing; Fri, 24 Oct 1997 03:12:34 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from solist. ([193.219.246.204]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA06941; Fri, 24 Oct 1997 03:12:29 -0700 (PDT) (envelope-from girgen@partitur.se) Received: from partitur.se by solist. (SMI-8.6/SMI-SVR4) id MAA02559; Fri, 24 Oct 1997 12:10:47 +0200 Message-ID: <34507427.7975BEFD@partitur.se> Date: Fri, 24 Oct 1997 12:10:47 +0200 From: Palle Girgensohn Organization: Partitur X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG CC: dwmalone@maths.tcd.ie, gnat@frii.com, current@FreeBSD.ORG Subject: Re: -STABLE reboots References: <199710220037.KAA17789@godzilla.zeta.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi! I have a similar problem, that I have seen before, although not this bad: I rebooted an nfs server yesterday evening, after a kernel rebuild. Today, a df on a workstation that had the server mounted prduced an immediate crash (no kernel panic, really; the screen just went black), and the system rebooted! I have never seen a FreeBSD machine crash before, at least from software(?) error! The stable is a few weeks old: Thu Oct 9 10:45:58 CEST 1997 How do I prevent this? It is not the first time nfs gives me problems when I take down a server. My guess is that I need to uncomment a few lines in inetd.conf regarding rpc.* so the server can broadcast that it is going down. Now it's untouched from the release. Am I right? Regards, Palle From owner-freebsd-current Fri Oct 24 03:44:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA08461 for current-outgoing; Fri, 24 Oct 1997 03:44:50 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from ns1.he.net (ns1.he.net [207.33.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA08453 for ; Fri, 24 Oct 1997 03:44:48 -0700 (PDT) (envelope-from fantasy@ocea.es) From: fantasy@ocea.es Received: from user900.meznet4.net (ocea.es [194.179.66.2]) by ns1.he.net (8.8.6/8.8.2) with SMTP id DAA09351; Fri, 24 Oct 1997 03:38:42 -0700 Message-Id: <199710241038.DAA09351@ns1.he.net> To: cumeater@eighteen.net Subject: New and changed *! Reply-To: fantasy@ocea.es Date: Fri, 8 Sep 97 14:24:52 EST Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk *** Important Message - Sent Using The Zenith Bulk Emailer *** For A FREE Copy Of The Zenith Bulk Emailer See The End Of This Email Dear Internet user, This is NOT a SPAM message..so please read the information. This e-mail contains information about ADULT sites! So DELETE this message if you don't want to read further.. Hi, we are an Erotic Internet Service Provider, and located in Mallorca, Spain (Yes.. the Sunny island) We send you this e-mail to let you know a few IMPORTANT items... First: You can WIN a FREE vacation to: the Caribbean! (yes, for FREE) All you have to do is take a look at our NEW and IMPROVED Club on the site of Fantasy Dreams (http://www.fantasy-dreams.com) We have NO erotic picutures displayed, so minors won't see anything! Also, we changed to another Country, (from Holland to Spain) and this is also the reason WHY we send you this e-mail. We used to have an URL (domain) called: www.fantasy-dreams.nl BUT... This is changed into http://www.fantasy-dreams.com To a COM name, to let MORE visitors at our site. We like to introduce you to our brand new site with much graphics.. (our Webmaster(s) did a fine job) If you want to see more ADULT sites, you allways are FREE to visit one of these sites...(they are friends of us) and need some visitors!!! http://www.fantasy-dreams.com (ADULT-SITE) (STRIPTEASE-LIVE) http://www.pornolandia.com (ADULT SITE) (free AMATEUR-PICTURES) http://www.erocity.com (ADULT SITE) (FREE FETISH PICTURES) http://www.xxxzoo.com (ADULT SITE) (ONLY MEMBERS) http://www.centro-de-baleares.com (TOURIST SITE - MALLORCA) We thank you for your time, Yours Truly, Fantasy Dreams *** The Zenith Bulk Emailer - FREE - Get Your Copy Today *** *** For Your Free Copy Send An Email To freesoftware@answerme.com Or Freeware@force4.net *** From owner-freebsd-current Fri Oct 24 04:31:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA10176 for current-outgoing; Fri, 24 Oct 1997 04:31:40 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA10171; Fri, 24 Oct 1997 04:31:37 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie by salmon.maths.tcd.ie via local-salmon id aa02348; 24 Oct 97 12:31 +0100 To: Terry Lambert cc: KATO Takenori , current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Recursive mount [ was Re: -STABLE reboots ] In-reply-to: Your message of "Thu, 23 Oct 1997 18:22:29 -0000." <199710231822.LAA29050@usr02.primenet.com> Date: Fri, 24 Oct 1997 12:31:28 +0100 From: David Malone Message-ID: <9710241231.aa02348@salmon.maths.tcd.ie> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Makeing mount priveledged is a kludge. Indeed - though might it be useful for other reasons? (User NFS mounts a directory from their laptop, which they take home, leaving you unable to unmount that directory and all its ancestors? Unless forced umounting of NFS works in 3.0) > Is this a production environment patch? I've a dual processor machine with about 1000 undergrads with accounts on it, so its really a matter of time before someone discovers how to knock it over that way. > There's not really any > conceptual difference between root and non-root mounts, once the > greation of a mount struct instance is abstracted from it's mapping > into the FS hierarchy by moving the latter into common code. I take it that this would factor the recursive lock problem out of the VFS code into the generic mount code, and make it a bit more straight forward to fix? David. From owner-freebsd-current Fri Oct 24 10:27:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA05720 for current-outgoing; Fri, 24 Oct 1997 10:27:43 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA05708; Fri, 24 Oct 1997 10:27:38 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id KAA15493; Fri, 24 Oct 1997 10:27:31 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd015472; Fri Oct 24 10:27:27 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA13692; Fri, 24 Oct 1997 10:27:22 -0700 (MST) From: Terry Lambert Message-Id: <199710241727.KAA13692@usr08.primenet.com> Subject: Re: Recursive mount [ was Re: -STABLE reboots ] To: dwmalone@maths.tcd.ie (David Malone) Date: Fri, 24 Oct 1997 17:27:22 +0000 (GMT) Cc: tlambert@primenet.com, kato@migmatite.eps.nagoya-u.ac.jp, current@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <9710241231.aa02348@salmon.maths.tcd.ie> from "David Malone" at Oct 24, 97 12:31:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Is this a production environment patch? > > I've a dual processor machine with about 1000 undergrads with > accounts on it, so its really a matter of time before someone > discovers how to knock it over that way. Then I don't object. ;-). > > There's not really any > > conceptual difference between root and non-root mounts, once the > > greation of a mount struct instance is abstracted from it's mapping > > into the FS hierarchy by moving the latter into common code. > > I take it that this would factor the recursive lock problem out > of the VFS code into the generic mount code, and make it a bit > more straight forward to fix? Plus enable several nomadic computing features, plus make it possible to boot from any FS type. Etc. 8-). Actually, it should drop recursion out of the picture entirely. The only check you'd need to make is at the time you map the file into the directory hierarchy. And that's trivial because you know the device for the parentfs, the child fs, and the parent of the parent... up to the root. It's a straight linear traversal (not a bad thing, since mount is relatively rare, and the number of fs's is limited). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Oct 24 13:27:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA17597 for current-outgoing; Fri, 24 Oct 1997 13:27:52 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA17592 for ; Fri, 24 Oct 1997 13:27:45 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id WAA07919 for ; Fri, 24 Oct 1997 22:20:23 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id WAA01870 for current@FreeBSD.ORG; Fri, 24 Oct 1997 22:19:49 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id WAA00308; Fri, 24 Oct 1997 22:17:37 +0200 (CEST) (envelope-from roberto) Message-ID: <19971024221736.29056@keltia.freenix.fr> Date: Fri, 24 Oct 1997 22:17:36 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: nullfs & current References: <199710200143.UAA05747@dyson.iquest.net> <406.877333677@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <406.877333677@critter.freebsd.dk>; from Poul-Henning Kamp on Mon, Oct 20, 1997 at 09:47:57AM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Poul-Henning Kamp: > In FFS we only call vnode_pager_uncache in ffs_unmount()... Look inside vfs_syscalls.c... unlink(2) calls vnode_pager_uncache() _unconditionally_ on the vp it gets. In our case, and that why Tor's patch works, the nullvp. We need to propagate that to the lowervp too. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-current Sat Oct 25 07:57:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA06176 for current-outgoing; Sat, 25 Oct 1997 07:57:12 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA06168 for ; Sat, 25 Oct 1997 07:57:08 -0700 (PDT) (envelope-from wosch@cs.tu-berlin.de) Received: from panke.panke.de (anonymous214.ppp.cs.tu-berlin.de [130.149.17.214]) by mail.cs.tu-berlin.de (8.8.6/8.8.7) with ESMTP id QAA18660 for ; Sat, 25 Oct 1997 16:55:41 +0200 (MET DST) Received: (from wosch@localhost) by panke.panke.de (8.8.5/8.6.12) id PAA01669; Sat, 25 Oct 1997 15:11:02 +0200 (MET DST) Date: Sat, 25 Oct 1997 15:11:02 +0200 (MET DST) Message-Id: <199710251311.PAA01669@panke.panke.de> From: Wolfram Schneider To: current@freebsd.org Subject: src/share/doc/iso MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think we can remove this directory. It is out of date and if someone want read this files he can do it from the Attic directory. src/share/doc/iso/README The documentation contained here is horribly out of date and not to be trusted. However, it's probably better than nothing at all. -- Wolfram Schneider http://www.apfel.de/~wosch/ From owner-freebsd-current Sat Oct 25 17:42:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA02423 for current-outgoing; Sat, 25 Oct 1997 17:42:45 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from zippy.dyn.ml.org (garbanzo@seoul-234.ppp.hooked.net [206.169.228.234]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA02418 for ; Sat, 25 Oct 1997 17:42:42 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id RAA00277 for ; Sat, 25 Oct 1997 17:43:16 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 25 Oct 1997 17:43:10 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: current Subject: out of swap space causes hang Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I decided to edit a little xpm today with pixmap. As it was saving the pixmap, which apparently is a very memory & time consuming process, my computer decided to just completely hang, no panic no nothing. Since this is the second time this has happened to me today (totally different circumstances), I decided to check the logs. Right before the copytight message of my latest boot the last message that seemed strange was /kernel: swap_pager: out of space. Now I have 128Mb swap and 64Mb ram, and I'm running a make world a few weeks old and a kernel a few days old. Kinda annoying. Anyone else seeing this? - alex From owner-freebsd-current Sat Oct 25 18:00:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA03358 for current-outgoing; Sat, 25 Oct 1997 18:00:00 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03353 for ; Sat, 25 Oct 1997 17:59:58 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA19623; Sat, 25 Oct 1997 17:59:59 -0700 (PDT) To: Alex cc: current Subject: Re: out of swap space causes hang In-reply-to: Your message of "Sat, 25 Oct 1997 17:43:10 PDT." Date: Sat, 25 Oct 1997 17:59:59 -0700 Message-ID: <19620.877827599@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I decided to edit a little xpm today with pixmap. As it was saving the > pixmap, which apparently is a very memory & time consuming process, my > computer decided to just completely hang, no panic no nothing. Since this Are you sure it hung or did the X server just get shot down for eating too much memory? Since getting shot down leaves your screen and keyboard in a seriously hosed state, unless you can actually telnet in or ping the box externally, it looks just like a crash. Jordan From owner-freebsd-current Sat Oct 25 18:40:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA06957 for current-outgoing; Sat, 25 Oct 1997 18:40:13 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from zippy.dyn.ml.org (garbanzo@korea-130.ppp.hooked.net [206.169.225.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA06948 for ; Sat, 25 Oct 1997 18:40:09 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id SAA03152; Sat, 25 Oct 1997 18:40:31 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 25 Oct 1997 18:40:31 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: "Jordan K. Hubbard" cc: current Subject: Re: out of swap space causes hang In-Reply-To: <19620.877827599@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, Jordan K. Hubbard wrote: > > I decided to edit a little xpm today with pixmap. As it was saving the > > pixmap, which apparently is a very memory & time consuming process, my > > computer decided to just completely hang, no panic no nothing. Since this > > Are you sure it hung or did the X server just get shot down for eating > too much memory? Since getting shot down leaves your screen and > keyboard in a seriously hosed state, unless you can actually telnet > in or ping the box externally, it looks just like a crash. Keyboard didn't seem to respond. I got the X server to hang somewhere in the middle of the two crashes when I exited and the screen stayed with the gradient background, hitting alt-ctrl-del rebooted the computer cleanly that time (don't think that was caused by lack of swap space tho). The other two times it seemed to be completely hung. Guess it's time for me to setup a mini network to make extra sure it's not completely frozen. - alex From owner-freebsd-current Sat Oct 25 19:07:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08922 for current-outgoing; Sat, 25 Oct 1997 19:07:46 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08865 for ; Sat, 25 Oct 1997 19:06:58 -0700 (PDT) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id CAA09303; Sun, 26 Oct 1997 02:04:42 GMT Message-Id: <199710260204.CAA09303@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: Alex , current Subject: Re: out of swap space causes hang In-reply-to: Your message of "Sat, 25 Oct 1997 17:59:59 PDT." <19620.877827599@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Oct 1997 02:04:42 +0000 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I decided to edit a little xpm today with pixmap. As it was saving the > > pixmap, which apparently is a very memory & time consuming process, my > > computer decided to just completely hang, no panic no nothing. Since this > > Are you sure it hung or did the X server just get shot down for eating > too much memory? Since getting shot down leaves your screen and > keyboard in a seriously hosed state, unless you can actually telnet > in or ping the box externally, it looks just like a crash. This is annoying if you do actually crash. Is there any reason why ddb can't reset the screen & keyboard ? I suspect (although I know next to nothing abouth this) that putting the screen & keyboard into a know state is an ``art'' that depends on knowing what specific hardware is there :-( > Jordan -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Sat Oct 25 19:11:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09218 for current-outgoing; Sat, 25 Oct 1997 19:11:18 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09210 for ; Sat, 25 Oct 1997 19:11:04 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA20062; Sat, 25 Oct 1997 19:10:55 -0700 (PDT) To: Brian Somers cc: Alex , current Subject: Re: out of swap space causes hang In-reply-to: Your message of "Sun, 26 Oct 1997 02:04:42 -0000." <199710260204.CAA09303@awfulhak.demon.co.uk> Date: Sat, 25 Oct 1997 19:10:55 -0700 Message-ID: <20058.877831855@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This is annoying if you do actually crash. Is there any reason why > ddb can't reset the screen & keyboard ? I suspect (although I know > next to nothing abouth this) that putting the screen & keyboard into > a know state is an ``art'' that depends on knowing what specific > hardware is there :-( You got it. It's not easy at all (and was first discussed, oh, I'd say at least 3 years ago :). Jordan From owner-freebsd-current Sat Oct 25 19:23:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09956 for current-outgoing; Sat, 25 Oct 1997 19:23:09 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from zippy.dyn.ml.org (garbanzo@korea-130.ppp.hooked.net [206.169.225.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09939 for ; Sat, 25 Oct 1997 19:23:01 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id TAA03282; Sat, 25 Oct 1997 19:22:16 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 25 Oct 1997 19:22:13 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: Brian Somers cc: current Subject: Re: out of swap space causes hang In-Reply-To: <199710260204.CAA09303@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Oct 1997, Brian Somers wrote: > > Are you sure it hung or did the X server just get shot down for eating > > too much memory? Since getting shot down leaves your screen and > > keyboard in a seriously hosed state, unless you can actually telnet > > in or ping the box externally, it looks just like a crash. > > This is annoying if you do actually crash. Is there any reason why > ddb can't reset the screen & keyboard ? I suspect (although I know > next to nothing abouth this) that putting the screen & keyboard into > a know state is an ``art'' that depends on knowing what specific > hardware is there :-( DDB won't work if they keyboard's not responding, unless it works telepathically now. ;-) - alex From owner-freebsd-current Sat Oct 25 20:54:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA15203 for current-outgoing; Sat, 25 Oct 1997 20:54:13 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from hwcn.org (main.hwcn.org [199.212.94.65]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA15198 for ; Sat, 25 Oct 1997 20:54:10 -0700 (PDT) (envelope-from hoek@hwcn.org) Received: from james.freenet.hamilton.on.ca (ac199@james.hwcn.org [199.212.94.66]) by hwcn.org (8.8.7/8.8.7) with ESMTP id XAA05216; Sat, 25 Oct 1997 23:54:49 -0400 (EDT) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.8.7/8.8.7) with SMTP id XAA01395; Sat, 25 Oct 1997 23:55:12 -0400 (EDT) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Sat, 25 Oct 1997 23:55:12 -0400 (EDT) From: Tim Vanderhoek X-Sender: ac199@james.freenet.hamilton.on.ca To: "Jordan K. Hubbard" cc: Alex , current Subject: Re: out of swap space causes hang In-Reply-To: <19620.877827599@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, Jordan K. Hubbard wrote: > Are you sure it hung or did the X server just get shot down for eating > too much memory? Since getting shot down leaves your screen and > keyboard in a seriously hosed state, unless you can actually telnet > in or ping the box externally, it looks just like a crash. Shouldn't the fact that something (ie. the X server in this case) got shot down be recorded in some log, somewhere? That would make it easy to distinguish a crash from a killed X server on the reboot, at least... -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk