From owner-freebsd-current Sun Aug 25 00:13:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA16385 for current-outgoing; Sun, 25 Aug 1996 00:13:11 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA16380 for ; Sun, 25 Aug 1996 00:13:08 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id AAA15708; Sun, 25 Aug 1996 00:13:12 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id AAA07341; Sun, 25 Aug 1996 00:12:51 -0700 (PDT) Message-Id: <199608250712.AAA07341@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Warner Losh cc: current@freebsd.org Subject: Re: Speedingup the "worldstone" In-reply-to: Your message of Sat, 24 Aug 96 11:48:45 -0600. <199608241748.LAA02804@rover.village.org> Date: Sun, 25 Aug 1996 00:12:49 -0700 From: "Michael L. VanLoon" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >have an old 486 DX2-66 that I'd like to get the most out of when it >comes to building the world, since it takes just about exactly 9 hours [scsi drives...] [32MB...] >Does anybody have a list of the typical bottle necks in this process? >I know I can solve this problem by getting a good P6/200 with 64M of >memory and a good Adaptech Ultra Wide PCI card and a fast wide scsi >disk. But I don't have the $7500 (or even $5000) to do that just now Actually, "there's just no substitute for cubic inches". :-) Or in our case, MIPS. You can only squeeze so much out of 486 technology. I have an AMD 5x86 133MHz (really a 486 with a 16KB cache), plugged into an EISA motherboard with a 512KB write-back L2 cache, a BusLogic BT747s EISA SCSI controller, /usr (including /usr/src) on ccd over two drives, /usr/obj on a third separate drive from those, swap spread out over all three, and 24MB of RAM. It still takes me 6.5-7 hours to do a complete clean make world on NetBSD. I just threw NetBSD on my P5 120MHz. It's an Asus P55TP4N (Triton I), 512K PB cache, 32MB EDO RAM, using either a BusLogic BT956c or an Adaptec 2940UW (I was benchmarking -- tried both), one Seagate 2GB Barracuda (no ccd, no distributed swap or obj dirs). I consistently got 3:10 to 3:15 with this setup. Full kernel build, including make clean, config, and make depend in about 15 minutes (I have a *lot* of crap in my kernel). Pentium motherboards are becoming very cheap. I'll bet you could get a P100 for "pocket change". A P133 would be a fairly small investment. You should be able to get into one of these with an NCR PCI SCSI controller for well under $500. You should also seriously consider a Cyrix 6x86 if you want to wring the most performance out of one of these boards for the lowest price. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Sun Aug 25 00:30:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA17093 for current-outgoing; Sun, 25 Aug 1996 00:30:55 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA17065; Sun, 25 Aug 1996 00:30:36 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id AAA15845; Sun, 25 Aug 1996 00:30:42 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id AAA07494; Sun, 25 Aug 1996 00:30:21 -0700 (PDT) Message-Id: <199608250730.AAA07494@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: sysseh@devetir.qld.gov.au (Stephen Hocking) cc: freebsd-fs@freebsd.org, current@freebsd.org Subject: Re: The VIVA file system (fwd) In-reply-to: Your message of Sun, 25 Aug 96 03:35:19 +0000. <199608250335.DAA21536@netfl15a.devetir.qld.gov.au> Date: Sun, 25 Aug 1996 00:30:20 -0700 From: "Michael L. VanLoon" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Anybody have opinions on this vs LFS? Are we still waiting for the Lite-2 >stuff, before LFS can go in? The fact that they claim extraordinary performance for a filesystem that sounds like it's only about a third implemented? ;-) Remember the last 10% and 90% of the time/effort... [...] >indirect blocks. Benchmark results of our implementation of VIVA in the >Linux kernel show that it is much faster than Ext2, the default Linux >filesystem, for common file operations. >The Linux implementation of VIVA is a "work in progress". It does not >yet handle partitions larger than 64M (so that the allocation bitmap >fits readily in memory). Individual files are limited to about 8M >(inodes currently have only a single indirect block). There are no >fragments; block size is restricted to 1K. (Adding logical blocks of >larger size will relieve some of these limitations.) So, what is it good for besides development and benchmarks? :-) I'll be more impressed when I see the finished product benchmarked against something else. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Sun Aug 25 13:20:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA01627 for current-outgoing; Sun, 25 Aug 1996 13:20:10 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA01609 for ; Sun, 25 Aug 1996 13:20:07 -0700 (PDT) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id LAA25801 for ; Sun, 25 Aug 1996 11:56:29 -0700 (PDT) Received: (from news@localhost) by haywire.DIALix.COM (8.7.5/8.7.3) id CAA00848 for freebsd-current@freebsd.org; Mon, 26 Aug 1996 02:54:54 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@FreeBSD.ORG Date: Sun, 25 Aug 1996 16:43:14 GMT From: mark@putte.seeware.DIALix.oz.au (Mark Hannon) Message-ID: Organization: Private FreeBSD site Subject: 960801 install comments Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Have just installed 2.2-960801 and have basically only nice things to say about it. The system seems stable and after recompiling top and xperfmon everything seems to be working correctly. I have two small nits to pick with the installation- (1) My first attempt to upgrade from a partition which was (accidently) not mounted gave me an error message that bin, man, proflibs etc were not found. Upon pressing enter the installation proceeded to work on my /etc and /dev directories even though it hadn't actually extracted anything. Maybe there should be some other default behaviour in this case? (2) /etc/dumpdates is cleared with the new installation. Why?? Regards & looking forward to the full 2.2 release! Mark -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Mark Hannon,| FreeBSD - Free Unix for your PC| mark@seeware.DIALix.oz.au| | Melbourne, | PGP key available by fingering | epamha@epa.ericsson.se | | Australia | seeware@melbourne.DIALix.oz.au | | +-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From owner-freebsd-current Sun Aug 25 13:26:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02827 for current-outgoing; Sun, 25 Aug 1996 13:26:56 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA02766 for ; Sun, 25 Aug 1996 13:26:46 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id GAA24889 for ; Sun, 25 Aug 1996 06:57:14 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA11611 for ; Sun, 25 Aug 1996 11:51:42 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA11798 for freebsd-current@FreeBSD.org; Sun, 25 Aug 1996 11:51:41 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id LAA15473 for freebsd-current@FreeBSD.org; Sun, 25 Aug 1996 11:35:46 +0200 (MET DST) From: J Wunsch Message-Id: <199608250935.LAA15473@uriah.heep.sax.de> Subject: Re: Help on block size in tar To: freebsd-current@FreeBSD.ORG (FreeBSD-current users) Date: Sun, 25 Aug 1996 11:35:46 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199608241406.KAA03455@james.freenet.hamilton.on.ca> from "hoek@freenet.hamilton.on.ca" at "Aug 24, 96 10:06:40 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As hoek@freenet.hamilton.on.ca wrote: > > Anyway, i think the default blocksize is only 512 bytes. This should > > also pass any variable-length driver. > > Are you sure? I quote the tar manpage (which, being GNU tar isn't the > official source of information regarding tar, I suppose). > > "and 20 is the default block size" You're right, gtar also defaults to 10 KB blocks when used on a local tape, i just verified. However, i seem to remember that adding a ``-B 20'' gave me a substantial speed improvement when using it on a remote tape (``-f host:/dev/rtape''). -- 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 Aug 25 13:31:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA03984 for current-outgoing; Sun, 25 Aug 1996 13:31:01 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA03936 for ; Sun, 25 Aug 1996 13:30:52 -0700 (PDT) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id DAA24237 for ; Sun, 25 Aug 1996 03:53:31 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by mail.barrnet.net (8.7.5/MAIL-RELAY-LEN) with SMTP id DAA09422 for ; Sun, 25 Aug 1996 03:52:09 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id MAA09535 for ; Sun, 25 Aug 1996 12:36:36 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id MAA20439 for freebsd-current@freefall.cdrom.com; Sun, 25 Aug 1996 12:49:23 +0200 Date: Sun, 25 Aug 1996 12:49:23 +0200 From: Christoph Kukulies Message-Id: <199608251049.MAA20439@gilberto.physik.rwth-aachen.de> To: freebsd-current@freefall.freebsd.org Subject: dead code in /sys/i386/isa/clock.c (glitch) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk /sys/i386/isa/clock.c defines DDB_prtintrtc when DDB is defined but never uses it. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Sun Aug 25 13:46:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA05816 for current-outgoing; Sun, 25 Aug 1996 13:46:37 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA05808; Sun, 25 Aug 1996 13:46:33 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA21331; Sun, 25 Aug 1996 13:36:27 -0700 From: Terry Lambert Message-Id: <199608252036.NAA21331@phaeton.artisoft.com> Subject: Re: The VIVA file system (fwd) To: dyson@FreeBSD.org Date: Sun, 25 Aug 1996 13:36:26 -0700 (MST) Cc: sysseh@devetir.qld.gov.au, freebsd-fs@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199608250445.XAA05829@dyson.iquest.net> from "John S. Dyson" at Aug 24, 96 11:45:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Anybody have opinions on this vs LFS? Are we still waiting for the Lite-2 > > stuff, before LFS can go in? > > Looks interesting, but LFS is also. Some of the improvements will appear > when we get our implementation of properly delayed writes working for > UFS. I am sure that someone will take-on LFS when Lite-2 stuff goes > in, even I might (shiver :-)). The VIVA stuff is, I think, overoptimistic. They have made a number of claims in the University of Kentucky papers that were published about two years ago that seem to rely on overly optimistic assumptions about policy and usage. They also seemed to pick "worst case" scenarios for comparison with FFS, and avoided FFS best case. This is not nearly as bad as the MACH MSDOSFS papers, which intentioanlly handicapped FFS through parameter setting and cache reduction, while caching the entire DOS FAT in core was seen as being acceptable, to compare their work to FFS. But it is certainly not entirely unbiased reporting. Several of their approaches will (if you have read the Herrin/Finkel paper in any depth) apply directly to FFS with little or no modification. The file delete benchmarks are especially telling; they are comparing directory entry manipulation policy, which has little to do with the ability of the file system to store files at all. The dog-legs in the creation result from similar effects. The read and rewrite differences are moslty attributable to policy issues in the use of FFS "optimizations" which are inapropriate to the hardware used. You can see from the block-sized based divergence in the single file case that the dog-legs one would expect when the use of indirect blocks comes into play are missing. This refutes their claim of where the actual wins are coming from. I would be interested to see how VIVA performs in the following: 1) Unified VM/buffer cache implementation 2) Fixed write clustering; the BSD algorith traditionally has had problems which remain unaddressed (except in prototype code from Matt Day, which has not been externally distributed at all) 3) FFS optimizations for head positioning turned off, and/or use of FFS optimizationss on older drive hardware, where the optimizations are not actually pessimizations Finally, I am interested in, but suspicious of, their compression claims, since they also claim that the FFS performance degradation, which Knuth clearly shows to be a hash effect to be expected after an 85% fill (in "Sorting and Searching"), to be nonexistant. INRE: "where the wins come from", the "Discussion" reverses the claims made earlier in the paper -- we see that the avoidance of indirect blocks is not the primary win (a conclusion we came to on our own from viewing the earlier graphs). We also see in "Discussion" that caching file beginnings/ends in the inode itself is not a win as they has hoped. In fact, compilation times are pessimized by 25% by it. The final interesting aspect of VIVA is their crash recovery. The same effect can be had, with more general applicability, by examining the FS in terms of graph theory, and establishing node-relationship handlers for soft updates: an obvious extention of the Ganger/Patt work on soft updates, which disconnects the soft update mechanism from the FS implementation (the one obvious drawback of the Ganger/Patt work is that it is inhernetly tied to FFS, and each FS fro which it is to be impelemented requires it's own individual modifications and implementation of timer service routines). If you are looking for something to do a Master's Thesis on, moving applicable VIVA FS techniques into FFS would be one thing to consider, since it would allow you to determine the origin of the effects that are noted in the paper with better accuracy. If you are looking for a porting project, you could do worse. If you are trying to "keep up with Linux", it's probably not worth the direct effort, at least until, as another poster noted, there is sufficient grounds for a side-by-side comparison with a well studied FS implementation. My opinions, 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 Sun Aug 25 14:22:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA09073 for current-outgoing; Sun, 25 Aug 1996 14:22:41 -0700 (PDT) Received: from prozac.neuron.net (prozac.neuron.net [165.254.1.213]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA09062 for ; Sun, 25 Aug 1996 14:22:28 -0700 (PDT) Received: (from amir@localhost) by prozac.neuron.net (8.7.5/8.6.12) id RAA01702; Sun, 25 Aug 1996 17:30:43 -0400 (EDT) From: "Amir Y. Rosenblatt" Message-Id: <199608252130.RAA01702@prozac.neuron.net> Subject: Re: -current kills harddrives In-Reply-To: <199608240641.IAA08952@uriah.heep.sax.de> from J Wunsch at "Aug 24, 96 08:41:51 am" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 25 Aug 1996 17:30:43 -0400 (EDT) Cc: freebsd-current@freebsd.org, nirva@ishiboo.com X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > no, but it could push it over the edge if cooling is not sufficient.. > > Btw., if i read the mail correctly, the drives are not going entirely > dead. It's just that they decouple from the SCSI bus, so perhaps they > are simply reacting to a detected overheating condition. As it happens, the drive of mine that I mentioned (this is now the second boot disk I've had on this machine) bit it last night. Started getting messages like: sd0(ahc0:0:0): timed out in datain phase fatal process exception; page fault, fault V=0x18920 and a slew of the usual SCSI warnings (see the earlier posts for specifics -- I'd put some in but the thing was so hosed that it couldn;t even log the errors). I could hear the disk making little clicking noises (the kind it makes when you power it up) and spinnign down and then back up over and over. I brought tha machine down, took off the face plates and let it cool off for an hour (the room it's in has a/c). Once ves were cool to the touch I tried to bring it back up again, but alas, no dice. I spent a solid 2 more hours at iut before giving up. Tried one more time this morning but to no avail and just spent the day swapping in a new disk (lucky I have a spare). That'll make 2 'cudas dead in about 3-4 weeks. I am: displeased. Any suggestions (includsing recommendations for appropriate external enclosures that'll keep these suckers cool -- I still have a 3rd disk I want to add in to the system). -Amir From owner-freebsd-current Sun Aug 25 15:00:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA11807 for current-outgoing; Sun, 25 Aug 1996 15:00:29 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA11799 for ; Sun, 25 Aug 1996 15:00:27 -0700 (PDT) From: sthaug@nethelp.no Received: from verdi.nethelp.no (verdi.nethelp.no [193.91.212.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id PAA26238 for ; Sun, 25 Aug 1996 15:00:24 -0700 (PDT) Received: (qmail-queue invoked from smtpd); 25 Aug 1996 21:58:42 +0000 (GMT) Received: from localhost (HELO verdi.nethelp.no) (@127.0.0.1) by localhost with SMTP; 25 Aug 1996 21:58:42 +0000 (GMT) To: amir@neuron.net Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@freebsd.org, nirva@ishiboo.com Subject: Re: -current kills harddrives In-Reply-To: Your message of "Sun, 25 Aug 1996 17:30:43 -0400 (EDT)" References: <199608252130.RAA01702@prozac.neuron.net> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 25 Aug 1996 23:58:42 +0200 Message-ID: <25899.841010322@verdi.nethelp.no> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Any suggestions (includsing recommendations for > appropriate external enclosures that'll keep these suckers cool -- I still > have a 3rd disk I want to add in to the system). I'd recommend the TRIMM Trinketbox for the Barracudas. It has a 50W power supply, and a better than normal fan. I have one of these myself, and the air coming out of the cabinet by the fan is just mildly warmer than the surroundings. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current Sun Aug 25 15:33:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA15754 for current-outgoing; Sun, 25 Aug 1996 15:33:27 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA15733 for ; Sun, 25 Aug 1996 15:33:22 -0700 (PDT) Received: from skipper.eng.umd.edu (skipper.eng.umd.edu [129.2.103.24]) by po1.glue.umd.edu (8.8.Alpha.8/8.8.Alpha.8) with ESMTP id SAA19554; Sun, 25 Aug 1996 18:33:18 -0400 (EDT) Received: from localhost (chuckr@localhost) by skipper.eng.umd.edu (8.7.5/8.7.3) with SMTP id SAA31070; Sun, 25 Aug 1996 18:33:18 -0400 (EDT) X-Authentication-Warning: skipper.eng.umd.edu: chuckr owned process doing -bs Date: Sun, 25 Aug 1996 18:33:17 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@skipper.eng.umd.edu To: Thomas Sparrevohn cc: freebsd-current@freebsd.org Subject: Re: My Gumby 82439HX diffs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 18 Aug 1996, Thomas Sparrevohn wrote: > > > Thanks to everybody that responded. But I must have hit my head with a > brick and the M_EN's was wrong. Please try this patch it contains the > registerdump for the 82439HX and the 82371SB. The only real difference > between the 82371SB and the 82371FB that concerns the registers dumped > is the APIC select field. I saw some requests for this patch again, so I'm reposting it with my comments. If you reboot normally, there is no change, but if you reboot -v, well here is what I got (and I'm very pleased with): exiting on signal 15 R# Output Type: Open drain output, Global TXC disabled Cache: 512K pipelined-burst, NA Disable: disabled, Extended Cacheability disabled, SCFMI disabled, L1 enabled Speculative Leadoff enabled, Turn-around Insertion enabled, Memory Address Drive Strength: 12mA/12mA, 64 Mbit mode disabled Hole: None, EDO Detect mode disabled, DRAM Refrest Rate 66Mhz Turbo Read Leadoff disabled, DRAM Read Burst Timing: x-2-2-2/x-3-3-3, DRAM Write Burst Timing: x-2-2-2, Fast RAS to CAS Delay: 2 clocks, DRAM leadoff Timing: Read 6, Write 5, Precharge 3, Refresh 4 chip1 rev 0 on pci0:7:0 DMA Reserved Page Register Aliasing disabled 8-Bit I/O Recovery: enabled I/O Recovery Timing: 8-bit 1 clocks, 16-bit 1 clocks APIC Chip Select: enabled Extended BIOS: enabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled BIOSCS# Write Protect: disabled Keyboard Controller Address Location: enabled RTC Address Location: enabled Interrupt Routing: A: IRQ10, B: IRQ11, C: disabled, D: disabled MB0: disabled, MB1: I'm not competent in this area of code, so I can't commit it, but I hope someone else does. > > This is the new patch. > > Regards > Thomas > > *** pcisupport.c#ctm Thu Aug 15 21:42:23 1996 > --- pcisupport.c Sun Aug 18 00:32:12 1996 > *************** > *** 131,136 **** > --- 131,140 ---- > return ("Intel 82437 (Triton) PCI cache memory controller"); > case 0x122e8086: > return ("Intel 82371 (Triton) PCI-ISA bridge"); > + case 0x12508086: > + return ("Intel 82439HX (Triton II) PCI cache memory controller"); > + case 0x70008086: > + return ("Intel 82371SB (Triton II) PCI-ISA bridge"); > case 0x04961039: > return ("SiS 85c496"); > case 0x04061039: > *************** > *** 463,468 **** > --- 467,562 ---- > { 0 } > }; > > + static const struct condmsg conf82439hx[] = > + { > + /* PCON -- PCI Control Register */ > + { 0x00, 0x00, 0x00, M_TR, "\tDRAM ECC/Parity:" }, > + { 0x50, 0x80, 0x80, M_EQ, " ECC" }, > + { 0x50, 0x80, 0x00, M_EQ, " Parity" }, > + { 0x00, 0x00, 0x00, M_TR, ", ECC Test " }, > + { 0x50, 0x40, 0x40, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tShutdown to Port 92 " }, > + { 0x50, 0x20, 0x20, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ", Dual Processor NA# " }, > + { 0x50, 0x10, 0x10, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tPeer Concurrency " }, > + { 0x50, 0x08, 0x08, M_EN, 0 }, > + /* XXX I am not sure thats the SERR# output type is usefull */ > + { 0x00, 0x00, 0x00, M_TR, ", SERR# Output Type:" }, > + { 0x50, 0x04, 0x04, M_EQ, " Normal output" }, > + { 0x50, 0x04, 0x00, M_EQ, " Open drain output" }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tGlobal TXC " }, > + { 0x50, 0x01, 0x01, M_EN, 0 }, > + > + /* CC -- Cache Control Regsiter */ > + { 0x00, 0x00, 0x00, M_TR, "\n\tCache:" }, > + { 0x52, 0xc0, 0x80, M_EQ, " 512K" }, > + { 0x52, 0xc0, 0x40, M_EQ, " 256K" }, > + { 0x52, 0xc0, 0x00, M_EQ, " NO" }, > + { 0x52, 0x30, 0x00, M_EQ, " pipelined-burst" }, > + { 0x52, 0x30, 0x10, M_EQ, " reserved" }, > + { 0x52, 0x30, 0x20, M_EQ, " reserved" }, > + { 0x52, 0x30, 0x30, M_EQ, " dual-bank pipelined-burst" }, > + { 0x00, 0x00, 0x00, M_TR, ", NA Disable: " }, > + { 0x52, 0x04, 0x04, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tExtended Cacheability " }, > + { 0x52, 0x04, 0x04, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ", SCFMI "}, > + { 0x52, 0x02, 0x02, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ", L1 " }, > + { 0x52, 0x01, 0x01, M_EN, 0 }, > + > + /* DRAMEC -- DRAM Extended Control Register */ > + { 0x00, 0x00, 0x00, M_TR, "\n\tSpeculative Leadoff " }, > + { 0x56, 0x10, 0x10, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ", Turn-around Insertion " }, > + { 0x56, 0x08, 0x08, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tMemory Address Drive Strength: " }, > + { 0x56, 0x06, 0x00, M_EQ, "8mA/8mA" }, > + { 0x56, 0x06, 0x02, M_EQ, "8mA/12mA" }, > + { 0x56, 0x06, 0x04, M_EQ, "12mA/8mA" }, > + { 0x56, 0x06, 0x06, M_EQ, "12mA/12mA" }, > + { 0x00, 0x00, 0x00, M_TR, ", 64 Mbit mode " }, > + { 0x56, 0x01, 0x01, M_EN, 0 }, > + > + /* DRAMC - DRAM Control Register */ > + { 0x00, 0x00, 0x00, M_TR, "\n\tHole: " }, > + { 0x57, 0xc0, 0x00, M_EQ, "None" }, > + { 0x57, 0xc0, 0x40, M_EQ, "512KB - 640KB" }, > + { 0x00, 0x00, 0x00, M_TR, ", EDO Detect mode " }, > + { 0x57, 0x04, 0x04, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tDRAM Refrest Rate " }, > + { 0x57, 0x07, 0x00, M_EQ, "Disabled" }, > + { 0x57, 0x07, 0x01, M_EQ, "50Mhz" }, > + { 0x57, 0x07, 0x02, M_EQ, "60Mhz" }, > + { 0x57, 0x07, 0x03, M_EQ, "66Mhz" }, > + > + /* DRAMT -- DRAM Timing Register */ > + { 0x00, 0x00, 0x00, M_TR, "\n\tTurbo Read Leadoff " }, > + { 0x58, 0x80, 0x80, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tDRAM Read Burst Timing: " }, > + { 0x58, 0x60, 0x00, M_EQ, "x-4-4-4/x-4-4-4" }, > + { 0x58, 0x60, 0x20, M_EQ, "x-3-3-3/x-4-4-4" }, > + { 0x58, 0x60, 0x40, M_EQ, "x-2-2-2/x-3-3-3" }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tDRAM Write Burst Timing: " }, > + { 0x58, 0x18, 0x00, M_EQ, "x-4-4-4" }, > + { 0x58, 0x18, 0x08, M_EQ, "x-3-3-3" }, > + { 0x58, 0x18, 0x10, M_EQ, "x-2-2-2" }, > + { 0x00, 0x00, 0x00, M_TR, ",\n\tFast RAS to CAS Delay: " }, > + { 0x58, 0x04, 0x00, M_EQ, "3" }, > + { 0x58, 0x04, 0x04, M_EQ, "2" }, > + { 0x00, 0x00, 0x00, M_TR, " clocks,\n\tDRAM leadoff Timing: " }, > + { 0x58, 0x03, 0x00, M_EQ, "Read 7, Write 6, Precharge 3, Refresh 4" }, > + { 0x58, 0x03, 0x01, M_EQ, "Read 6, Write 5, Precharge 3, Refresh 4" }, > + { 0x58, 0x03, 0x02, M_EQ, "Read 7, Write 6, Precharge 4, Refresh 5" }, > + { 0x58, 0x03, 0x03, M_EQ, "Read 6, Write 5, Precharge 4, Refresh 5" }, > + { 0x00, 0x00, 0x00, M_TR, "\n" }, > + > + /* end marker */ > + { 0 } > + > + }; > + > static const struct condmsg conf82371fb[] = > { > /* IORT -- ISA I/O Recovery Timer Register */ > *************** > *** 528,533 **** > --- 622,707 ---- > { 0 } > }; > > + /* The 82371fb and the 82371sb are allmost identical in > + function 0, but a few registers values are different */ > + > + static const struct condmsg conf82371sb[] = > + { > + /* IORT -- ISA I/O Recovery Timer Register */ > + { 0x00, 0x00, 0x00, M_TR, "\tDMA Reserved Page Register Aliasing " }, > + { 0x4c, 0x80, 0x80, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\t8-Bit I/O Recovery: " }, > + { 0x4c, 0x40, 0x40, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\tI/O Recovery Timing: 8-bit " }, > + { 0x4c, 0x40, 0x00, M_EQ, "3.5" }, > + { 0x4c, 0x78, 0x48, M_EQ, "1" }, > + { 0x4c, 0x78, 0x50, M_EQ, "2" }, > + { 0x4c, 0x78, 0x58, M_EQ, "3" }, > + { 0x4c, 0x78, 0x60, M_EQ, "4" }, > + { 0x4c, 0x78, 0x68, M_EQ, "5" }, > + { 0x4c, 0x78, 0x70, M_EQ, "6" }, > + { 0x4c, 0x78, 0x78, M_EQ, "7" }, > + { 0x4c, 0x78, 0x40, M_EQ, "8" }, > + { 0x00, 0x00, 0x00, M_TR, " clocks, 16-bit " }, > + { 0x4c, 0x04, 0x00, M_EQ, "3.5" }, > + { 0x4c, 0x07, 0x05, M_EQ, "1" }, > + { 0x4c, 0x07, 0x06, M_EQ, "2" }, > + { 0x4c, 0x07, 0x07, M_EQ, "3" }, > + { 0x4c, 0x07, 0x04, M_EQ, "4" }, > + { 0x00, 0x00, 0x00, M_TR, " clocks\n" }, > + > + /* XBCS -- X-Bus Chip Select Register 4e-4f in PIIX3 */ > + { 0x00, 0x00, 0x00, M_TR, "\tAPIC Chip Select: " }, > + { 0x4f, 0x01, 0x01, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\tExtended BIOS: " }, > + { 0x4e, 0x80, 0x80, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\tLower BIOS: " }, > + { 0x4e, 0x40, 0x40, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\tCoprocessor IRQ13: " }, > + { 0x4e, 0x20, 0x20, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\tMouse IRQ12: " }, > + { 0x4e, 0x10, 0x10, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\tBIOSCS# Write Protect: " }, > + { 0x4e, 0x04, 0x04, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\tKeyboard Controller Address Location: " }, > + { 0x4e, 0x02, 0x02, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n\tRTC Address Location: " }, > + { 0x4e, 0x01, 0x01, M_EN, 0 }, > + { 0x00, 0x00, 0x00, M_TR, "\n" }, > + > + { 0x00, 0x00, 0x00, M_TR, "\tInterrupt Routing: " }, > + #define PIRQ(x, n) \ > + { 0x00, 0x00, 0x00, M_TR, n ": " }, \ > + { x, 0x80, 0x80, M_EQ, "disabled" }, \ > + { x, 0xc0, 0x40, M_EQ, "[shared] " }, \ > + { x, 0x8f, 0x03, M_EQ, "IRQ3" }, \ > + { x, 0x8f, 0x04, M_EQ, "IRQ4" }, \ > + { x, 0x8f, 0x05, M_EQ, "IRQ5" }, \ > + { x, 0x8f, 0x06, M_EQ, "IRQ6" }, \ > + { x, 0x8f, 0x07, M_EQ, "IRQ7" }, \ > + { x, 0x8f, 0x09, M_EQ, "IRQ9" }, \ > + { x, 0x8f, 0x0a, M_EQ, "IRQ10" }, \ > + { x, 0x8f, 0x0b, M_EQ, "IRQ11" }, \ > + { x, 0x8f, 0x0c, M_EQ, "IRQ12" }, \ > + { x, 0x8f, 0x0e, M_EQ, "IRQ14" }, \ > + { x, 0x8f, 0x0f, M_EQ, "IRQ15" } > + > + /* Interrupt routing */ > + PIRQ(0x60, "A"), > + PIRQ(0x61, ", B"), > + PIRQ(0x62, ", C"), > + PIRQ(0x63, ", D"), > + PIRQ(0x70, "\n\t\tMB0"), > + PIRQ(0x71, ", MB1"), > + > + { 0x00, 0x00, 0x00, M_TR, "\n" }, > + > + #undef PIRQ > + > + /* XXX - do DMA routing, too? */ > + { 0 } > + }; > + > #if 0 /* xxx not used */ > static const struct condmsg conf82371fb2[] = > { > *************** > *** 615,620 **** > --- 789,800 ---- > break; > case 0x122e8086: > writeconfig (config_id, conf82371fb); > + break; > + case 0x12508086: > + writeconfig (config_id, conf82439hx); > + break; > + case 0x70008086: > + writeconfig (config_id, conf82371sb); > break; > #if 0 > case 0x00011011: /* DEC 21050 */ > > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Sun Aug 25 17:49:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA01644 for current-outgoing; Sun, 25 Aug 1996 17:49:20 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA01637 for ; Sun, 25 Aug 1996 17:49:17 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA07185; Mon, 26 Aug 1996 00:49:09 GMT Date: Mon, 26 Aug 1996 09:49:09 +0900 (JST) From: Michael Hancock To: Warner Losh cc: current@freebsd.org Subject: Re: Speedingup the "worldstone" In-Reply-To: <199608241748.LAA02804@rover.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 24 Aug 1996, Warner Losh wrote: > Does anybody have a list of the typical bottle necks in this process? > > I know I can solve this problem by getting a good P6/200 with 64M of > memory and a good Adaptech Ultra Wide PCI card and a fast wide scsi > disk. But I don't have the $7500 (or even $5000) to do that just now > :-). I think you've already done things nicely by spreading out the disk i/o, compiles are also CPU intensive so the x486 looks like your bottle neck. I'm skepical that you can really get the disks singing in harmony to take advantage of Ultra Wide. Though it's generally a good thing to have advances in bus architectures so that it puts pressure on the peripherals to catch up. Regards, Mike Hancock From owner-freebsd-current Sun Aug 25 18:26:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05184 for current-outgoing; Sun, 25 Aug 1996 18:26:09 -0700 (PDT) Received: (from grog@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05174; Sun, 25 Aug 1996 18:26:07 -0700 (PDT) From: Greg Lehey Message-Id: <199608260126.SAA05174@freefall.freebsd.org> Subject: Re: Help on block size in tar To: hoek@freenet.hamilton.on.ca Date: Sun, 25 Aug 1996 18:26:07 -0700 (PDT) Cc: freebsd-current@FreeBSD.org (FreeBSD-current users) In-Reply-To: <199608241406.KAA03455@james.freenet.hamilton.on.ca> from "hoek@freenet.hamilton.on.ca" at Aug 24, 96 10:06:40 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > In Email, J Wunsch wrote: > > > > What is the default blocksize of tar on FreeBSD, I have made a tape > > > > on a freebsd system and now cannot read it on a linux system. > > > > > it may be more complicated... > > > it might be teh TAPE DRIVE complaining... > > > > Anyway, i think the default blocksize is only 512 bytes. This should > > also pass any variable-length driver. > > Are you sure? I quote the tar manpage (which, being GNU tar isn't the > official source of information regarding tar, I suppose). > > "and 20 is the default block size" > > And each of these blocks are then 512 bytes, I believe. This is the traditonal tar format, at least as far back as the Sixth Edition. It's certainly true for the version of GNU tar I'm using, but that isn't the released version. I'd expect it to be true both for the -release version of tar, and also for Linux tar. > Or the manpage is just confusing the heck out of me. About the only thing it could be doing is lying. But I don't believe that. To the original poster: I think you're probably looking in the wrong place. Since Linux also uses GNU tar, you could try $ tar tvb 1 or $ tar tvb 20 and see if that helps. BTW: for helical scan tapes, you should use large block sizes, typically 64 or 128 blocks (use the b option for this, as well). Be warned, however, that some brain-dead System V tars can't read more than 62 (yup, 62) blocks. If you find you need to read big blocks on these bmachnes, dd might help you. From owner-freebsd-current Sun Aug 25 18:44:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA07032 for current-outgoing; Sun, 25 Aug 1996 18:44:16 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA07025 for ; Sun, 25 Aug 1996 18:44:14 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id SAA27499; Sun, 25 Aug 1996 18:44:13 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id SAA12137; Sun, 25 Aug 1996 18:43:54 -0700 (PDT) Message-Id: <199608260143.SAA12137@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Michael Hancock cc: Warner Losh , current@freebsd.org Subject: Re: Speedingup the "worldstone" In-reply-to: Your message of Mon, 26 Aug 96 09:49:09 +0900. Date: Sun, 25 Aug 1996 18:43:53 -0700 From: "Michael L. VanLoon" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I think you've already done things nicely by spreading out the disk i/o, >compiles are also CPU intensive so the x486 looks like your bottle neck. >I'm skepical that you can really get the disks singing in harmony to take >advantage of Ultra Wide. Though it's generally a good thing to have >advances in bus architectures so that it puts pressure on the peripherals >to catch up. I can tell you, for a fact, that you won't get Ultra Wide bandwidth out of a 486 on real filesystem data. The 486 design just doesn't have enough power. The best you'll probably do, on real-world use, is maxing out fast SCSI (10MB/s), and then only if you tune well. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Sun Aug 25 18:49:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA07371 for current-outgoing; Sun, 25 Aug 1996 18:49:16 -0700 (PDT) Received: from UKCC.uky.edu (ukcc.uky.edu [128.163.1.170]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA07351; Sun, 25 Aug 1996 18:49:12 -0700 (PDT) Received: from t2.mscf.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R3) with TCP; Sun, 25 Aug 96 21:47:03 EDT Received: from t1.mscf.uky.edu by t2.ms.uky.edu id aa12275; 25 Aug 96 21:45 EDT From: eric@ms.uky.edu Subject: Re: The VIVA file system (fwd) To: Terry Lambert Date: Sun, 25 Aug 1996 21:45:16 -0400 (EDT) Cc: freebsd-fs@freebsd.org, current@freebsd.org In-Reply-To: <199608252036.NAA21331@phaeton.artisoft.com> from "Terry Lambert" at Aug 25, 96 01:36:26 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <9608252145.aa12275@t2.t2.mscf.uky.edu> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I guess I should respond to this thread since I happen to be on all these nice FreeBSD mailing lists nowadays. The Linux version was done by one of Raphael's Master's students. It isn't complete, but it does apparently work (I personally have not seen it nor have I seen the performance figures). As a side note, I am currently working on Viva2, which should be a much more interesting gadget. Anyway, it is in active development again and FreeBSD is the platform this time. > > > Anybody have opinions on this vs LFS? Are we still waiting for the Lite-2 > > > stuff, before LFS can go in? > > > > Looks interesting, but LFS is also. Some of the improvements will appear > > when we get our implementation of properly delayed writes working for > > UFS. I am sure that someone will take-on LFS when Lite-2 stuff goes > > in, even I might (shiver :-)). > > The VIVA stuff is, I think, overoptimistic. > > They have made a number of claims in the University of Kentucky papers > that were published about two years ago that seem to rely on overly > optimistic assumptions about policy and usage. You might explain this one, I'm not sure I know what you mean. The paper was written over three years ago. The work was actually performed from late 1991-1992. The AT&T lawsuit came out, I became distracted with making a living, and haven't gotten back to it until a couple months ago. For all the discussion below, you must remember that the platforms for Viva were 1) AT&T SysV, and 2) BSDI's BSD/386. We abandoned SysV because I wanted to release the code, then came the AT&T lawsuit:-( > They also seemed to pick "worst case" scenarios for comparison with FFS, > and avoided FFS best case. We did our testing on clean, freshly newfs'd partitions for the graphs. I don't see how this is "worst case", but perhaps you mean the types of tests we ran. Obviously, we ran some tests that showed a difference between FFS and Viva. > This is not nearly as bad as the MACH MSDOSFS papers, which intentioanlly > handicapped FFS through parameter setting and cache reduction, while > caching the entire DOS FAT in core was seen as being acceptable, to > compare their work to FFS. > > But it is certainly not entirely unbiased reporting. I'm not sure how to react to this. Can one write an "entirely unbiased" report about one's own work? Personally, I don't think so. We tried. I'll leave it at that. <--stuff deleted> > The read and rewrite differences are moslty attributable to policy > issues in the use of FFS "optimizations" which are inapropriate to > the hardware used. The read and rewrite differences are due to the fact FFS didn't do clustering very well at all. BSDI *still* doesn't do it well, but FreeBSD appears to be much better at it. I'm still running tests though and probably will be running tests for some time yet. <--more stuff deleted> > Finally, I am interested in, but suspicious of, their compression > claims, since they also claim that the FFS performance degradation, > which Knuth clearly shows to be a hash effect to be expected after > an 85% fill (in "Sorting and Searching"), to be nonexistant. Well, the results are in the paper. This is what we saw, but you should look at the table carefully. There are places where the effective clustering of a particular file degrades over 50%, but that was (at the time) about as good as FFS ever did anyway. The mean effective clustering always remained very high (90%+). I should have some more modern numbers in a few months, Raphael's student probably has some for Linux now. I think he used the original algorithms. > INRE: "where the wins come from", the "Discussion" reverses the > claims made earlier in the paper -- we see that the avoidance of > indirect blocks is not the primary win (a conclusion we came to > on our own from viewing the earlier graphs). This is correct, the big performance wins came from: 1) Large block sizes and small frag sizes 2) Good clustering 3) Multiple read-ahead > We also see in "Discussion" that caching file beginnings/ends in the > inode itself is not a win as they has hoped. In fact, compilation > times are pessimized by 25% by it. Yes, we were disappointed by that, but it just confirmed what others (Tanenbaum for example) had seen earlier. You should remember that one reason for the degradation was that it threw off all the code that tries to read things in FS block-sized chunks. We wanted to be able to read headers in files quickly and it *does* do that well. We just thought it would be nice to provide that capability (some people have entire file systems dedicated to particular tasks). Some space in the inode can be used for lots of things, perhaps it would be most useful at user level and disjoint from the bytes in the file. Eric From owner-freebsd-current Sun Aug 25 20:23:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13701 for current-outgoing; Sun, 25 Aug 1996 20:23:24 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA13695 for ; Sun, 25 Aug 1996 20:23:13 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA26405; Mon, 26 Aug 1996 13:18:51 +1000 Date: Mon, 26 Aug 1996 13:18:51 +1000 From: Bruce Evans Message-Id: <199608260318.NAA26405@godzilla.zeta.org.au> To: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: dead code in /sys/i386/isa/clock.c (glitch) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >/sys/i386/isa/clock.c defines DDB_prtintrtc when DDB is defined >but never uses it. It's for calling from the ddb prompt (call DDB_printrtc). Bruce From owner-freebsd-current Sun Aug 25 23:09:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA20197 for current-outgoing; Sun, 25 Aug 1996 23:09:59 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA20186 for ; Sun, 25 Aug 1996 23:09:55 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA18275; Sun, 25 Aug 1996 23:08:11 -0700 From: "Rodney W. Grimes" Message-Id: <199608260608.XAA18275@GndRsh.aac.dev.com> Subject: Re: Speedingup the "worldstone" To: michaelv@MindBender.serv.net (Michael L. VanLoon) Date: Sun, 25 Aug 1996 23:08:11 -0700 (PDT) Cc: michaelh@cet.co.jp, imp@village.org, current@freebsd.org In-Reply-To: <199608260143.SAA12137@MindBender.serv.net> from "Michael L. VanLoon" at "Aug 25, 96 06:43:53 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >I think you've already done things nicely by spreading out the disk i/o, > >compiles are also CPU intensive so the x486 looks like your bottle neck. > >I'm skepical that you can really get the disks singing in harmony to take > >advantage of Ultra Wide. Though it's generally a good thing to have > >advances in bus architectures so that it puts pressure on the peripherals > >to catch up. > > I can tell you, for a fact, that you won't get Ultra Wide bandwidth > out of a 486 on real filesystem data. The 486 design just doesn't > have enough power. The best you'll probably do, on real-world use, is > maxing out fast SCSI (10MB/s), and then only if you tune well. More correctly you won't get more than 6 to 8MB/s on ISA based 486 systems, or 12 to 17MB/s on EISA based 486 systems, and about the same on PCI based 486 systems. The ISA based is limited by how fast you can bus master on the ISA bus, and few boards will do about 8MB/s. The EISA/PCI systems are limited by the bcopy speed of the 486, the only 486 board that I could get to hit 17MB/s was the ASUS PCI/I-486SP3G, and it could do it because it uses 2 way interleaved memory, and a decent PCI chip set. These are real live test results from my work 2 years ago on a stripping disk drive that was finally tuned to the customers application, I couldn't break the 17MB/s barrier until we changed the design to PCI/Pentium. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Aug 25 23:35:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA21236 for current-outgoing; Sun, 25 Aug 1996 23:35:38 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA21231; Sun, 25 Aug 1996 23:35:33 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id WAA05397; Sun, 25 Aug 1996 22:54:57 +0200 (MET DST) To: Christoph Kukulies cc: freebsd-current@freefall.freebsd.org Subject: Re: dead code in /sys/i386/isa/clock.c (glitch) In-reply-to: Your message of "Sun, 25 Aug 1996 12:49:23 +0200." <199608251049.MAA20439@gilberto.physik.rwth-aachen.de> Date: Sun, 25 Aug 1996 22:54:57 +0200 Message-ID: <5395.841006497@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199608251049.MAA20439@gilberto.physik.rwth-aachen.de>, Christoph Ku kulies writes: > >/sys/i386/isa/clock.c defines DDB_prtintrtc when DDB is defined >but never uses it. Yeah, it's a function you can call from the debugger but it isn't otherwise used. Bruce hates the DDB_ prefix I put on it btw. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Sun Aug 25 23:38:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA21374 for current-outgoing; Sun, 25 Aug 1996 23:38:44 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA21369 for ; Sun, 25 Aug 1996 23:38:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id XAA00557; Sun, 25 Aug 1996 23:37:32 -0700 (PDT) Message-Id: <199608260637.XAA00557@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Poul-Henning Kamp cc: Christoph Kukulies , freebsd-current@freefall.freebsd.org Subject: Re: dead code in /sys/i386/isa/clock.c (glitch) In-reply-to: Your message of "Sun, 25 Aug 1996 22:54:57 +0200." <5395.841006497@critter.tfs.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 25 Aug 1996 23:37:32 -0700 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >In message <199608251049.MAA20439@gilberto.physik.rwth-aachen.de>, Christoph Ku >kulies writes: >> >>/sys/i386/isa/clock.c defines DDB_prtintrtc when DDB is defined >>but never uses it. > >Yeah, it's a function you can call from the debugger but it isn't >otherwise used. > >Bruce hates the DDB_ prefix I put on it btw. I do, too. :-( -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Sun Aug 25 23:54:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA23378 for current-outgoing; Sun, 25 Aug 1996 23:54:20 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA23369 for ; Sun, 25 Aug 1996 23:54:16 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA17062; Mon, 26 Aug 1996 08:52:47 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA04008; Mon, 26 Aug 1996 08:52:46 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id IAA18794; Mon, 26 Aug 1996 08:35:43 +0200 (MET DST) From: J Wunsch Message-Id: <199608260635.IAA18794@uriah.heep.sax.de> Subject: Re: -current kills harddrives To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 26 Aug 1996 08:35:43 +0200 (MET DST) Cc: amir@neuron.net (Amir Y. Rosenblatt) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199608252130.RAA01702@prozac.neuron.net> from "Amir Y. Rosenblatt" at "Aug 25, 96 05:30:43 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Amir Y. Rosenblatt wrote: > I could hear the disk making little clicking noises (the kind it > makes when you power it up) and spinnign down and then back up over and > over. Overheated. -- 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 Aug 26 00:38:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA25196 for current-outgoing; Mon, 26 Aug 1996 00:38:21 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA25191 for ; Mon, 26 Aug 1996 00:38:19 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id AAA03386; Mon, 26 Aug 1996 00:38:14 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id AAA12917; Mon, 26 Aug 1996 00:37:50 -0700 (PDT) Message-Id: <199608260737.AAA12917@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@freebsd.org (FreeBSD-current users), amir@neuron.net (Amir Y. Rosenblatt) Subject: Re: -current kills harddrives In-reply-to: Your message of Mon, 26 Aug 96 08:35:43 +0200. <199608260635.IAA18794@uriah.heep.sax.de> Date: Mon, 26 Aug 1996 00:37:49 -0700 From: "Michael L. VanLoon" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >As Amir Y. Rosenblatt wrote: >> I could hear the disk making little clicking noises (the kind it >> makes when you power it up) and spinnign down and then back up over and >> over. >Overheated. Or a dying power supply... ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Mon Aug 26 02:20:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA29072 for current-outgoing; Mon, 26 Aug 1996 02:20:03 -0700 (PDT) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA29011; Mon, 26 Aug 1996 02:19:54 -0700 (PDT) Received: from sol1.gud.siemens.co.at (root@firix [10.1.143.100]) by eins.siemens.at (8.7.4/8.7.3) with SMTP id LAA27206; Mon, 26 Aug 1996 11:17:57 +0200 (MET DST) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0uuxnu-00021iC; Mon, 26 Aug 96 11:17 MET DST Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA242520847; Mon, 26 Aug 1996 11:14:07 +0200 From: "Hr.Ladavac" Message-Id: <199608260914.AA242520847@ws2301.gud.siemens.co.at> Subject: Re: The VIVA file system (fwd) To: sysseh@devetir.qld.gov.au (Stephen Hocking) Date: Mon, 26 Aug 1996 11:14:07 +0200 (MESZ) Cc: freebsd-fs@freebsd.org, current@freebsd.org In-Reply-To: <199608250335.DAA21536@netfl15a.devetir.qld.gov.au> from "Stephen Hocking" at Aug 25, 96 03:35:19 am X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk E-mail message from Stephen Hocking contained: Anybody have opinions on this vs LFS? Are we still waiting for the Lite-2 stuff, before LFS can go in? > The package contains a paper on VIVA by its developers, Eric H. Herrin > II > and Raphael A. Finkel, and a report on implementing VIVA in Linux by > Shankar Pasupathy. A brief description of VIVA follows. > > The VIVA filesystem was designed to minimize the time taken for file > operations. VIVA achieves this goal by using an allocation policy that > clusters sequentially accessed disk blocks so that disk-head movement > is minimized. VIVA also uses this clustering to compress block addresses > in an inode from 32 bits to 1 bit, relative to traditional filesystems. > This compression allows us to access about 800KB of data without using > indirect blocks. Benchmark results of our implementation of VIVA in the > Linux kernel show that it is much faster than Ext2, the default Linux > filesystem, for common file operations. > > The Linux implementation of VIVA is a "work in progress". It does not > yet handle partitions larger than 64M (so that the allocation bitmap > fits readily in memory). Individual files are limited to about 8M > (inodes currently have only a single indirect block). There are no > fragments; block size is restricted to 1K. (Adding logical blocks of > larger size will relieve some of these limitations.) Sounds sort of like clustering FFS if I'm reading this correctly. Okay, with a lessened need for indirect blocks, but with a typical unix file length distribution, I don't think they gain overmuch. /Marino > > Shankar Pasupathy > (shankar@pop.uky.edu) > > > From owner-freebsd-current Mon Aug 26 02:59:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA00933 for current-outgoing; Mon, 26 Aug 1996 02:59:01 -0700 (PDT) Received: (from hsu@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA00924; Mon, 26 Aug 1996 02:58:58 -0700 (PDT) Date: Mon, 26 Aug 1996 02:58:58 -0700 (PDT) From: Jeffrey Hsu Message-Id: <199608260958.CAA00924@freefall.freebsd.org> To: lada@ws2301.gud.siemens.co.at Subject: Re: The VIVA file system (fwd) Cc: current, freebsd-fs Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Are we still waiting for the Lite-2 stuff, before LFS can go in? We're waiting for someone to integrate the latest LFS from Keith and Margo with our VM. Compared to that, the the Lite2 VOP changes are minor. There is a new version of LFS in Lite2, but since there's an even newer version available from the author, LFS was left out of the Lite2 integration. From owner-freebsd-current Mon Aug 26 03:37:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA02749 for current-outgoing; Mon, 26 Aug 1996 03:37:22 -0700 (PDT) Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA02741 for ; Mon, 26 Aug 1996 03:37:08 -0700 (PDT) Received: from grumble.grondar.za (localhost.grondar.za [127.0.0.1]) by grumble.grondar.za (8.7.5/8.7.3) with ESMTP id MAA12702; Mon, 26 Aug 1996 12:35:10 +0200 (SAT) Message-Id: <199608261035.MAA12702@grumble.grondar.za> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users), amir@neuron.net (Amir Y. Rosenblatt) Subject: Re: -current kills harddrives Date: Mon, 26 Aug 1996 12:35:09 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > As Amir Y. Rosenblatt wrote: > > > I could hear the disk making little clicking noises (the kind it > > makes when you power it up) and spinnign down and then back up over and > > over. > > Overheated. Could be - I had this on a 1GB drive at work. Screwing it in properly and making the air flow decent by putting on the cover solved that problem. OTOH, at home I had a similar drive behave in much the same way; whenever it was busy, I'd hear the same "click, wind down, wind up, carry on", sometimes accompanied by a panic, and always accompanied by DEVICE RESET (Whatever eveyone is seeing). I solved that problem by replacing a crappy power splitter - (one of those 1-in, 2-out) jobs). I think it had a dry joint or something. Now I have a proper one, and all is well. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-current Mon Aug 26 04:31:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05806 for current-outgoing; Mon, 26 Aug 1996 04:31:47 -0700 (PDT) Received: from shadows.aeon.net (shadows.aeon.net [194.100.41.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA05800 for ; Mon, 26 Aug 1996 04:31:44 -0700 (PDT) Received: (from freebsd@localhost) by shadows.aeon.net (8.7.5/8.6.9) id OAA00702; Mon, 26 Aug 1996 14:27:55 +0300 (EET DST) From: Mr Operating System Message-Id: <199608261127.OAA00702@shadows.aeon.net> Subject: Re: -current kills harddrives To: michaelv@MindBender.serv.net (Michael L. VanLoon) Date: Mon, 26 Aug 1996 14:27:55 +0300 (EET DST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@freebsd.org, amir@neuron.net In-Reply-To: <199608260737.AAA12917@MindBender.serv.net> from "Michael L. VanLoon" at "Aug 26, 96 00:37:49 am" 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> I could hear the disk making little clicking noises (the kind it > >> makes when you power it up) and spinnign down and then back up over and > >> over. > >Overheated. > Or a dying power supply... now that you did mention this... i had noises like that coming from my non freebsd drive too, at work, and throwing the power cable i had away and using another one solved the prob for good... i think... =) mickey From owner-freebsd-current Mon Aug 26 07:45:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA13260 for current-outgoing; Mon, 26 Aug 1996 07:45:32 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA13255 for ; Mon, 26 Aug 1996 07:45:29 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id JAA00178; Mon, 26 Aug 1996 09:42:04 -0500 From: Joe Greco Message-Id: <199608261442.JAA00178@brasil.moneng.mei.com> Subject: Re: -current kills harddrives To: sthaug@nethelp.no Date: Mon, 26 Aug 1996 09:42:04 -0500 (CDT) Cc: amir@neuron.net, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org, nirva@ishiboo.com In-Reply-To: <25899.841010322@verdi.nethelp.no> from "sthaug@nethelp.no" at Aug 25, 96 11:58:42 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Any suggestions (includsing recommendations for > > appropriate external enclosures that'll keep these suckers cool -- I still > > have a 3rd disk I want to add in to the system). > > I'd recommend the TRIMM Trinketbox for the Barracudas. It has a 50W > power supply, and a better than normal fan. I have one of these myself, > and the air coming out of the cabinet by the fan is just mildly warmer > than the surroundings. I just looked at http://www.trimm.com/, VERY nice Web site, I like the level of detail they provide :-) The Trinketbox looks substantially similar to JMR's Chico towers, we have had bad experiences with these because when the fan goes: your drive cooks. I like a minimum of two fans. :-) I would particularly avoid things like their GiftBox (2 drives), etc. for this reason... JMR makes some nice (pricey) cases, their "Plex" family, but they are designed more for multiple drives (the scenario it seems we were discussing anyways). I've only used the HEXPLEX, but it is a very nice enclosure and is as close to ideal as any other non-RAID case I have seen. ... JG From owner-freebsd-current Mon Aug 26 08:33:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA19544 for current-outgoing; Mon, 26 Aug 1996 08:33:21 -0700 (PDT) Received: from hp.com (hp.com [15.255.152.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA19534 for ; Mon, 26 Aug 1996 08:33:04 -0700 (PDT) Received: from srmail.sr.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA131663582; Mon, 26 Aug 1996 08:33:02 -0700 Received: from hpnmhjw.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA164283579; Mon, 26 Aug 1996 08:33:00 -0700 Received: from mina.sr.hp.com by hpnmhjw.sr.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA141643579; Mon, 26 Aug 1996 08:32:59 -0700 Message-Id: <199608261532.AA141643579@hpnmhjw.sr.hp.com> To: current@freefall.freebsd.org Cc: "Rodney W. Grimes" Subject: Re: Speedingup the "worldstone" In-Reply-To: Your message of "Sun, 25 Aug 1996 23:08:11 PDT." Date: Mon, 26 Aug 1996 08:32:59 -0700 From: Darryl Okahata Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Rodney W. Grimes wrote: > More correctly you won't get more than 6 to 8MB/s on ISA based 486 > systems, On an ISA-based system, it's a lot closer to 2MB/s (sustained, not burst). (Or, are you talking about RAID/striping?) Here are some bonnie numbers for a Quantum Fireball 1280S. Note the huge improvement going from ISA to PCI. The first is for an ISA-based 1542CF controller, and the second is for an NCR815/PCI-based controller: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU ISA/1280 60 1349 95.2 2237 63.9 804 35.7 1361 92.2 1943 22.0 42.6 5.7 PCI/1280 256 4267 86.3 4393 19.2 1207 8.3 4118 77.9 4620 17.8 56.8 2.5 The exact same drive mechanism was used on two systems: * 486DX4/100 w/256K cache, 24MB RAM, & an ISA-based Adaptec 1542CF. FreeBSD 2.1R, untuned kernel, untuned 1542 (DMA setting of 5MB/sec). * P133 w/512K cache, 64MB RAM, & an NCR815-based PCI SCSI controller. FreeBSD 2.1R, untuned kernel The block numbers above should be CPU-independent, although I'm not sure about the "per-char" ones; these might be impacted by CPU performance. -- Darryl Okahata Internet: darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. From owner-freebsd-current Mon Aug 26 08:38:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA19700 for current-outgoing; Mon, 26 Aug 1996 08:38:52 -0700 (PDT) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA19693 for ; Mon, 26 Aug 1996 08:38:47 -0700 (PDT) Received: from modem.eng.umd.edu (modem.eng.umd.edu [129.2.98.187]) by po2.glue.umd.edu (8.7.5/8.7.3) with ESMTP id LAA03872 for ; Mon, 26 Aug 1996 11:38:42 -0400 (EDT) Received: from localhost (chuckr@localhost) by modem.eng.umd.edu (8.7.5/8.7.3) with SMTP id LAA05952 for ; Mon, 26 Aug 1996 11:38:41 -0400 (EDT) X-Authentication-Warning: modem.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 26 Aug 1996 11:38:41 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@modem.eng.umd.edu To: FreeBSD current Subject: new gcc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Whats the status of the efforts to get the gcc upgraded? I thought it was going to happen momentarily, about 2 weeks ago. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Mon Aug 26 09:00:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA21117 for current-outgoing; Mon, 26 Aug 1996 09:00:19 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA21112 for ; Mon, 26 Aug 1996 09:00:15 -0700 (PDT) From: sthaug@nethelp.no Received: from verdi.nethelp.no (verdi.nethelp.no [193.91.212.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA27741 for ; Mon, 26 Aug 1996 09:00:10 -0700 (PDT) Received: (qmail-queue invoked from smtpd); 26 Aug 1996 15:58:16 +0000 (GMT) Received: from localhost (HELO verdi.nethelp.no) (@127.0.0.1) by localhost with SMTP; 26 Aug 1996 15:58:16 +0000 (GMT) To: jgreco@brasil.moneng.mei.com Cc: amir@neuron.net, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org, nirva@ishiboo.com Subject: Re: -current kills harddrives In-Reply-To: Your message of "Mon, 26 Aug 1996 09:42:04 -0500 (CDT)" References: <199608261442.JAA00178@brasil.moneng.mei.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 26 Aug 1996 17:58:15 +0200 Message-ID: <3345.841075095@verdi.nethelp.no> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I just looked at http://www.trimm.com/, VERY nice Web site, I like the level > of detail they provide :-) > > The Trinketbox looks substantially similar to JMR's Chico towers, we have > had bad experiences with these because when the fan goes: your drive cooks. > I like a minimum of two fans. :-) Sure, if you can afford it. I replaced another cabinet (for my Barracuda) with the Trinketbox, and it runs *much* cooler now. Also, a big local supplier here always recommends the Trinketbox for the 'cudas - and they do this from experience (those Barracudas run hot!) Btw, the Web page for the Trinketbox mentions 'the new 10000 RPM drives'. Anybody heard more details of these yet? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current Mon Aug 26 09:38:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA23546 for current-outgoing; Mon, 26 Aug 1996 09:38:23 -0700 (PDT) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA23539 for ; Mon, 26 Aug 1996 09:38:21 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by mail.barrnet.net (8.7.5/MAIL-RELAY-LEN) with SMTP id JAA14582 for ; Mon, 26 Aug 1996 09:38:17 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id JAA18794; Mon, 26 Aug 1996 09:31:50 -0700 From: "Rodney W. Grimes" Message-Id: <199608261631.JAA18794@GndRsh.aac.dev.com> Subject: Re: Speedingup the "worldstone" To: darrylo@hpnmhjw.sr.hp.com (Darryl Okahata) Date: Mon, 26 Aug 1996 09:31:49 -0700 (PDT) Cc: current@freefall.freebsd.org In-Reply-To: <199608261532.AA141643579@hpnmhjw.sr.hp.com> from Darryl Okahata at "Aug 26, 96 08:32:59 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Rodney W. Grimes wrote: > > > More correctly you won't get more than 6 to 8MB/s on ISA based 486 > > systems, > > On an ISA-based system, it's a lot closer to 2MB/s (sustained, not > burst). (Or, are you talking about RAID/striping?) I am talking about stripping, and I am also talking about using ISA MB's that you can crank the DMA rate up to 6 or 8Mhz, and I am talking about multiple 1542CF's. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Aug 26 09:38:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA23577 for current-outgoing; Mon, 26 Aug 1996 09:38:56 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA23572; Mon, 26 Aug 1996 09:38:52 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id AAA22795; Tue, 27 Aug 1996 00:38:38 +0800 (WST) Message-Id: <199608261638.AAA22795@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: current@freebsd.org cc: committers@freebsd.org Subject: CTM users take note! Date: Tue, 27 Aug 1996 00:38:37 +0800 From: Peter Wemm Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We have some bigish imports on the drawing board (gcc-2.7.2.1, ncurses, nvi, etc) that might cause the people getting ctm deltas MAILED to them some pain. It's been suggested that the exising ctm-{src,cvs,ports}-cur mailing lists be converted to "slow mailout" and a seperate set of new "fast, all at once" lists be started. Gary Palmer has written a nice slow-delta-mailout backend for the ctm delta generator which should do the job nicely. It defaults to 2 100K chunks per hour, that's 2MB per 10 hours. Is this too much? Too little? The current configuration won't mail out a delta that's more than 3MB, perhaps lowering that would be an alternative. Does anybody have particularly strong feelings about the parameters for this? (Watch the reply address, this is crossposted..) -Peter From owner-freebsd-current Mon Aug 26 09:50:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA24321 for current-outgoing; Mon, 26 Aug 1996 09:50:42 -0700 (PDT) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA24309; Mon, 26 Aug 1996 09:50:38 -0700 (PDT) Received: from modem.eng.umd.edu (modem.eng.umd.edu [129.2.98.187]) by po2.glue.umd.edu (8.7.5/8.7.3) with ESMTP id MAA06664; Mon, 26 Aug 1996 12:50:35 -0400 (EDT) Received: from localhost (chuckr@localhost) by modem.eng.umd.edu (8.7.5/8.7.3) with SMTP id MAA06070; Mon, 26 Aug 1996 12:50:35 -0400 (EDT) X-Authentication-Warning: modem.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 26 Aug 1996 12:50:34 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@modem.eng.umd.edu To: Peter Wemm cc: current@freebsd.org, committers@freebsd.org Subject: Re: CTM users take note! In-Reply-To: <199608261638.AAA22795@spinner.DIALix.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 Aug 1996, Peter Wemm wrote: > We have some bigish imports on the drawing board (gcc-2.7.2.1, ncurses, > nvi, etc) that might cause the people getting ctm deltas MAILED to them > some pain. > > It's been suggested that the exising ctm-{src,cvs,ports}-cur mailing lists > be converted to "slow mailout" and a seperate set of new "fast, all at > once" lists be started. > > Gary Palmer has written a nice slow-delta-mailout backend for the ctm > delta generator which should do the job nicely. > > It defaults to 2 100K chunks per hour, that's 2MB per 10 hours. Is this > too much? Too little? That's ideal for me, at least. > > The current configuration won't mail out a delta that's more than 3MB, > perhaps lowering that would be an alternative. > > Does anybody have particularly strong feelings about the parameters for > this? > > (Watch the reply address, this is crossposted..) > > -Peter > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Mon Aug 26 10:17:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA25572 for current-outgoing; Mon, 26 Aug 1996 10:17:48 -0700 (PDT) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA25566 for ; Mon, 26 Aug 1996 10:17:46 -0700 (PDT) Received: from modem.eng.umd.edu (modem.eng.umd.edu [129.2.98.187]) by po2.glue.umd.edu (8.7.5/8.7.3) with ESMTP id NAA07694; Mon, 26 Aug 1996 13:17:38 -0400 (EDT) Received: from localhost (chuckr@localhost) by modem.eng.umd.edu (8.7.5/8.7.3) with SMTP id NAA06094; Mon, 26 Aug 1996 13:17:37 -0400 (EDT) X-Authentication-Warning: modem.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 26 Aug 1996 13:17:37 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@modem.eng.umd.edu To: FreeBSD Ports cc: Satoshi Asami , FreeBSD current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry for the crossposting, but this does affect two sets of users. I have done some work in ports recently, trying to adapt some stuff in ports to the reality of new /usr/src/contrib stuff in FreeBSD-current. As an example, ghostscript4 now uses the libz in /usr/lib, and not a dependency on the old ports libz. This wasn't a problem, just made it link against new libs, no include file problems. I am doing a new port at home of tcl-dp, distributed processing for tcl using rpc, and the port needs to look at several tcl and tk include files, well beyond just tcl.h. Before tcl was made part of current, this was no problem, I would just make it dependent on the tcl port, and tell the new port where tcl lived in the ports collection. The trouble comes in, in trying to decide where to tell this new port to look for the tcl include files. The only one that has been installed in /usr/include is tcl.h, which is really too little. If I tell the tcl-dp port to look into /usr/src/contrib/tcl/somewhere, then anyone not having the full FreeBSD-current sources is out of luck. This seems way too draconian a requirement. I'd like to suggest that maybe a /usr/include/tcl be made, and fully populated with the tcl include files, following the directory setup in /usr/src/contrib/tcl. There aren't that many files involved with that (if this is limited to .h files) and would take care of the problem. I think this would take care of dependencies for the tk41 port too, which will have to be fixed sooner of later too. I would move tcl.h to /usr/include/tcl/tcl.h. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Mon Aug 26 10:19:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA25641 for current-outgoing; Mon, 26 Aug 1996 10:19:15 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA25636 for ; Mon, 26 Aug 1996 10:19:12 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA00614; Mon, 26 Aug 1996 12:16:31 -0500 From: Joe Greco Message-Id: <199608261716.MAA00614@brasil.moneng.mei.com> Subject: Re: -current kills harddrives To: sthaug@nethelp.no Date: Mon, 26 Aug 1996 12:16:31 -0500 (CDT) Cc: jgreco@brasil.moneng.mei.com, amir@neuron.net, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org, nirva@ishiboo.com In-Reply-To: <3345.841075095@verdi.nethelp.no> from "sthaug@nethelp.no" at Aug 26, 96 05:58:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I just looked at http://www.trimm.com/, VERY nice Web site, I like the level > > of detail they provide :-) > > > > The Trinketbox looks substantially similar to JMR's Chico towers, we have > > had bad experiences with these because when the fan goes: your drive cooks. > > I like a minimum of two fans. :-) > > Sure, if you can afford it. I replaced another cabinet (for my Barracuda) > with the Trinketbox, and it runs *much* cooler now. Also, a big local > supplier here always recommends the Trinketbox for the 'cudas - and they > do this from experience (those Barracudas run hot!) Yes they do, too many people don't take that literally... these fish fry! I am just leery of anything with a single fan, as noted, because I've seen disk cans like the Trinketbox become disk _ovens_ when they contain a Barra and a bad fan. > Btw, the Web page for the Trinketbox mentions 'the new 10000 RPM drives'. > Anybody heard more details of these yet? Nope... but, curious. I have noticed that the new Seagate Hawk 1GB drives (31055N) can outperform the Barra 2G's (32550N) at some things, and I believe the Hawk's are still 5400 RPM... we are seeing technology move so fast. ... JG From owner-freebsd-current Mon Aug 26 11:20:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00292 for current-outgoing; Mon, 26 Aug 1996 11:20:32 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA00287 for ; Mon, 26 Aug 1996 11:20:30 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA17599; Mon, 26 Aug 1996 11:18:55 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) by whistle.com via smap (V1.3) id sma017597; Mon Aug 26 11:18:34 1996 Date: Mon, 26 Aug 1996 11:17:35 -0700 (PDT) From: Julian Elischer To: Chuck Robey cc: FreeBSD current Subject: Re: new gcc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 Aug 1996, Chuck Robey wrote: > Whats the status of the efforts to get the gcc upgraded? I thought it was > going to happen momentarily, about 2 weeks ago > Maybe it did happen momentarily and you missed it? seriously I laugh so much about the differnce in the way Americans use the word "momentarily" from the way it is used in OZ (and UK too I believe) for the Americans thinking "Huh?" We use the word Momentarily to mean "FOR a moment" , not "In a moment" so now interpret "The train will be leaving momentarily" and "Gcc2.7 will be implimented momentarily" in this new light and see why it breaks me up so much.. julian From owner-freebsd-current Mon Aug 26 12:06:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05020 for current-outgoing; Mon, 26 Aug 1996 12:06:18 -0700 (PDT) Received: from jupiter.stochastik.rwth-aachen.de (odiug@jupiter.Stochastik.RWTH-Aachen.DE [137.226.106.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA04999; Mon, 26 Aug 1996 12:06:14 -0700 (PDT) Received: (from odiug@localhost) by jupiter.stochastik.rwth-aachen.de (8.7.4/BuGless_1.03/MS1.00) id VAA06960; Mon, 26 Aug 1996 21:04:44 +0200 (MET DST) From: Guido Muesch Message-Id: <199608261904.VAA06960@jupiter.stochastik.rwth-aachen.de> Subject: NCR & AMD DX/4-133 problem To: hardware@FreeBSD.ORG Date: Mon, 26 Aug 1996 21:04:43 +0200 (MET DST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I get the following when booting FreeBSD-current from my SCSI disk: Using an AMD-133: ncr0 rev 17 int a irq 9 on pci0:29 ncr waiting fo scsi devices to settle ncr0:0: ERROR (81:0) (8-0-0) (0/13) @ (ffdac008:f000f773) reg: ca 00 00 13 47 00 00 1f 31 08 04 00 80 00 08 02. ncr0: restart (fatal error). (ncr0:0:0): COMMAND FAILED (9 ff) @ f09fa8dc. When I have my old AMD-100 plugged in, everything works fine. I get this with two different boards. (One of them did not support the AMD-133 right). But the DOS driver seems to work with the second. Is it a hardware problem? Should I get just another mainboard? (This mainboard is a Pine PT-432B) Help Guido From owner-freebsd-current Mon Aug 26 12:15:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA07127 for current-outgoing; Mon, 26 Aug 1996 12:15:14 -0700 (PDT) Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA07121 for ; Mon, 26 Aug 1996 12:15:12 -0700 (PDT) Received: from delphi.gordian.com (delphi.gordian.com [192.73.220.125]) by gordius.gordian.com (8.7.5/8.6.5) with ESMTP id MAA27146 for ; Mon, 26 Aug 1996 12:15:13 -0700 (PDT) Received: (from steve@localhost) by delphi.gordian.com (8.7.2/8.6.9) id MAA10702; Mon, 26 Aug 1996 12:15:09 -0700 (PDT) Date: Mon, 26 Aug 1996 12:15:09 -0700 (PDT) Message-Id: <199608261915.MAA10702@delphi.gordian.com> From: Steve Khoo To: freebsd-current@freebsd.org Subject: problems booting with 2 drives on NCR8251D Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk setup: Asus MB(P55TP4XEG) 512K Cache 32MB RAM Fast Wide Differential SCSI Controller (NCR8251D) Seagate ST12550WD on SCSI ID #0 Seagate ST15150WD on SCSI ID #1 The system is running FreeBSD 2.2-CURRENT sup'd on 8/17/96. The system boots and runs find with just the first(Seagate ST12550WD) drive. When I added the second(Seagate ST15150WD) drive I get the following errors. I can boot dos and do fdisk/format and stuff on the second drive without any problems. Any ideas what the errors mean? I'd appreciate any help. Thanks! SEK FreeBSD 2.2-CURRENT #0: Mon Aug 19 12:48:53 PDT 1996 steve@metis.gordian.com:/usr/src/sys/compile/metis Calibrating clock(s) relative to mc146818A clock... i586 clock: 99465569 Hz, i8254 clock: 1193086 Hz CPU: Pentium (99.47-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30695424 (29976K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7:0 pci0:7:1: Intel Corporation, device=0x1230, class=storage (ide) [no driver assigned] de0 rev 18 int a irq 12 on pci0:9 de0: SMC 9332 DC21140 [10-100Mb/s] pass 1.2 de0: address 00:00:c0:58:c3:e4 de0: enabling 10baseT port ncr0 rev 2 int a irq 10 on pci0:10 ncr0 waiting for scsi devices to settle (ncr0:0:0): "SEAGATE ST12550W 0004" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled. sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2040MB (4178874 512 byte sectors) (ncr0:1:0): "SEAGATE ST15150W 0023" type 0 fixed SCSI 2 sd1(ncr0:1:0): Direct-Access sd1(ncr0:1:0): WIDE SCSI (16 bit) enabled. ncr0:1: ERROR (80:91) (9-ae-0) (0/1b) @ (d8c:19000004). script cmd = 89030000 reg: da 10 80 1b 47 00 01 07 23 09 81 ae 80 00 0e 08. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. sd1 could not mode sense (4). Using ficticious geometry ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. ncr0: aborting job ... ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). script cmd = 878b0000 reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. ncr0: restart (fatal error). sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. sd1: could not get size 0MB (0 512 byte sectors) From owner-freebsd-current Mon Aug 26 12:35:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08421 for current-outgoing; Mon, 26 Aug 1996 12:35:03 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA08414 for ; Mon, 26 Aug 1996 12:35:01 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA28052 for ; Mon, 26 Aug 1996 12:34:57 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA22871; Mon, 26 Aug 1996 11:06:54 -0700 From: Terry Lambert Message-Id: <199608261806.LAA22871@phaeton.artisoft.com> Subject: Re: -current kills harddrives To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Mon, 26 Aug 1996 11:06:54 -0700 (MST) Cc: sthaug@nethelp.no, jgreco@brasil.moneng.mei.com, amir@neuron.net, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org, nirva@ishiboo.com In-Reply-To: <199608261716.MAA00614@brasil.moneng.mei.com> from "Joe Greco" at Aug 26, 96 12:16:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Btw, the Web page for the Trinketbox mentions 'the new 10000 RPM drives'. > > Anybody heard more details of these yet? > > Nope... but, curious. I have noticed that the new Seagate Hawk 1GB drives > (31055N) can outperform the Barra 2G's (32550N) at some things, and I > believe the Hawk's are still 5400 RPM... we are seeing technology move so > fast. Faster, dammit, faster! 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 Aug 26 12:37:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09113 for current-outgoing; Mon, 26 Aug 1996 12:37:56 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA09100 for ; Mon, 26 Aug 1996 12:37:54 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA28059 for ; Mon, 26 Aug 1996 12:37:53 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA23022; Mon, 26 Aug 1996 12:23:53 -0700 From: Terry Lambert Message-Id: <199608261923.MAA23022@phaeton.artisoft.com> Subject: Re: new gcc To: julian@current1.whistle.com (Julian Elischer) Date: Mon, 26 Aug 1996 12:23:53 -0700 (MST) Cc: chuckr@glue.umd.edu, freebsd-current@freefall.freebsd.org In-Reply-To: from "Julian Elischer" at Aug 26, 96 11:17:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Maybe it did happen momentarily and you missed it? > > seriously I laugh so much about the differnce in the way > Americans use the word "momentarily" from the way it is used > in OZ (and UK too I believe) > > for the Americans thinking > "Huh?" > We use the word Momentarily to mean "FOR a moment" , not "In a moment" > so now interpret "The train will be leaving momentarily" > and "Gcc2.7 will be implimented momentarily" in this new light and see > why it breaks me up so much.. Americans use "momentarily" that way as well; we just derive it from context. It is not nearly so funny as the misuse of "moot". Everyone says "it's a moot point" to mean "it's not worthy of discussion" when they are trying to sound intellectual. Look it up -- "moot" means "subject to discussion". There are lots of examples where context modifies of English words in "American English". 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 Aug 26 12:48:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA10114 for current-outgoing; Mon, 26 Aug 1996 12:48:53 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA10102; Mon, 26 Aug 1996 12:48:48 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id VAA07395; Mon, 26 Aug 1996 21:40:16 +0200 (MET DST) To: Chuck Robey cc: FreeBSD Ports , Satoshi Asami , FreeBSD current In-reply-to: Your message of "Mon, 26 Aug 1996 13:17:37 EDT." Date: Mon, 26 Aug 1996 21:40:15 +0200 Message-ID: <7393.841088415@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message , Chuck R obey writes: >I'd like to suggest that maybe a /usr/include/tcl be made, and fully >populated with the tcl include files, following the directory setup in >/usr/src/contrib/tcl. There aren't that many files involved with that (if >this is limited to .h files) and would take care of the problem. I think >this would take care of dependencies for the tk41 port too, which will >have to be fixed sooner of later too. yes. >I would move tcl.h to /usr/include/tcl/tcl.h. no. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Aug 26 13:15:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12662 for current-outgoing; Mon, 26 Aug 1996 13:15:55 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-175.ut.nl.ibm.net [139.92.42.175]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA12649; Mon, 26 Aug 1996 13:15:45 -0700 (PDT) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id RAA16960; Mon, 26 Aug 1996 17:17:42 +0200 (MET DST) Message-Id: <199608261517.RAA16960@vector.jhs.no_domain> To: Bora Akyol cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@freebsd.org (FreeBSD-current users), hoek@freenet.hamilton.on.ca Subject: Re: Help on block size in tar From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Address: Holz Strasse 27d, 80469 Munich, Germany Phone: +49.89.268616 Fax: +49.89.2608126 Web: http://www.freebsd.org/~jhs/ Mailer: EXMH 1.6.7, PGP available In-reply-to: Your message of "Sat, 24 Aug 1996 10:06:40 EDT." <199608241406.KAA03455@james.freenet.hamilton.on.ca> Date: Mon, 26 Aug 1996 17:17:42 +0200 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: hoek@freenet.hamilton.on.ca > Subject: Re: Help on block size in tar > Date: Sat, 24 Aug 1996 10:06:40 -0400 (EDT) > Message-id: <199608241406.KAA03455@james.freenet.hamilton.on.ca> > > In Email, J Wunsch wrote: > > > > What is the default blocksize of tar on FreeBSD, I have made a tape > > > > on a freebsd system and now cannot read it on a linux system. > > > > > it may be more complicated... > > > it might be teh TAPE DRIVE complaining... > > > > Anyway, i think the default blocksize is only 512 bytes. This should > > also pass any variable-length driver. > > Are you sure? I quote the tar manpage (which, being GNU tar isn't the > official source of information regarding tar, I suppose). tar --help says: -b, --block-size N block size of Nx512 bytes (default N=20) so it is official. > "and 20 is the default block size" > > And each of these blocks are then 512 bytes, I believe. > > Or the manpage is just confusing the heck out of me. Maybe the tape drive used for writing was capable of variable blocking (like my "TANDBERG TDC 3800 =04Y" type 1 removable SCSI 2 Sequential-Access density code 0x0, drive empty ) If one writes a tape on that without `mt blocksize 512', and then tries to read it elsewhere, problems can occur.... so maybe the tape was written with variable blocking. Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Mon Aug 26 13:17:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12879 for current-outgoing; Mon, 26 Aug 1996 13:17:10 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-175.ut.nl.ibm.net [139.92.42.175]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA12833; Mon, 26 Aug 1996 13:16:59 -0700 (PDT) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id RAA16897; Mon, 26 Aug 1996 17:05:54 +0200 (MET DST) Message-Id: <199608261505.RAA16897@vector.jhs.no_domain> To: "Rodney W. Grimes" cc: jkh@time.cdrom.com (Jordan K. Hubbard), julian@whistle.com, nirva@ishiboo.com, freebsd-current@freebsd.org Subject: Re: -current kills harddrives From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Address: Holz Strasse 27d, 80469 Munich, Germany Phone: +49.89.268616 Fax: +49.89.2608126 Web: http://www.freebsd.org/~jhs/ Mailer: EXMH 1.6.7, PGP available In-reply-to: Your message of "Fri, 23 Aug 1996 17:23:57 PDT." <199608240023.RAA15876@GndRsh.aac.dev.com> Date: Mon, 26 Aug 1996 17:05:54 +0200 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: "Rodney W. Grimes" > > > > > I seriously doubt that -current is killing your hard drives. > > > > Some things you just can't do from software, even if you wanted > > > > to. > > > > > > That's not true. & then there was my ex colleague in London, who decided `acceptance test' included getting all the _big_ drives in a row of racks to head seek the same way, at the same time, & then tuning to resonant frequency of the row of racks ... ! Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Mon Aug 26 13:53:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA15120 for current-outgoing; Mon, 26 Aug 1996 13:53:40 -0700 (PDT) Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA15112; Mon, 26 Aug 1996 13:53:36 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-13.slip.Uni-Koeln.DE) by FileServ1.MI.Uni-Koeln.DE with SMTP id AA15792 (5.67b/IDA-1.5); Mon, 26 Aug 1996 22:53:24 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.5/8.6.9) id WAA03904; Mon, 26 Aug 1996 22:47:02 +0200 (MET DST) Date: Mon, 26 Aug 1996 22:47:02 +0200 (MET DST) Message-Id: <199608262047.WAA03904@x14.mi.uni-koeln.de> From: Stefan Esser To: Guido Muesch Cc: hardware@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: NCR & AMD DX/4-133 problem In-Reply-To: <199608261904.VAA06960@jupiter.stochastik.rwth-aachen.de> References: <199608261904.VAA06960@jupiter.stochastik.rwth-aachen.de> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Guido Muesch writes: > I get the following when booting FreeBSD-current from my SCSI disk: > > Using an AMD-133: > > ncr0 rev 17 int a irq 9 on pci0:29 > ncr waiting fo scsi devices to settle > ncr0:0: ERROR (81:0) (8-0-0) (0/13) @ (ffdac008:f000f773) Hmm, the 81 means "Illegal Instruction", and the pair of values at the end of the line does fully support the NCR chips complains :) Seems that the NCR reads corrupt data from memory when fetching its instructions. > reg: ca 00 00 13 47 00 00 1f 31 08 04 00 80 00 08 02. > ncr0: restart (fatal error). > (ncr0:0:0): COMMAND FAILED (9 ff) @ f09fa8dc. > > When I have my old AMD-100 plugged in, everything works fine. Yes, the error message above indicates some kind of hardware problem, though not everything is lost ... > I get this with two different boards. (One of them did not support the > AMD-133 right). But the DOS driver seems to work with the second. Actually, that doesn't prove a lot :) The DOS drivers tend to ignore most of the features that make the NCR controllers interesting under a multi-tasking OS. > Is it a hardware problem? Should I get just another mainboard? > (This mainboard is a Pine PT-432B) Don't know that motherboard. As always: Please boot with "-v" and send me the message log (as written to /var/log/messages). I'll know which chip set there is, and possibly which cache configuration and PCI performance options are in effect. My current suspicion is that you are using the Write-Back mode of the AMD5x86s primary cache, and that your motherboard's chip set does not actually support that feature. Please try again with the primary cache set to Write-Through, or with the primary cache disabled. Send me your results ... Gruss, STefan From owner-freebsd-current Mon Aug 26 14:16:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16654 for current-outgoing; Mon, 26 Aug 1996 14:16:18 -0700 (PDT) Received: from clem.systemsix.com ([198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA16648 for ; Mon, 26 Aug 1996 14:16:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA22453 for ; Mon, 26 Aug 1996 15:16:10 -0600 Message-Id: <199608262116.PAA22453@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: current@freefall.freebsd.org Subject: Re: current-digest V1 #566 In-reply-to: Your message of "Mon, 26 Aug 1996 12:37:59 PDT." <199608261937.MAA09135@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Aug 1996 15:16:10 -0600 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > The Trinketbox looks substantially similar to JMR's Chico towers, we have > had bad experiences with these because when the fan goes: your drive cooks. Steve's golden rule for buying disk cases: find the case you like and buy it. throw away the fan, it will be junk. buy a GOOD, BRAND-NAME, ball-bearing fan from digikey or other reliable parts house other hints: if the front panel is removable, REMOVE IT, it may look ugly, but free air will flow directly across top of drive if it has airflow holes on bottom (or top if stacked) get extra tall rubber feet from hardware store. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-current Mon Aug 26 15:06:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA19670 for current-outgoing; Mon, 26 Aug 1996 15:06:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA19658; Mon, 26 Aug 1996 15:05:53 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA23328; Mon, 26 Aug 1996 14:55:12 -0700 From: Terry Lambert Message-Id: <199608262155.OAA23328@phaeton.artisoft.com> Subject: Re: The VIVA file system (fwd) To: eric@ms.uky.edu Date: Mon, 26 Aug 1996 14:55:12 -0700 (MST) Cc: terry@lambert.org, freebsd-fs@freebsd.org, current@freebsd.org In-Reply-To: <9608252145.aa12275@t2.t2.mscf.uky.edu> from "eric@ms.uky.edu" at Aug 25, 96 09:45:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I guess I should respond to this thread since I happen to be on > all these nice FreeBSD mailing lists nowadays. > > The Linux version was done by one of Raphael's Master's students. > It isn't complete, but it does apparently work (I personally have > not seen it nor have I seen the performance figures). > > As a side note, I am currently working on Viva2, which should be a much > more interesting gadget. Anyway, it is in active development again > and FreeBSD is the platform this time. > > > The VIVA stuff is, I think, overoptimistic. > > > > They have made a number of claims in the University of Kentucky papers > > that were published about two years ago that seem to rely on overly > > optimistic assumptions about policy and usage. > > You might explain this one, I'm not sure I know what you mean. The > paper was written over three years ago. The work was actually > performed from late 1991-1992. The AT&T lawsuit came out, I became > distracted with making a living, and haven't gotten back to it until > a couple months ago. The optimism is in terms of comparative technology. The FFS you talk about in the paper is *not* the FFS FreeBSD is running. Sorry if this seemed like an attack on VIVA; it was intended as an attack on the idea of replacing FFS with VIVA based on the contents of the paper, and the fact that "Linux has it, now we need it!". I know that I saw the paper at least two years and 5 months ago, if not before that -- I *think* I saw it the week it came out; there was a presentation by one of the grad students involved to the USL FS gurus: Art Sabsevitch, Wen Ling Lu, etc., of the code on SVR4. > For all the discussion below, you must remember that the platforms for > Viva were 1) AT&T SysV, and 2) BSDI's BSD/386. We abandoned SysV > because I wanted to release the code, then came the AT&T lawsuit:-( I saw the code on #1. That's part of what made me skeptical; the SVR4 FFS implementation was intentionally (IMO) crippled on a lot of defaults and tunables so they could make the claims they did about VXFS. The VXFS code was the shining golden baby. Never mind that it was itself FFS derived (for example, it used SVR4 UFS directory management code without modification). Any comparison against SVR4 UFS as it was will be incredibly biased, even if the bias was not an intentional result of the testing conditions, because the UFS code came pre-biased. 8-(. > > They also seemed to pick "worst case" scenarios for comparison with FFS, > > and avoided FFS best case. > > We did our testing on clean, freshly newfs'd partitions for the graphs. > I don't see how this is "worst case", but perhaps you mean the types > of tests we ran. Obviously, we ran some tests that showed a difference > between FFS and Viva. Well, of course. And without looking at it side-by-side myself, I really couldn't say if there were only positive-for-VIVA comparisons existing, or only positive one presented. The near-full-disk scenario seemed a bit contrived, but *could* be justified in real world usage. Like I said, I'd like to see someone working on a thesis (or with a similar incentive for detail) revisit the whole thing in light of the rewritten FICUS-derived-VFS-based FFS code in FreeBSD, post cache-unification. I wonder if all the locality wins would still hold. My opinion is that at least three of them would not; I'd be happy to be proven wrong, and find out that they are additive to the VM/buffer cache architecture improvements in FreeBSD's VFS/VM interface. > > This is not nearly as bad as the MACH MSDOSFS papers, which intentioanlly > > handicapped FFS through parameter setting and cache reduction, while > > caching the entire DOS FAT in core was seen as being acceptable, to > > compare their work to FFS. > > > > But it is certainly not entirely unbiased reporting. > > I'm not sure how to react to this. Can one write an "entirely > unbiased" report about one's own work? Personally, I don't think > so. We tried. I'll leave it at that. I don't think it's possible, either -- conclusions must always be taken with a grain of salt. It is definitely *not* in the same class as the MACH paper, which exhibited intentional bias. I guess this would have read better if you knew about the MACH paper's taking of license before you read my comment. Sorry about that -- I tend to assume everyone has the same context, or is willing to get it. I wasn't going off half-cocked. > > The read and rewrite differences are moslty attributable to policy > > issues in the use of FFS "optimizations" which are inapropriate to > > the hardware used. > > The read and rewrite differences are due to the fact FFS didn't do > clustering very well at all. BSDI *still* doesn't do it well, but > FreeBSD appears to be much better at it. I'm still running tests > though and probably will be running tests for some time yet. Yes. Like I said, Matt Day's work on this is relevent, but it may never see the light. He's made some comments to the effect of what he has done in brief discussions on the -current list. Even with the recent work, there's a lot of room for improvement in FreeBSD clustering and write-gathering, without needing a new disk layout to get it. As before, I'm not sure if this is additive or parallel to the VIVA developement. > > Finally, I am interested in, but suspicious of, their compression > > claims, since they also claim that the FFS performance degradation, > > which Knuth clearly shows to be a hash effect to be expected after > > an 85% fill (in "Sorting and Searching"), to be nonexistant. > > Well, the results are in the paper. This is what we saw, but > you should look at the table carefully. There are places where > the effective clustering of a particular file degrades over 50%, > but that was (at the time) about as good as FFS ever did anyway. > The mean effective clustering always remained very high (90%+). Yes; I didn't make the distinction on "effective clustering", the term which was introduced in the paper. I'm really not sure about one cache effect being superior to another in a unified VM. The FFS does do clustering as well, and it seems that this has more to do with file I/O clustering mapping to disk I/O clustering effectively than anything that might be a real artifact of the FFS layout itself. The address space compression is interesting for vnode-based buffering; FreeBSD currently uses this method, but... well, I've railed often enough against vclean that I think everyone knows how I feel. > I should have some more modern numbers in a few months, Raphael's > student probably has some for Linux now. I think he used the > original algorithms. Yes... really, it wants a new paper (or 3 or 5 of them). There is a lot of room for exciting work in FS development. I just think that it would be ill-advised to expect the same gains in a FreeBSD framework, at least until some basic academic work has taken place that addresses the new situation. > > INRE: "where the wins come from", the "Discussion" reverses the > > claims made earlier in the paper -- we see that the avoidance of > > indirect blocks is not the primary win (a conclusion we came to > > on our own from viewing the earlier graphs). > > This is correct, the big performance wins came from: > > 1) Large block sizes and small frag sizes > 2) Good clustering > 3) Multiple read-ahead Yes; the only one failing in FreeBSD right now is #3. There is some room for improvement in #2 for writes, but that won't affect the read/rewrite speeds (or shouldn't). > > We also see in "Discussion" that caching file beginnings/ends in the > > inode itself is not a win as they has hoped. In fact, compilation > > times are pessimized by 25% by it. > > Yes, we were disappointed by that, but it just confirmed what others > (Tanenbaum for example) had seen earlier. You should remember > that one reason for the degradation was that it threw off all > the code that tries to read things in FS block-sized chunks. > We wanted to be able to read headers in files quickly and it *does* > do that well. We just thought it would be nice to provide that > capability (some people have entire file systems dedicated to > particular tasks). Some space in the inode can be used for lots > of things, perhaps it would be most useful at user level and disjoint > from the bytes in the file. I was considering this at one time for executable header information, to cause the pages in the actual binary on disk to be block aligned for more efficient paging at the boundry conditions. This is probably still a win, but might be better handled by moving to a more generic attribution mechanism. I should probably say that I've had experience both with upping the directory block size (for Unicode and multiple name space support), and with doubling the inode size (for use in attribution -- NetWare, Apple, OS/2, and NT file attributes, specifically). I saw similar NULL effects everywhere but for competition with Veritas, which must fault seperate pages for their file attribution, and so pay a serious performance penalty for use of attributes, in comparison. So for that case, it maintained the status quo instead of being a loss. I also found it useful to combine the directory lookup and stat operations into a single system call, saving two protection domain crossings, and to pre-fault the inode asynchronously when the directory entry was referenced. This last assumed locality of usage, and was probably more related to the application (attributed kernel FS for NetWare services in a UNIX environment) than to a general win. Like the file rewrite benchmark in the VIVA paper, this was a specialized usage, and more related to implementation than architecture... for file rewrites on a block boundry granularity, it is not strictly necessary to fault in the blocks to be rewritten from the disk, using the historical read-before-write, and then comparing the (obviously bad) numbers that result. To my knowledge, partial page sequential writes on block or multiple-of-block granularity are possible, but not currently supported by the FreeBSD VM. If supported, I expect that the win from doing the rewrite that way will dwarf any small relative win into insignificance. In any case, the VIVA code is worth pursuing; just not for the reasons that seemed to be behind the original posting ("Linux has it, we must have it"). If someone wants to pursue it mining for a thesis, it's far better than some of the other areas people tend to look to. Regards, 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 Aug 26 16:03:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA22653 for current-outgoing; Mon, 26 Aug 1996 16:03:15 -0700 (PDT) Received: from UKCC.uky.edu (ukcc.uky.edu [128.163.1.170]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA22634; Mon, 26 Aug 1996 16:03:11 -0700 (PDT) Received: from t2.mscf.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R3) with TCP; Mon, 26 Aug 96 19:01:03 EDT Received: from t1.mscf.uky.edu by t2.ms.uky.edu id aa24476; 26 Aug 96 18:58 EDT From: eric@ms.uky.edu Subject: Re: The VIVA file system (fwd) To: Terry Lambert Date: Mon, 26 Aug 1996 18:58:09 -0400 (EDT) Cc: freebsd-fs@freebsd.org, current@freebsd.org In-Reply-To: <199608262155.OAA23328@phaeton.artisoft.com> from "Terry Lambert" at Aug 26, 96 02:55:12 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <9608261858.aa24476@t2.t2.mscf.uky.edu> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I know that I saw the paper at least two years and 5 months ago, if not > before that -- I *think* I saw it the week it came out; there was a > presentation by one of the grad students involved to the USL FS gurus: > Art Sabsevitch, Wen Ling Lu, etc., of the code on SVR4. > I was the sole implementor of all versions of Viva. No other grad students were involved at the time... > > > For all the discussion below, you must remember that the platforms for > > Viva were 1) AT&T SysV, and 2) BSDI's BSD/386. We abandoned SysV > > because I wanted to release the code, then came the AT&T lawsuit:-( > > I saw the code on #1. That's part of what made me skeptical; the > SVR4 FFS implementation was intentionally (IMO) crippled on a lot > of defaults and tunables so they could make the claims they did > about VXFS. The VXFS code was the shining golden baby. Never mind > that it was itself FFS derived (for example, it used SVR4 UFS directory > management code without modification). Any comparison against SVR4 > UFS as it was will be incredibly biased, even if the bias was not > an intentional result of the testing conditions, because the UFS > code came pre-biased. 8-(. Are you talking about VIFS or VXFS? I seem to remember that VXFS was the Veritas File System. Veritas had nothing to do with Viva. Perhaps you are confusing the two. Eric From owner-freebsd-current Mon Aug 26 16:04:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA22729 for current-outgoing; Mon, 26 Aug 1996 16:04:08 -0700 (PDT) Received: from PACBELL.net (chumash.snfc21.pbi.net [206.13.28.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA22724 for ; Mon, 26 Aug 1996 16:04:06 -0700 (PDT) Received: from [206.170.0.31] (ppp-206-170-0-31.snfc21.pacbell.net [206.170.0.31]) by PACBELL.net (8.7.5/8.7.1) with SMTP id QAA20421; Mon, 26 Aug 1996 16:00:11 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Aug 1996 16:04:14 -0700 To: terry@lambert.org From: leonard@pacbell.net (Leonard Chung) Subject: Re: new gcc Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >It is not nearly so funny as the misuse of "moot". > >Everyone says "it's a moot point" to mean "it's not worthy of discussion" >when they are trying to sound intellectual. Look it up -- "moot" means >"subject to discussion". I looked up "moot" in my dictionary, and it defines "moot" as "subject to debate; arguable." However, it also says that in the context of law, "moot" means "a. Lacking legal significance, though having been previously decided or settled. b. Of no practical importance; academic." The use of "a moot point" seems to be correct under the context of law... Leonard From owner-freebsd-current Mon Aug 26 16:16:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23152 for current-outgoing; Mon, 26 Aug 1996 16:16:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA23147; Mon, 26 Aug 1996 16:16:05 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA23479; Mon, 26 Aug 1996 16:05:29 -0700 From: Terry Lambert Message-Id: <199608262305.QAA23479@phaeton.artisoft.com> Subject: Re: The VIVA file system (fwd) To: eric@ms.uky.edu Date: Mon, 26 Aug 1996 16:05:29 -0700 (MST) Cc: terry@lambert.org, freebsd-fs@freebsd.org, current@freebsd.org In-Reply-To: <9608261858.aa24476@t2.t2.mscf.uky.edu> from "eric@ms.uky.edu" at Aug 26, 96 06:58:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I know that I saw the paper at least two years and 5 months ago, if not > > before that -- I *think* I saw it the week it came out; there was a > > presentation by one of the grad students involved to the USL FS gurus: > > Art Sabsevitch, Wen Ling Lu, etc., of the code on SVR4. > > I was the sole implementor of all versions of Viva. No other grad > students were involved at the time... Did you do the presentation? I'm sure it was a U of KY grad student who was interning at USL. > Are you talking about VIFS or VXFS? I seem to remember that > VXFS was the Veritas File System. Veritas had nothing to do > with Viva. Perhaps you are confusing the two. VIVA in general, VXFS in the specific instance of why an SVR4 UFS comparison isn't really a strong comparison. 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 Aug 26 16:33:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23632 for current-outgoing; Mon, 26 Aug 1996 16:33:20 -0700 (PDT) Received: from UKCC.uky.edu (ukcc.uky.edu [128.163.1.170]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA23615; Mon, 26 Aug 1996 16:33:16 -0700 (PDT) Received: from t2.mscf.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R3) with TCP; Mon, 26 Aug 96 19:31:08 EDT Received: from t1.mscf.uky.edu by t2.ms.uky.edu id aa27777; 26 Aug 96 19:29 EDT From: eric@ms.uky.edu Subject: Re: The VIVA file system (fwd) To: Terry Lambert Date: Mon, 26 Aug 1996 19:29:06 -0400 (EDT) Cc: freebsd-fs@freebsd.org, current@freebsd.org In-Reply-To: <199608262305.QAA23479@phaeton.artisoft.com> from "Terry Lambert" at Aug 26, 96 04:05:29 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <9608261929.aa27777@t2.t2.mscf.uky.edu> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > I know that I saw the paper at least two years and 5 months ago, if not > > > before that -- I *think* I saw it the week it came out; there was a > > > presentation by one of the grad students involved to the USL FS gurus: > > > Art Sabsevitch, Wen Ling Lu, etc., of the code on SVR4. > > > > I was the sole implementor of all versions of Viva. No other grad > > students were involved at the time... > > Did you do the presentation? I'm sure it was a U of KY grad student > who was interning at USL. Nope. It is possible that some grad student did a presentation without a demo, but they weren't involved with the development or implementation of Viva. > > Are you talking about VIFS or VXFS? I seem to remember that > > VXFS was the Veritas File System. Veritas had nothing to do > > with Viva. Perhaps you are confusing the two. > > VIVA in general, VXFS in the specific instance of why an SVR4 UFS > comparison isn't really a strong comparison. Ok, but we never released *any* results from our UFS implementation. I determined that 1) I couldn't release the code, and 2) UFS on SysV was crippled and didn't make a good comparison. We dropped it totally at that point and I picked up a source copy of BSDI. Eric From owner-freebsd-current Mon Aug 26 16:55:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA24667 for current-outgoing; Mon, 26 Aug 1996 16:55:43 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA24662 for ; Mon, 26 Aug 1996 16:55:40 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id XAA16518; Mon, 26 Aug 1996 23:55:24 GMT Date: Tue, 27 Aug 1996 08:55:24 +0900 (JST) From: Michael Hancock To: Poul-Henning Kamp cc: Christoph Kukulies , freebsd-current@freefall.freebsd.org Subject: Re: dead code in /sys/i386/isa/clock.c (glitch) In-Reply-To: <5395.841006497@critter.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 25 Aug 1996, Poul-Henning Kamp wrote: > In message <199608251049.MAA20439@gilberto.physik.rwth-aachen.de>, Christoph Ku > kulies writes: > > > >/sys/i386/isa/clock.c defines DDB_prtintrtc when DDB is defined > >but never uses it. > > Yeah, it's a function you can call from the debugger but it isn't > otherwise used. > > Bruce hates the DDB_ prefix I put on it btw. How would he name it? From owner-freebsd-current Mon Aug 26 17:04:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA25327 for current-outgoing; Mon, 26 Aug 1996 17:04:57 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA25316 for ; Mon, 26 Aug 1996 17:04:53 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA16562; Tue, 27 Aug 1996 00:00:57 GMT Date: Tue, 27 Aug 1996 09:00:57 +0900 (JST) From: Michael Hancock To: Darryl Okahata cc: current@freefall.freebsd.org, "Rodney W. Grimes" Subject: Re: Speedingup the "worldstone" In-Reply-To: <199608261532.AA141643579@hpnmhjw.sr.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 Aug 1996, Darryl Okahata wrote: > On an ISA-based system, it's a lot closer to 2MB/s (sustained, not > burst). (Or, are you talking about RAID/striping?) > > Here are some bonnie numbers for a Quantum Fireball 1280S. Note > the huge improvement going from ISA to PCI. The first is for an > ISA-based 1542CF controller, and the second is for an NCR815/PCI-based > controller: Has anyone done a 2940/ST32550N vs. 2940UW/ST32550W in one or two disk configurations to quiet people with spec-envy? From owner-freebsd-current Mon Aug 26 17:09:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA25631 for current-outgoing; Mon, 26 Aug 1996 17:09:51 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA25621 for ; Mon, 26 Aug 1996 17:09:47 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA16617; Tue, 27 Aug 1996 00:08:46 GMT Date: Tue, 27 Aug 1996 09:08:46 +0900 (JST) From: Michael Hancock To: Joe Greco cc: sthaug@nethelp.no, amir@neuron.net, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG, nirva@ishiboo.com Subject: Re: -current kills harddrives In-Reply-To: <199608261716.MAA00614@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 Aug 1996, Joe Greco wrote: > Nope... but, curious. I have noticed that the new Seagate Hawk 1GB drives > (31055N) can outperform the Barra 2G's (32550N) at some things, and I > believe the Hawk's are still 5400 RPM... we are seeing technology move so > fast. I/O advances are slooow compared to CPU advances. From owner-freebsd-current Mon Aug 26 17:38:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA27624 for current-outgoing; Mon, 26 Aug 1996 17:38:45 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (daemon@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA27616; Mon, 26 Aug 1996 17:38:38 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.7.5/8.7.3) id KAA06970; Tue, 27 Aug 1996 10:38:28 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id KAA16808; Tue, 27 Aug 1996 10:24:04 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id AAA00161; Tue, 27 Aug 1996 00:24:58 GMT Message-Id: <199608270024.AAA00161@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: Jeffrey Hsu cc: current@freefall.freebsd.org, freebsd-fs@freefall.freebsd.org Subject: Re: The VIVA file system (fwd) In-reply-to: Your message of "Mon, 26 Aug 1996 02:58:58 MST." <199608260958.CAA00924@freefall.freebsd.org> X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 1996 10:24:55 +1000 From: Stephen Hocking Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Are we still waiting for the Lite-2 stuff, before LFS can go in? > > We're waiting for someone to integrate the latest LFS from Keith > and Margo with our VM. Compared to that, the the Lite2 VOP changes > are minor. There is a new version of LFS in Lite2, but since > there's an even newer version available from the author, LFS was > left out of the Lite2 integration. (Gulp) Who's the someone? Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-current Mon Aug 26 17:42:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA27972 for current-outgoing; Mon, 26 Aug 1996 17:42:10 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA27966; Mon, 26 Aug 1996 17:42:07 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA16894; Tue, 27 Aug 1996 00:41:37 GMT Date: Tue, 27 Aug 1996 09:41:37 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG Subject: vclean (was The VIVA file system) In-Reply-To: <199608262155.OAA23328@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 Aug 1996, Terry Lambert wrote: > The address space compression is interesting for vnode-based buffering; > FreeBSD currently uses this method, but... well, I've railed often > enough against vclean that I think everyone knows how I feel. > Some subsystems now depend on the ability to disassociate buffers from vnodes. For example, kill the session leader and the session terminal is revoked from all children and the deadfs is associated with the vnode. The only call that doesn't return an error is close() and the children eventually exit. I think what needs to be looked at is having more synchronized buffer cache/vnode recycling policies. Regards, Mike Hancock From owner-freebsd-current Mon Aug 26 17:49:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA29036 for current-outgoing; Mon, 26 Aug 1996 17:49:13 -0700 (PDT) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA29029 for ; Mon, 26 Aug 1996 17:49:10 -0700 (PDT) Received: from protocol.eng.umd.edu (protocol.eng.umd.edu [129.2.98.180]) by po2.glue.umd.edu (8.7.5/8.7.3) with ESMTP id UAA24098; Mon, 26 Aug 1996 20:49:07 -0400 (EDT) Received: from localhost (chuckr@localhost) by protocol.eng.umd.edu (8.7.5/8.7.3) with SMTP id UAA03640; Mon, 26 Aug 1996 20:49:06 -0400 (EDT) X-Authentication-Warning: protocol.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 26 Aug 1996 20:49:04 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@protocol.eng.umd.edu To: Poul-Henning Kamp cc: FreeBSD Ports , Satoshi Asami , FreeBSD current Subject: Re: your mail In-Reply-To: <7393.841088415@critter.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 Aug 1996, Poul-Henning Kamp wrote: > In message , Chuck R > obey writes: On rereading this, maybe I jumped too soon. You were saying I was right, and that the tcl stuff _should_ be copied to /usr/include/tcl? If you agree (if I have you right) then maybe (being that I suggested the work to begin with) then I oughta do it? If I sent you prosed diffs to the makefile for lib/tcl, would you review it? Or should I send them to Peter? Or let him do it? I don't want to be lazy about it, what's right here? Oh, I caught the last remark about NOT moving tcl.h. I can live with that fine. > > >I'd like to suggest that maybe a /usr/include/tcl be made, and fully > >populated with the tcl include files, following the directory setup in > >/usr/src/contrib/tcl. There aren't that many files involved with that (if > >this is limited to .h files) and would take care of the problem. I think > >this would take care of dependencies for the tk41 port too, which will > >have to be fixed sooner of later too. > yes. > > > >I would move tcl.h to /usr/include/tcl/tcl.h. > no. > > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. > Future will arrive by its own means, progress not so. > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Mon Aug 26 18:29:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA04401 for current-outgoing; Mon, 26 Aug 1996 18:29:51 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA04376 for ; Mon, 26 Aug 1996 18:29:47 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA03830; Tue, 27 Aug 1996 10:59:04 +0930 From: Michael Smith Message-Id: <199608270129.KAA03830@genesis.atrad.adelaide.edu.au> Subject: Where to put Tcl headers (was: "") To: chuckr@glue.umd.edu (Chuck Robey) Date: Tue, 27 Aug 1996 10:59:03 +0930 (CST) Cc: FreeBSD-Ports@FreeBSD.org, asami@cs.berkeley.edu, freebsd-current@freefall.freebsd.org In-Reply-To: from "Chuck Robey" at Aug 26, 96 01:17:37 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Chuck Robey stands accused of saying: > > I'd like to suggest that maybe a /usr/include/tcl be made, and fully > populated with the tcl include files, following the directory setup in > /usr/src/contrib/tcl. There aren't that many files involved with that (if > this is limited to .h files) and would take care of the problem. I think > this would take care of dependencies for the tk41 port too, which will > have to be fixed sooner of later too. This is good. Or maybe /usr/include/contrib/tcl, but that's perhaps going too far. > I would move tcl.h to /usr/include/tcl/tcl.h. Don't. Lots of Tcl-dependant software expects to find it on the standard include path. You might want to symlink it out rather than have two seperate copies though. > Chuck Robey | Interests include any kind of voice or data -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Mon Aug 26 19:04:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA07220 for current-outgoing; Mon, 26 Aug 1996 19:04:30 -0700 (PDT) Received: (from hsu@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA07207; Mon, 26 Aug 1996 19:04:27 -0700 (PDT) Date: Mon, 26 Aug 1996 19:04:27 -0700 (PDT) From: Jeffrey Hsu Message-Id: <199608270204.TAA07207@freefall.freebsd.org> To: sysseh@devetir.qld.gov.au Subject: Re: The VIVA file system (fwd) Cc: current@freefall.freebsd.org, freebsd-fs@freefall.freebsd.org Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>> Are we still waiting for the Lite-2 stuff, before LFS can go in? >> >> We're waiting for someone to integrate the latest LFS from Keith >> and Margo with our VM. > >(Gulp) Who's the someone? > > Stephen Ask not for whom the bell tolls. From owner-freebsd-current Mon Aug 26 19:31:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA16764 for current-outgoing; Mon, 26 Aug 1996 19:31:11 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA16702; Mon, 26 Aug 1996 19:31:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA23773; Mon, 26 Aug 1996 19:20:17 -0700 From: Terry Lambert Message-Id: <199608270220.TAA23773@phaeton.artisoft.com> Subject: Re: vclean (was The VIVA file system) To: michaelh@cet.co.jp Date: Mon, 26 Aug 1996 19:20:17 -0700 (MST) Cc: terry@lambert.org, eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Aug 27, 96 09:41:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The address space compression is interesting for vnode-based buffering; > > FreeBSD currently uses this method, but... well, I've railed often > > enough against vclean that I think everyone knows how I feel. > > Some subsystems now depend on the ability to disassociate buffers from > vnodes. For example, kill the session leader and the session terminal is > revoked from all children and the deadfs is associated with the vnode. > The only call that doesn't return an error is close() and the children > eventually exit. > > I think what needs to be looked at is having more synchronized buffer > cache/vnode recycling policies. Inode data, disklabel data, and any other FS object which is not file contents is not cached under the current policy. Further, dissociating buffers from vnodes does not require that they be returned to a global pool for clean-behind. I think the non-opacity of vnodes is a mistake. 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 Aug 26 20:35:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA03956 for current-outgoing; Mon, 26 Aug 1996 20:35:42 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA03935; Mon, 26 Aug 1996 20:35:35 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id DAA18200; Tue, 27 Aug 1996 03:35:15 GMT Date: Tue, 27 Aug 1996 12:35:14 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: vclean (was The VIVA file system) In-Reply-To: <199608270220.TAA23773@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 Aug 1996, Terry Lambert wrote: > > I think what needs to be looked at is having more synchronized buffer > > cache/vnode recycling policies. > > Inode data, disklabel data, and any other FS object which is not file > contents is not cached under the current policy. The vnode/inode association with a vnhash() you mentioned before makes sense. I wonder how hard it would be to manage the buffer cache/vnodes/inodes with more synergy (sorry I couldn't think of a better word). > Further, dissociating buffers from vnodes does not require that they > be returned to a global pool for clean-behind. There's an in-place free list that can have valid buffers hanging off of them and vnodes go on the list when inactive() is called. I guess the freelist should be called the inactive list. getnewvnode() vgone() vclean() should only be called when it needs to, such as when file activity moves to a different fs and there aren't enough vnodes. The vnode pool was a fixed size pool in lite, but someone put in a malloc() into getnewvnode(). The vnode pool is kind of wired so I think it can now grow, but it can't shrink unless there's some free()s being done somewhere where I haven't noticed. > I think the non-opacity of vnodes is a mistake. I guess they didn't have time to get this aspect right. Some of the semantics are very interesting though, they look very different from the SysV vnodes I read about in the Vahalia book. Regards, Mike Hancock From owner-freebsd-current Tue Aug 27 00:49:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA22069 for current-outgoing; Tue, 27 Aug 1996 00:49:38 -0700 (PDT) Received: from ns.eu.org (valerian.glou.eu.org [193.56.58.251]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA22064 for ; Tue, 27 Aug 1996 00:49:33 -0700 (PDT) Received: (from uucp@localhost) by ns.eu.org (8.7.3/8.7.1/951117) with UUCP id JAA23190 for current@freebsd.org; Tue, 27 Aug 1996 09:49:23 +0200 (MET DST) Received: (from regnauld@localhost) by tetard.glou.eu.org (8.7.5/8.7.3/tetard-uucp-2.7) id JAA09113 for current@freebsd.org; Tue, 27 Aug 1996 09:01:37 +0200 (MET DST) From: Philippe Regnauld Message-Id: <199608270701.JAA09113@tetard.glou.eu.org> Subject: Re: current-digest V1 #566 To: current@freebsd.org (current) Date: Tue, 27 Aug 1996 09:01:36 +0200 (MET DST) In-Reply-To: <199608262116.PAA22453@clem.systemsix.com> from Steve Passe at "Aug 26, 96 03:16:10 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe écrit / writes: > Steve's golden rule for buying disk cases: > > find the case you like and buy it. > throw away the fan, it will be junk. > buy a GOOD, BRAND-NAME, ball-bearing fan > from digikey or other reliable parts house Yes. Too many fans out there are some El Cheapo with ovoid bearings. Same for CPU fans : fan mechanisms are NOT designed to be directly in contact with intenseley variating heat sources. Guess why those $10 coolers end up sounding like dying yorkshires... Real, direct surface contact fans are way more than $10. > other hints: > > if the front panel is removable, REMOVE IT, Uh, not necessarily - what you want to achieve is maximum air-flow, not maximum exposition : the drives in my machine are hotter when the cover is off. > it may look ugly, but free air will flow directly across top of drive Not if proper ventilation is in effect -- the more open the space, the more air-flow you need. -- Phil -- -[ Philippe Regnauld / regnauld@eu.org / +55.4N +11.3E @ Sol3 / +45 31241690 ]- -[ "To kärve or nøt to kärve, that is the qvestion..." -- My sister ]- From owner-freebsd-current Tue Aug 27 01:08:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA23053 for current-outgoing; Tue, 27 Aug 1996 01:08:25 -0700 (PDT) Received: from render.gu.kiev.ua (render.gu.kiev.ua [193.124.51.65]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA23034 for ; Tue, 27 Aug 1996 01:07:55 -0700 (PDT) Received: from creator.gu.kiev.ua (root@creator.gu.kiev.ua [193.124.51.73]) by render.gu.kiev.ua with ESMTP id KAA20128; Tue, 27 Aug 1996 10:46:25 +0300 Received: (from stesin@localhost) by creator.gu.kiev.ua id KAA20433; Tue, 27 Aug 1996 10:44:13 +0300 From: Andrew Stesin Message-Id: <199608270744.KAA20433@creator.gu.kiev.ua> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: angio@aros.net (Dave Andersen) Date: Tue, 27 Aug 1996 10:44:12 +0300 (EET DST) Cc: squid-users@nlanr.net, current@freebsd.org Reply-To: stesin@gu.kiev.ua In-Reply-To: <199608262251.QAA07775@terra.aros.net> from "Dave Andersen" at Aug 26, 96 04:51:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, As a result of a pre-2.1.5-release discussion, I was under impression that libmalloc in FreeBSD-2.1.5 was going to be a "libPHKmalloc" really, with old libmalloc going elsewhere. >From your message I got an impression that I was wrong. :( As for me, I strongly suggest using phkmalloc with Squid on any platform. Or gnumalloc at least. Default (standard?) BSD malloc isn't usable. Yours -- Andrew Stesin | | As an interesting point to note: | | Recompiling squid with*out* -lmalloc and using phkmalloc (malloc from | -current) resulted in squid stabalizing, after about 13 hours of moderate | to light use (1 hit/second) at 21M used. With the standard malloc and | linking against -lmalloc, this usage was at about 35M under the same load | after the same period of time. | | If someone's developing a FAQ, the above may wish to be a part of it. | :) (Or mail me, and I'll send you a better formatted entry). | | Has anyone tried changing the configure script to _not_ link to | -lmalloc under stock 2.1.5? I'd be curious about the results. My guess | is that linking against the now-antiquated libmalloc causes squid to | waste memory like there's no tomorrow, even when not using phkmalloc. | | -Dave Andersen | | -- | angio@aros.net Complete virtual hosting and business-oriented | system administration Internet services. (WWW, FTP, email) | http://www.aros.net/ http://www.aros.net/about/virtual | "There are only two industries that refer to their customers as 'users'." | -- nic-hdl: ST73-RIPE From owner-freebsd-current Tue Aug 27 02:39:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA26203 for current-outgoing; Tue, 27 Aug 1996 02:39:29 -0700 (PDT) Received: from terra.stack.urc.tue.nl (terra.stack.urc.tue.nl [131.155.140.128]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA26197 for ; Tue, 27 Aug 1996 02:39:25 -0700 (PDT) Received: from xaa.stack.urc.tue.nl (uucp@localhost) by terra.stack.urc.tue.nl (8.7.5) with UUCP id LAA20471 for freebsd-current@freebsd.org; Tue, 27 Aug 1996 11:39:20 +0200 (MET DST) Received: (from xaa@localhost) by xaa.stack.urc.tue.nl (8.7.5/8.6.12) id LAA00388 for freebsd-current@freebsd.org; Tue, 27 Aug 1996 11:38:45 +0200 (MET DST) From: Mark Huizer Message-Id: <199608270938.LAA00388@xaa.stack.urc.tue.nl> Subject: Machine getting slow at CTM-2136 To: freebsd-current@freebsd.org Date: Tue, 27 Aug 1996 11:38:45 +0200 (MET DST) Reply-To: xaa@stack.urc.tue.nl X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmm.... just recompiled my kernel after the current-CTM 2136 got in, rebooted, and everything was running at Win NT speed :-) Well, it was just slow, the load and all showed little activity and the /etc/rc stuff took about 5 to 6 times longer than normal :-( Mark ------------------------------------------------------------------------- - Mark Huizer - xaa@stack.urc.tue.nl - huizer@circlesoft.nl - ------------------------------------------------------------------------- - Cogito ergo boom (S. Sontag) - ------------------------------------------------------------------------- From owner-freebsd-current Tue Aug 27 06:14:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA04532 for current-outgoing; Tue, 27 Aug 1996 06:14:00 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-140.ut.nl.ibm.net [139.92.42.140]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA04526; Tue, 27 Aug 1996 06:13:53 -0700 (PDT) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id OAA19329; Tue, 27 Aug 1996 14:46:55 +0200 (MET DST) Message-Id: <199608271246.OAA19329@vector.jhs.no_domain> To: roberto@keltia.freenix.fr (Ollivier Robert) cc: current@FreeBSD.org Subject: Re: libmd.so.2.0 From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Address: Holz Strasse 27d, 80469 Munich, Germany Phone: +49.89.268616 Fax: +49.89.2608126 Web: http://www.freebsd.org/~jhs/ Mailer: EXMH 1.6.7, PGP available In-reply-to: Your message of "Tue, 20 Aug 1996 22:56:52 +0200." <199608202056.WAA27164@keltia.freenix.fr> Date: Tue, 27 Aug 1996 14:46:52 +0200 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: roberto@keltia.freenix.fr (Ollivier Robert) > According to Julian H. Stacey: > > Is libmd.so.2.0 not being installed, a bug ? > If you have a libmd.so or need one, you have a big problem: > ------------------------------------------------------------ > phk 94/09/18 00:22:09 > ^^^^^^^^ > Modified: lib/libmd Makefile > Log: > libmd no longer built as shared-lib, only static. > Renamed the beforeinstall to test. > ------------------------------------------------------------ > This was even _before_ 2.0 if I have the date right. > > PS I noticed libcompat.so.2.0 was missing on my host `gate' too. > Same for libcompat. > ------------------------------------------------------------ > nate 95/02/20 10:19:52 > ^^^^^^^^ > Modified: lib/libcompat Makefile > Log: > Make libcompat a static only library. > Since functions will come and go from libcompat as they are deprecated > it makes no sense to build a shared library out of it as it will change. > Based on freedback from Terry and Jonas on the mailing lists. > ------------------------------------------------------------ > You have either a garbled /usr/src or some very old binaries... Ollivier, Thanks for telling me libmd.so & libcompat.so were obsolete, it helped :-) Your 2nd guess was right: some of my binaries from a previous 2.something release (stamp is Nov 15 1995) were not overlayed by an over-the-local-net install, because of a problem with _collate_range_cmp & locale.h, on my current box, which prevented these compiling: csh sh awk grep sort tar fetch strfile so I'm doing a make world. Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Tue Aug 27 06:20:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA04969 for current-outgoing; Tue, 27 Aug 1996 06:20:07 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-140.ut.nl.ibm.net [139.92.42.140]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA04895; Tue, 27 Aug 1996 06:19:56 -0700 (PDT) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id QAA16855; Mon, 26 Aug 1996 16:57:44 +0200 (MET DST) Message-Id: <199608261457.QAA16855@vector.jhs.no_domain> To: Terry Lambert cc: jkh@time.cdrom.com (Jordan K. Hubbard), nirva@ishiboo.com, freebsd-current@FreeBSD.org Subject: Re: -current kills harddrives From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Address: Holz Strasse 27d, 80469 Munich, Germany Phone: +49.89.268616 Fax: +49.89.2608126 Web: http://www.freebsd.org/~jhs/ Mailer: EXMH 1.6.7, PGP available In-reply-to: Your message of "Fri, 23 Aug 1996 10:06:10 PDT." <199608231706.KAA16028@phaeton.artisoft.com> Date: Mon, 26 Aug 1996 16:57:43 +0200 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: Terry Lambert > > > > Here's my situation, 2 perfectly happy HDs, both SCSI-II, were > > > working great for months. > > > > I seriously doubt that -current is killing your hard drives. > > Some things you just can't do from software, even if you wanted > > to. > > Do you have a Commodore CBM 8032? > > I have three pokes to sell you... & then there's the "branch to {relative to current offset}: 0" that could kill real core store 'cos of the non cycling on the scan lines, & the assumed duty factors :-) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Tue Aug 27 08:59:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA11426 for current-outgoing; Tue, 27 Aug 1996 08:59:32 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA11358; Tue, 27 Aug 1996 08:56:34 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id IAA24710; Tue, 27 Aug 1996 08:45:33 -0700 From: Terry Lambert Message-Id: <199608271545.IAA24710@phaeton.artisoft.com> Subject: Re: vclean (was The VIVA file system) To: michaelh@cet.co.jp Date: Tue, 27 Aug 1996 08:45:33 -0700 (MST) Cc: terry@lambert.org, eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Aug 27, 96 12:35:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I think what needs to be looked at is having more synchronized buffer > > > cache/vnode recycling policies. > > > > Inode data, disklabel data, and any other FS object which is not file > > contents is not cached under the current policy. > > The vnode/inode association with a vnhash() you mentioned before makes > sense. I wonder how hard it would be to manage the buffer > cache/vnodes/inodes with more synergy (sorry I couldn't think of a better > word). You're forgiven... you just need to get with the new "paradigm". 8-) 8-). > > Further, dissociating buffers from vnodes does not require that they > > be returned to a global pool for clean-behind. > > There's an in-place free list that can have valid buffers hanging off of > them and vnodes go on the list when inactive() is called. I guess the > freelist should be called the inactive list. > > getnewvnode() > vgone() > vclean() should only be called when it needs to, such as when > file activity moves to a different fs and there aren't enough vnodes. > > The vnode pool was a fixed size pool in lite, but someone put in a > malloc() into getnewvnode(). The vnode pool is kind of wired so I think > it can now grow, but it can't shrink unless there's some free()s being > done somewhere where I haven't noticed. Yes. The number one problem is that the in-place freelist with valid buffers hanging off of them is not recoverable once the inode data has been disassociated. The vnode is effectively unrecoverable without the buffers being freed. This is very annoying; at the very least, going the other direction, where the vnode is treated as an opaque handle external to the VFS itself instead of as a common "subsystem" in kern/, would allow the buffers to be recovered via the ihash. This is, in fact, the wrong thing to do, since it would require the implementation of an ihash per FS. Better to consider name cache references in the directory lookup cache as if they were vnode references, and push the vnodes into a per FS pool, LRU'ing the shared references out of the name cache. This would result in recoverability for the buffers, at the same time removing the annoying race conditions that sow up every time the VM system is tweaked as "free vnode isn't" or other such crap. The vnode management as it stands is much too fragile. > > I think the non-opacity of vnodes is a mistake. > > I guess they didn't have time to get this aspect right. > > Some of the semantics are very interesting though, they look very > different from the SysV vnodes I read about in the Vahalia book. Yes; there is no reason to lose that going to a per FS vrelease; the most interesting semantic is stacking. I don't think that right now there is a guard against unmounting with a reference active if the data reference to the FS from the vnode is not asserted. This seems to be a problem for a couple of FS's that operate on the basis of virtual nodes (I don't know if devfs is implicated for sure yet; I'm still looking at that panic). For what it's worth, the vnode problems all seem to be related to lack of data abstraction -- promiscuous use of vnode data, etc. -- and that is not impossible to clean up, just time consuming. 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 Aug 27 10:09:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA15509 for current-outgoing; Tue, 27 Aug 1996 10:09:32 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA15504 for ; Tue, 27 Aug 1996 10:09:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA24972; Tue, 27 Aug 1996 09:53:42 -0700 From: Terry Lambert Message-Id: <199608271653.JAA24972@phaeton.artisoft.com> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: stesin@gu.kiev.ua Date: Tue, 27 Aug 1996 09:53:42 -0700 (MST) Cc: angio@aros.net, squid-users@nlanr.net, current@FreeBSD.org In-Reply-To: <199608270744.KAA20433@creator.gu.kiev.ua> from "Andrew Stesin" at Aug 27, 96 10:44:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As a result of a pre-2.1.5-release discussion, > I was under impression that libmalloc in FreeBSD-2.1.5 was going > to be a "libPHKmalloc" really, with old libmalloc going elsewhere. > From your message I got an impression that I was wrong. :( > > As for me, I strongly suggest using phkmalloc with Squid > on any platform. Or gnumalloc at least. Default (standard?) > BSD malloc isn't usable. More on this topic... I would like to see the use of an mmap() of /dev/zero replace the use of sbrk() in malloc. For one thing, it would allow us to seperate allocation by thread by establishing sparse allocation zones in the overall process address space. Secondly, the sbrk()-based system recovery of memory assumes too much allocation locality: the recovery of memory (via sbrk() back to the system) can only occur at the end of the allocation region. I would like to see an extention to the mmap() semantics for sparse reclaimation on a per-page basis: When a full page is no longer on use, it would be returned individually to the system. This would resolve the internal heap fragmentation issues of the X server, and of other programs, which do not use a persistance-based locality of allocation model (despite my squawking on the subject, I have only ever seen one persistance-based model implemented without using x86 segment identifiers, and since it was a commercial product, it's unlikely that the code will ever come into common use). Extending the mmap() semantics for page reclaimation also suggests that a "back fill" mechanism will be needed to avoid internal fragmentation (probably not a real problem unless the process normally uses a significant fraction of its available virtual address space). Finally, in the "as long as you're in there" category, it seems that it would be a good idea to support the extension of a mapping region without first unmapping -- a "remmap" in the "realloc" style, if you will. Combining this last with "file size extension" as an FS event to internally cause the mapping to change, at least up to the next page boundry (which has to be mapped anyway because of the VM system's page granularity), should resolve the INN mmap/extension 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 Tue Aug 27 10:28:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16523 for current-outgoing; Tue, 27 Aug 1996 10:28:13 -0700 (PDT) Received: from terra.stack.urc.tue.nl (terra.stack.urc.tue.nl [131.155.140.128]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA16517 for ; Tue, 27 Aug 1996 10:28:10 -0700 (PDT) Received: from alterego.stack.urc.tue.nl (xaa@alterego.stack.urc.tue.nl [131.155.141.160]) by terra.stack.urc.tue.nl (8.7.5) with ESMTP id TAA27677 for ; Tue, 27 Aug 1996 19:28:07 +0200 (MET DST) Received: (from xaa@localhost) by alterego.stack.urc.tue.nl (8.7.5/8.6.12) id TAA10731 for freebsd-current@freebsd.org; Tue, 27 Aug 1996 19:28:04 +0200 (MET DST) From: Mark Huizer Message-Id: <199608271728.TAA10731@alterego.stack.urc.tue.nl> Subject: pthreads / libc_r To: freebsd-current@freebsd.org Date: Tue, 27 Aug 1996 19:28:04 +0200 (MET DST) Reply-To: xaa@stack.urc.tue.nl X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How up to date is this library? Yesterday I built myself a nice little libc_r, but I couldn't really use it since e.g. pthread_attr_init and others aren't exported in the resulting lib. Is this just an omission in /usr/src/lib/libc_r/uthread/Makefile.inc or what? Greetings, Mark ------------------------------------------------------------------------- - Mark Huizer - xaa@stack.urc.tue.nl - rcbamh@urc.tue.nl - ------------------------------------------------------------------------- - Monday is a hard way to spend one-seventh of your life - ------------------------------------------------------------------------- From owner-freebsd-current Tue Aug 27 10:44:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA17213 for current-outgoing; Tue, 27 Aug 1996 10:44:00 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA17189 for ; Tue, 27 Aug 1996 10:43:50 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id MAA00794; Tue, 27 Aug 1996 12:34:40 -0500 (EST) From: "John S. Dyson" Message-Id: <199608271734.MAA00794@dyson.iquest.net> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: terry@lambert.org (Terry Lambert) Date: Tue, 27 Aug 1996 12:34:40 -0500 (EST) Cc: stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@FreeBSD.org In-Reply-To: <199608271653.JAA24972@phaeton.artisoft.com> from "Terry Lambert" at Aug 27, 96 09:53:42 am Reply-To: dyson@FreeBSD.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Secondly, the sbrk()-based system recovery of memory assumes too > much allocation locality: the recovery of memory (via sbrk() back > to the system) can only occur at the end of the allocation region. > Actually, we have an madvise(2) in current that supports "freeing" pages, but keeping the VM space. That doesn't do EXACTLY what you say above, but it can help. I have been running with an augmented version of phkmalloc with that change for a long time now. > > I would like to see an extention to the mmap() semantics for sparse > reclaimation on a per-page basis: When a full page is no longer on > use, it would be returned individually to the system. > You can do an munmap that does not correspond directly to an mmap. Also, as I said above, we have an madvise(2) call (arg:MADV_FREE) that releases the page, without giving up the vm space. Specifically, the page is marked clean, and might/might-not be demand-zeroed the next time that you use it. John From owner-freebsd-current Tue Aug 27 11:03:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA18229 for current-outgoing; Tue, 27 Aug 1996 11:03:38 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA18222; Tue, 27 Aug 1996 11:03:32 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id UAA01058; Tue, 27 Aug 1996 20:02:58 +0200 (MET DST) To: Terry Lambert cc: stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@FreeBSD.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-reply-to: Your message of "Tue, 27 Aug 1996 09:53:42 PDT." <199608271653.JAA24972@phaeton.artisoft.com> Date: Tue, 27 Aug 1996 20:02:57 +0200 Message-ID: <1056.841168977@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <199608271653.JAA24972@phaeton.artisoft.com>, Terry Lambert writes: >> As a result of a pre-2.1.5-release discussion, >> I was under impression that libmalloc in FreeBSD-2.1.5 was going >> to be a "libPHKmalloc" really, with old libmalloc going elsewhere. >> From your message I got an impression that I was wrong. :( libmalloc is gone. >> As for me, I strongly suggest using phkmalloc with Squid >> on any platform. Or gnumalloc at least. Default (standard?) >> BSD malloc isn't usable. > >More on this topic... > >I would like to see the use of an mmap() of /dev/zero replace the >use of sbrk() in malloc. For one thing, it would allow us to >seperate allocation by thread by establishing sparse allocation >zones in the overall process address space. Been there, done that. sbrk() is about 5..10 times faster, probably because it knows much more at the onset than mmap does. And by the way, you can munmap pages you got with sbrk as far as I know :-) >Secondly, the sbrk()-based system recovery of memory assumes too >much allocation locality: the recovery of memory (via sbrk() back >to the system) can only occur at the end of the allocation region. Well, I'm playing with an neat little hack, which I can send you a diff for if you want, (all of one line :-) that uses madvise to tell the kernel that the contents of free pages can be thrown away, and a dmz be done on next access. This potentially saves a pageout and a pagein, possibly more, if you have plenty of ram, nothing. It's cheaper than to unmap, but still a little to expensive if done conseqently. The trick would be to have the kernel tell the processes when it's low on memory, which leads to the Real Solution: Use madvise to keep an counter updated in the process structure "int pages_i_can_give_back" and use that as a criterion for sending a "SIGNOMEM" to processes when memory gets short. This signal is used to ask the process to kindly mark anything it doesn't use as unused with madvise or free it. I've tried this, it's very easy, and very little code, but I never got to the signal sending stuff because it was rather obvious that none of my test-systems would benefit significantly, and consequently, the added complexity was not worth it. If you have a system that pages out a lot, you would gain something, but who has that ? Not me. RAM is cheaper than frying disks by swapping heavily. And that brings me to the conclusion: Only if you are paging a lot can you really gain something by avoiding paging pages out that nobody loves the contents of. If your paging rate is low, there is not much to be gained anywhere. I guess that the pragmatic solution would be to add a couple of options to MALLOC_OPTIONS and leave the matter of policy in the hands of the local sysad. Except of course that you can't set it system-wide in any meaningfull way at present. I have thought about adding a global default to malloc (/etc/default/malloc) to solve that problem. Comments ? Anybody wants to test the code ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Aug 27 11:43:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20268 for current-outgoing; Tue, 27 Aug 1996 11:43:10 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA20260; Tue, 27 Aug 1996 11:43:04 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id UAA06174; Tue, 27 Aug 1996 20:42:47 +0200 (MET DST) cc: Terry Lambert , stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@FreeBSD.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-reply-to: Your message of "Tue, 27 Aug 1996 20:02:57 +0200." <1056.841168977@critter.tfs.com> Date: Tue, 27 Aug 1996 20:42:47 +0200 Message-ID: <6172.841171367@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Here, try these changes, and see if it makes a difference when you set 'H' or one or more '<' or '>' in the options. You can do it system wide: ln -s 'H<<' /etc/default/malloc or per process: setenv MALLOC_OPTIONS 'H<<' Feedback most welcome! Poul-Henning Index: malloc.3 =================================================================== RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.3,v retrieving revision 1.5 diff -u -r1.5 malloc.3 --- malloc.3 1996/02/11 22:34:02 1.5 +++ malloc.3 1996/08/27 18:37:24 @@ -34,10 +34,11 @@ .\" SUCH DAMAGE. .\" .\" @(#)malloc.3 8.1 (Berkeley) 6/4/93 +.\" $Id$ .\" -.Dd June 4, 1993 +.Dd August 27, 1996 .Dt MALLOC 3 -.Os BSD 4 +.Os FreeBSD 2 .Sh NAME .Nm malloc , .Nd general memory allocation function @@ -112,9 +113,11 @@ .Pp .Sh ENVIRONMENT -This malloc will check the environment for a variable called -.Em MALLOC_OPTIONS -and scan it for flags. +Malloc will first look for a symbolic link called +.Pa /etc/default/malloc +and next check the environment for a variable called +.Ev MALLOC_OPTIONS +and scan them for flags in that order. Flags are single letters, uppercase means on, lowercase means off. .Bl -tag -width indent .It A @@ -130,6 +133,10 @@ ``junk'' fill some junk into the area allocated. Currently junk is bytes of 0xd0, this is pronounced ``Duh'' :-) +.It H +``hint'' pass a hint to the kernel about pages we don't use. If the +machine is paging a lot this may help a bit. + .It R ``realloc'' always reallocate when .Fn realloc @@ -140,11 +147,22 @@ ``zero'' fill some junk into the area allocated (see ``J''), except for the exact length the user asked for, which is zeroed. +.It < +``Half the cache size'' Reduce the size of the cache by a factor of two. + +.It > +``Double the cache size'' Double the size of the cache by a factor of two. .El .Pp +So to set a systemwide reduction of cache size and coredumps on problems +one would: +.Li ln -s 'A<' /etc/default/malloc +.Pp The ``J'' and ``Z'' is mostly for testing and debugging, if a program changes behavior if either of these options are used, it is buggy. +.Pp +The default cache size is 32 pages. .Sh RETURN VALUES The .Fn malloc @@ -166,6 +184,7 @@ .Xr calloc 3 , .Xr getpagesize 3 , .Xr memory 3 +.Pa /usr/share/doc/papers/malloc.ascii.gz .Sh STANDARDS The .Fn malloc Index: malloc.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.c,v retrieving revision 1.11 diff -u -r1.11 malloc.c --- malloc.c 1996/07/03 05:03:07 1.11 +++ malloc.c 1996/08/27 18:25:10 @@ -188,9 +188,7 @@ /* * The minimum size (in bytes) of the free page cache. */ -#ifndef malloc_cache -static unsigned malloc_cache; -#endif /* malloc_cache */ +static unsigned malloc_cache = 32 << malloc_pageshift; /* * The offset from pagenumber to index into the page directory @@ -241,6 +239,11 @@ static int malloc_realloc; /* + * pass the kernel a hint on free pages ? + */ +static int malloc_hint; + +/* * zero fill ? */ static int malloc_zero; @@ -496,30 +499,46 @@ static void malloc_init () { - char *p; + char *p, b[64]; + int i,j; #ifdef EXTRA_SANITY malloc_junk = 1; #endif /* EXTRA_SANITY */ - for (p=getenv("MALLOC_OPTIONS"); p && *p; p++) { - switch (*p) { - case 'a': malloc_abort = 0; break; - case 'A': malloc_abort = 1; break; + for (i = 0; i < 2; i++) { + if (i == 0) { + j = readlink("/etc/default/malloc", b, sizeof b - 1); + if (j <= 0) + continue; + b[j] = '\0'; + p = b; + } else if (i == 1) { + p = getenv("MALLOC_OPTIONS"); + } + for (; p && *p; p++) { + switch (*p) { + case '>': malloc_cache <<= 1; break; + case '<': malloc_cache >>= 1; break; + case 'a': malloc_abort = 0; break; + case 'A': malloc_abort = 1; break; #ifdef MALLOC_STATS - case 'd': malloc_stats = 0; break; - case 'D': malloc_stats = 1; break; + case 'd': malloc_stats = 0; break; + case 'D': malloc_stats = 1; break; #endif /* MALLOC_STATS */ - case 'r': malloc_realloc = 0; break; - case 'R': malloc_realloc = 1; break; - case 'j': malloc_junk = 0; break; - case 'J': malloc_junk = 1; break; - case 'z': malloc_zero = 0; break; - case 'Z': malloc_zero = 1; break; - default: - wrtwarning("(Init): Unknown char in MALLOC_OPTIONS\n"); - p = 0; - break; + case 'h': malloc_hint = 0; break; + case 'H': malloc_hint = 1; break; + case 'r': malloc_realloc = 0; break; + case 'R': malloc_realloc = 1; break; + case 'j': malloc_junk = 0; break; + case 'J': malloc_junk = 1; break; + case 'z': malloc_zero = 0; break; + case 'Z': malloc_zero = 1; break; + default: + wrtwarning("(Init): Unknown char in MALLOC_OPTIONS\n"); + p = 0; + break; + } } } @@ -553,10 +572,6 @@ } #endif /* malloc_pageshift */ -#ifndef malloc_cache - malloc_cache = 100 << malloc_pageshift; -#endif /* malloc_cache */ - #ifndef malloc_minsize { int i; @@ -967,6 +982,9 @@ page_dir[index + i] = MALLOC_FREE; l = i << malloc_pageshift; + + if (malloc_hint) + madvise(ptr, l, MADV_FREE); tail = ptr+l; -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Aug 27 12:50:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24988 for current-outgoing; Tue, 27 Aug 1996 12:50:37 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA24983; Tue, 27 Aug 1996 12:50:35 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.6.12/8.6.12) with SMTP id MAA05059; Tue, 27 Aug 1996 12:50:26 -0700 Date: Tue, 27 Aug 1996 12:50:26 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org, current@freebsd.org Subject: Jaz really work? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I could've sworn I saw somebody say on this list that the IOMEGA Jaz drive drops right in and goes. So I went and bought one. I can't get it to work. It always says the drive is write protected. There's numerous errors about mode sense (4), and some other goop. P6-200, Adaptec 2940, -current as of 8/26, 2 4GB Barracuda, 1 Fuji 4GB disk, Toshiba CDROM, JAZ drive. The Jaz is the only external device, but I've mucked with all kinds of termination settings, and nothing seems to help. So the question is, is anybody actually using this drive with FreeBSD-current? From owner-freebsd-current Tue Aug 27 13:30:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA27853 for current-outgoing; Tue, 27 Aug 1996 13:30:50 -0700 (PDT) Received: from sumter.awod.com (awod.com [198.81.225.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA27847; Tue, 27 Aug 1996 13:30:46 -0700 (PDT) Received: from tsunami.awod.com (chs0184.awod.com [206.31.146.184]) by sumter.awod.com (8.6.12/8.6.12) with SMTP id QAA16093; Tue, 27 Aug 1996 16:30:41 -0400 Message-Id: <1.5.4.32.19960827203043.0091dd20@awod.com> X-Sender: klam@awod.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 1996 16:30:43 -0400 To: Jaye Mathisen , hackers@freebsd.org, current@freebsd.org From: Ken Lam Subject: Re: Jaz really work? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:50 PM 8/27/96 -0700, Jaye Mathisen wrote: > > >I could've sworn I saw somebody say on this list that the IOMEGA Jaz drive >drops right in and goes. Well, yes. Once you have disabled the write protection of the Jazz drive, I assume that you are using the tools cartdrige? You need to do their software install and run reclaim to delete the mac or pc "partition" and un-write protect it. This is a iomega "software" protection built into the drive. >So I went and bought one. I love mine, fast, quiet, .... maybe I'll just get 6 more and eliminate all my drives :) >I can't get it to work. It always says the drive is write protected. >There's numerous errors about mode sense (4), and some other goop. No problem with mode sense, it just isn't reporting a valid disk geometry, but should still work fine since it correctly reports the valid number of sectors. I've used mine on 2.1, 2.1.5, 2.2-Current and 8-XX SNAP. It is just another scsi drive, although you want it as a higher scsi ID than your CDROM during installation b/c otherwise during package or ports install, the system tried to mount that as the cdrom to install from. I'm assuming that FBSD tries using the first removable device as the CDROM from sysinstall? >P6-200, Adaptec 2940, -current as of 8/26, 2 4GB Barracuda, 1 Fuji 4GB >disk, Toshiba CDROM, JAZ drive. Will trade with you :) -Ken --- Ken Lam lam@awod.com Integrated Technical Systems Systems, Networks, and Internet Solutions -- Defining Technology Today "'Plug and Play' was only applicable to the original ATARI(tm)" From owner-freebsd-current Tue Aug 27 13:38:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA28398 for current-outgoing; Tue, 27 Aug 1996 13:38:51 -0700 (PDT) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA28391 for ; Tue, 27 Aug 1996 13:38:46 -0700 (PDT) Received: (from henrich@localhost) by crh.cl.msu.edu (8.7.5/8.7.3) id QAA20256; Tue, 27 Aug 1996 16:38:40 -0400 (EDT) Date: Tue, 27 Aug 1996 16:38:40 -0400 (EDT) From: Charles Henrich Message-Id: <199608272038.QAA20256@crh.cl.msu.edu> To: mrcpu@cdsnet.net, freebsd-current@freebsd.org Subject: Re: Jaz really work? Newsgroups: lists.freebsd.current References: <4vvktp$1d8p@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.current you write: >I could've sworn I saw somebody say on this list that the IOMEGA Jaz drive >drops right in and goes. >So I went and bought one. >I can't get it to work. It always says the drive is write protected. >There's numerous errors about mode sense (4), and some other goop. >P6-200, Adaptec 2940, -current as of 8/26, 2 4GB Barracuda, 1 Fuji 4GB >disk, Toshiba CDROM, JAZ drive. >The Jaz is the only external device, but I've mucked with all kinds of >termination settings, and nothing seems to help. >So the question is, is anybody actually using this drive with >FreeBSD-current? Im using a Jaz internel on a 960801-SNAP just peachy. It whines about geometry on boot then makes one up for it. Peachy. Havent seen the write protect message, HOWEVER, I know that via some magic you can tell a cart its write protected, this is done in software as far as I know. Perhaps it writes something to the media. In any case I've not overwritten my tools disk, instead im using additional carts I've purchased. It works, but not great. The problems: On a mount the platter must be spinning else you get a panic Once its mounted your in great shape from then on, whenever you touch the drive it will spin up as it should. To change a cart is problematic, you unmount the sucker, slap in a new one, and then mount it (Again wait until it has spun up). Again the system panics. The good news of this is, whenever you get a panic, you can just hop over to the debugger and type "continue" at which point FreeBSD will happily complete the operation that caused the panic, and your in good shape. Just remember to drop to a non-X virtual terminal before doing any ops that require a continue :) -- Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-current Tue Aug 27 16:37:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA09479 for current-outgoing; Tue, 27 Aug 1996 16:37:34 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA09470; Tue, 27 Aug 1996 16:37:30 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id XAA25859; Tue, 27 Aug 1996 23:37:13 GMT Date: Wed, 28 Aug 1996 08:37:13 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: vclean (was The VIVA file system) In-Reply-To: <199608271545.IAA24710@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 Aug 1996, Terry Lambert wrote: > Yes. The number one problem is that the in-place freelist with valid > buffers hanging off of them is not recoverable once the inode data has > been disassociated. The vnode is effectively unrecoverable without > the buffers being freed. > This was the point I was missing. What is disassociating the inode and when is it happening? Regards, Mike From owner-freebsd-current Tue Aug 27 19:26:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA17193 for current-outgoing; Tue, 27 Aug 1996 19:26:11 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA17187 for ; Tue, 27 Aug 1996 19:26:06 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id TAA02330; Tue, 27 Aug 1996 19:23:51 -0700 (PDT) To: Poul-Henning Kamp cc: Terry Lambert , stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@FreeBSD.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-reply-to: Your message of "Tue, 27 Aug 1996 20:42:47 +0200." <6172.841171367@critter.tfs.com> Date: Tue, 27 Aug 1996 19:23:51 -0700 Message-ID: <2328.841199031@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Here, try these changes, and see if it makes a difference when > you set 'H' or one or more '<' or '>' in the options. > > You can do it system wide: > ln -s 'H<<' /etc/default/malloc Aieee! Another file in /etc! sysctl! sysctl! :-) Jordan From owner-freebsd-current Tue Aug 27 20:33:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA21346 for current-outgoing; Tue, 27 Aug 1996 20:33:32 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA21331 for ; Tue, 27 Aug 1996 20:33:25 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA10965; Wed, 28 Aug 1996 12:59:41 +0930 From: Michael Smith Message-Id: <199608280329.MAA10965@genesis.atrad.adelaide.edu.au> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 28 Aug 1996 12:59:41 +0930 (CST) Cc: phk@critter.tfs.com, terry@lambert.org, stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@freebsd.org In-Reply-To: <2328.841199031@time.cdrom.com> from "Jordan K. Hubbard" at Aug 27, 96 07:23:51 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > > > You can do it system wide: > > ln -s 'H<<' /etc/default/malloc > > Aieee! Another file in /etc! sysctl! sysctl! :-) Time to take Terry up on his logicals concept. Anyone familiar enough with the way that VMS handles/d these willing to talk for a while on it? I seem to recall that you could create logicals on a system-wide basis as well as per-session (or was that per-user?) There should be a way to integrate this with sysctl so that what are currently sysctl variables become system-wide logicals with little or no effective change, but the concept is extended to per-process group (kinda like the environment), or summat similar. > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Aug 28 00:03:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA06892 for current-outgoing; Wed, 28 Aug 1996 00:03:02 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA06881 for ; Wed, 28 Aug 1996 00:03:00 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id XAA03558; Tue, 27 Aug 1996 23:59:52 -0700 (PDT) To: Michael Smith cc: phk@critter.tfs.com, terry@lambert.org, stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@freebsd.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-reply-to: Your message of "Wed, 28 Aug 1996 12:59:41 +0930." <199608280329.MAA10965@genesis.atrad.adelaide.edu.au> Date: Tue, 27 Aug 1996 23:59:52 -0700 Message-ID: <3556.841215592@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Time to take Terry up on his logicals concept. Anyone familiar enough with > the way that VMS handles/d these willing to talk for a while on it? I > seem to recall that you could create logicals on a system-wide basis as > well as per-session (or was that per-user?) My VMS memories are somewhat weak (I helped this happen through liberal ingestion of alcohol after I did my 2 year sentence in VMS hacking - FABs and RABs and XABS, oh my! I still sometimes wake up sweating), but I'd think that a UNIX equivalent would want 3 different levels of hierarchy: system, user, process (in that order). I think that the user variables would be especially interesting in the kinds of things you could do with them. Then you'd want to teach namei() about them for those, nudge nudge, variant symlinks! :-) Jordan From owner-freebsd-current Wed Aug 28 00:39:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA09311 for current-outgoing; Wed, 28 Aug 1996 00:39:51 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA09303 for ; Wed, 28 Aug 1996 00:39:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id AAA18958; Wed, 28 Aug 1996 00:36:36 -0700 (PDT) Message-Id: <199608280736.AAA18958@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@freebsd.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-reply-to: Your message of "Wed, 28 Aug 1996 12:59:41 +0930." <199608280329.MAA10965@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Wed, 28 Aug 1996 00:36:36 -0700 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Jordan K. Hubbard stands accused of saying: >> > >> > You can do it system wide: >> > ln -s 'H<<' /etc/default/malloc >> >> Aieee! Another file in /etc! sysctl! sysctl! :-) > >Time to take Terry up on his logicals concept. Anyone familiar enough with >the way that VMS handles/d these willing to talk for a while on it? I have about 10 years of experiance with VMS. I used to have a small VAXcluster here prior to switching my machines to Ultrix (and then later dumping the VAXes for PC's/386BSD). > I >seem to recall that you could create logicals on a system-wide basis as >well as per-session (or was that per-user?) Early versions of VMS had a simple {process, job, group, system} hierarchy. Later versions of VMS created a much more generic system that allowed for the creation of arbitrary logical name tables that allowed for custimized access/use. The old hierarchy was preserved using the new mechanism, however. Logical name tables have access permissions (system, owner, group, world) and individual entries have various flags which affect how the logical name is translated. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Wed Aug 28 02:01:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA13638 for current-outgoing; Wed, 28 Aug 1996 02:01:01 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA13623; Wed, 28 Aug 1996 02:00:55 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id JAA00764; Wed, 28 Aug 1996 09:27:36 +0200 (MET DST) To: Michael Smith cc: jkh@time.cdrom.com (Jordan K. Hubbard), terry@lambert.org, stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@freebsd.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-reply-to: Your message of "Wed, 28 Aug 1996 12:59:41 +0930." <199608280329.MAA10965@genesis.atrad.adelaide.edu.au> Date: Wed, 28 Aug 1996 09:27:36 +0200 Message-ID: <762.841217256@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199608280329.MAA10965@genesis.atrad.adelaide.edu.au>, Michael Smith writes: >Jordan K. Hubbard stands accused of saying: >> > >> > You can do it system wide: >> > ln -s 'H<<' /etc/default/malloc >> >> Aieee! Another file in /etc! sysctl! sysctl! :-) > >Time to take Terry up on his logicals concept. Anyone familiar enough with >the way that VMS handles/d these willing to talk for a while on it? I >seem to recall that you could create logicals on a system-wide basis as >well as per-session (or was that per-user?) > >There should be a way to integrate this with sysctl so that what are >currently sysctl variables become system-wide logicals with little or >no effective change, but the concept is extended to per-process group >(kinda like the environment), or summat similar. It's on it's way, I have a prototype "registry" on it's way, that would search, in order: process, session, uid, system trees for the variable. For now just live with the hack ok ? I havn't even committed this change to malloc, it's just for testing, OK ??? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Wed Aug 28 02:24:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA14648 for current-outgoing; Wed, 28 Aug 1996 02:24:51 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA14641 for ; Wed, 28 Aug 1996 02:24:47 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id SAA14146; Wed, 28 Aug 1996 18:49:28 +0930 From: Michael Smith Message-Id: <199608280919.SAA14146@genesis.atrad.adelaide.edu.au> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: dg@root.com Date: Wed, 28 Aug 1996 18:49:27 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@freebsd.org In-Reply-To: <199608280736.AAA18958@root.com> from "David Greenman" at Aug 28, 96 00:36:36 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman stands accused of saying: > > > I > >seem to recall that you could create logicals on a system-wide basis as > >well as per-session (or was that per-user?) > > Early versions of VMS had a simple {process, job, group, system} hierarchy. > Later versions of VMS created a much more generic system that allowed for > the creation of arbitrary logical name tables that allowed for custimized > access/use. The old hierarchy was preserved using the new mechanism, however. > Logical name tables have access permissions (system, owner, group, world) > and individual entries have various flags which affect how the logical name > is translated. What's the search order on logicals, or are the seperate spaces completely isolated? I have to look at phk's stuff I guess; for now doscmd gets most of my time, but this is a good one to think about while I'm drooling out documentation. Ramble ramble: - there are three sets of namespaces; the kernel namespace, process-group namespaces and process namespaces. - within at least the kernel namespace, seperate subspaces can be allocated (eg. for tunables, drivers, etc...) - init gets a default namespace (read from disk, perhaps?), which is the master inherited by other process groups, and thus other processes. This is perhaps bad; maybe when a process becomes a group leader it should inherit a default process-group namespace previously loaded into the kernel. What should happen to its process namespace? - a process' visible namespace is the result of overlapping its own namespace, that of its process group, and the kernel, with logicals capable of being marked such that they can't be occluded by the lower layers. (ie. the search order is process, group, kernel (or some kernel subspace?)). - logicals are byte arrays of arb. length (limits?), with textual names. Syntax? Nesting limits? Any thoughts, "I/we/they did it like this.."'s, would be educational... > David Greenman -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Aug 28 04:21:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA20269 for current-outgoing; Wed, 28 Aug 1996 04:21:20 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA20263; Wed, 28 Aug 1996 04:21:17 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id LAA00080; Wed, 28 Aug 1996 11:21:08 GMT Date: Wed, 28 Aug 1996 20:21:07 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: vclean (was The VIVA file system) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 28 Aug 1996, I wrote: > On Tue, 27 Aug 1996, Terry Lambert wrote: > > > Yes. The number one problem is that the in-place freelist with valid > > buffers hanging off of them is not recoverable once the inode data has > > been disassociated. The vnode is effectively unrecoverable without > > the buffers being freed. > > > > This was the point I was missing. What is disassociating the inode and > when is it happening? Yikes! I took a look below, but I didn't expect to see vgone() calls in ufs_inactive(). if (vp->v_usecount == 0 && ip->i_mode == 0) vgone(vp); I need to figure out what ip->i_mode == 0 means. Regards, Mike Hancock From owner-freebsd-current Wed Aug 28 05:23:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA22835 for current-outgoing; Wed, 28 Aug 1996 05:23:23 -0700 (PDT) Received: from hp.com (hp.com [15.255.152.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA22829 for ; Wed, 28 Aug 1996 05:23:21 -0700 (PDT) Received: from fakir.india.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA179584992; Wed, 28 Aug 1996 05:23:17 -0700 Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA255706824; Wed, 28 Aug 1996 17:53:44 +0500 Message-Id: <199608281253.AA255706824@fakir.india.hp.com> To: freebsd-current@freebsd.org Subject: punt RTM_LOSING without gateway? Date: Wed, 28 Aug 1996 17:53:44 +0500 From: A JOSEPH KOSHY Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm not terribly network aware so please pardon me if this is something basic: Over the past month I've seen messages like the following coming up occasionally (once in a few days) on the console: Aug 28 17:38:39 krill routed[46]: punt RTM_LOSING without gateway Aug 28 17:39:11 krill last message repeated 2 times This is followed at times by my rlogins/X connections freezing and timing out. This causes much grief :-(. Looks like something's hosing the network; however `ping' et al continue to work, and so do fresh rlogins. The only other anomalous message I see is : Aug 28 17:53:22 krill /kernel: arplookup 15.70.184.55 failed: host is not \ on local network Aug 28 17:53:38 krill routed[4856]: packet from unknown router 15.70.184.55\ or via unidentified interface This appears quite frequently but doesn't seem harmful. I'm running: FreeBSD 2.2-CURRENT #0: Thu Aug 22 16:23:28 IST 1996 root@krill.india.hp.com:/usr/src/sys/compile/KRILL Thanks, Koshy From owner-freebsd-current Wed Aug 28 05:50:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA24254 for current-outgoing; Wed, 28 Aug 1996 05:50:37 -0700 (PDT) Received: from iris.archimedia.khs-linz.ac.at (iris.archimedia.khs-linz.ac.at [193.170.99.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA24235 for ; Wed, 28 Aug 1996 05:50:18 -0700 (PDT) Received: by iris.archimedia.khs-linz.ac.at (940816.SGI.8.6.9/940406.SGI) for freebsd-current@freebsd.org id OAA04039; Wed, 28 Aug 1996 14:48:51 +0200 From: "Christian Gusenbauer" Message-Id: <9608281448.ZM4037@iris.archimedia.khs-linz.ac.at> Date: Wed, 28 Aug 1996 14:48:51 -0600 Reply-To: cg@www.archimedia.khs-linz.ac.at X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: freebsd-current@freebsd.org Subject: Problems with DEC DE205 cards Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! I just configured a PC as an Internet router. I'm using 2 DE205 cards put into a 486. Now, I can't get those cards working. The first card, which is initialized when booting works, the other one doesn't. If I disable the first card, the second works. I configured them as follows: device le0 at isa? port 0x220 net irq 15 iomem 0xe0000 vector le_intr device le1 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr What did I do wrong, or where's the bug? Isn't it possible to use 2 DE205 cards in one PC at the same time? Any clues? Thanks, Christian. -- --- DI. Christian Gusenbauer ARCHIMEDIA - HfG Linz, cg@www.archimedia.khs-linz.ac.at Hauptstr. 4, A-4040 Linz "It's easier to change the specification to fit the program than vice versa." From owner-freebsd-current Wed Aug 28 06:53:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA28207 for current-outgoing; Wed, 28 Aug 1996 06:53:53 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA28202 for ; Wed, 28 Aug 1996 06:53:51 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA11942; Wed, 28 Aug 1996 09:53:43 -0400 Date: Wed, 28 Aug 1996 09:53:43 -0400 From: Garrett Wollman Message-Id: <9608281353.AA11942@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: current@FreeBSD.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-Reply-To: <2328.841199031@time.cdrom.com> References: <6172.841171367@critter.tfs.com> <2328.841199031@time.cdrom.com> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk < said: > Aieee! Another file in /etc! sysctl! sysctl! :-) I don't see that this is an appropriate application of sysctl. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Wed Aug 28 07:04:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA28671 for current-outgoing; Wed, 28 Aug 1996 07:04:31 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA28666 for ; Wed, 28 Aug 1996 07:04:27 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA11859; Wed, 28 Aug 1996 10:04:01 -0400 Date: Wed, 28 Aug 1996 10:04:01 -0400 From: Garrett Wollman Message-Id: <9608281404.AA11859@halloran-eldar.lcs.mit.edu> To: Michael Smith Cc: current@freebsd.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-Reply-To: <199608280919.SAA14146@genesis.atrad.adelaide.edu.au> References: <199608280736.AAA18958@root.com> <199608280919.SAA14146@genesis.atrad.adelaide.edu.au> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > - there are three sets of namespaces; the kernel namespace, process-group > namespaces and process namespaces. > - within at least the kernel namespace, seperate subspaces can be allocated > (eg. for tunables, drivers, etc...) [more stuff deleted...] Oh, gawd, FreeBSD is being overrun by a crowd of VMS weenies! -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Wed Aug 28 07:08:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA28957 for current-outgoing; Wed, 28 Aug 1996 07:08:42 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA28947 for ; Wed, 28 Aug 1996 07:08:35 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id QAA02197 for ; Wed, 28 Aug 1996 16:03:43 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id QAA18510 for freebsd-current@freefall.cdrom.com; Wed, 28 Aug 1996 16:16:20 +0200 Date: Wed, 28 Aug 1996 16:16:20 +0200 From: Christoph Kukulies Message-Id: <199608281416.QAA18510@gilberto.physik.rwth-aachen.de> To: freebsd-current@freefall.FreeBSD.org Subject: _gdb_handle_exception Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk # make loading kernel db_interface.o: Undefined symbol `_gdb_handle_exception' referenced from text segment *** Error code 1 Stop. I have options DDB fyi. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Wed Aug 28 07:15:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA29309 for current-outgoing; Wed, 28 Aug 1996 07:15:28 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA29301 for ; Wed, 28 Aug 1996 07:15:24 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id XAA14897; Wed, 28 Aug 1996 23:45:06 +0930 From: Michael Smith Message-Id: <199608281415.XAA14897@genesis.atrad.adelaide.edu.au> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: wollman@lcs.mit.edu (Garrett Wollman) Date: Wed, 28 Aug 1996 23:45:06 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, current@freebsd.org In-Reply-To: <9608281404.AA11859@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Aug 28, 96 10:04:01 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman stands accused of saying: > [more stuff deleted...] > > Oh, gawd, FreeBSD is being overrun by a crowd of VMS weenies! I hope not 8) How would you do it? > -GAWollman -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Aug 28 07:26:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA29722 for current-outgoing; Wed, 28 Aug 1996 07:26:44 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA29717 for ; Wed, 28 Aug 1996 07:26:37 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id QAA02630 for ; Wed, 28 Aug 1996 16:21:50 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id QAA18578 for freebsd-current@freefall.cdrom.com; Wed, 28 Aug 1996 16:34:32 +0200 Date: Wed, 28 Aug 1996 16:34:32 +0200 From: Christoph Kukulies Message-Id: <199608281434.QAA18578@gilberto.physik.rwth-aachen.de> To: freebsd-current@freefall.FreeBSD.org Subject: Re: gdb_handle_exception Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk False alarm. Came from missing i386-gdbstub.c in my files.i386. Sorry. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Wed Aug 28 09:14:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA09978 for current-outgoing; Wed, 28 Aug 1996 09:14:13 -0700 (PDT) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA09960 for ; Wed, 28 Aug 1996 09:14:02 -0700 (PDT) Received: by sequent.kiae.su id AA06914 (5.65.kiae-2 for current@freebsd.org); Wed, 28 Aug 1996 20:12:15 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 28 Aug 96 20:12:14 +0400 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id UAA01568 for current@freebsd.org; Wed, 28 Aug 1996 20:11:40 +0400 (MSD) Message-Id: <199608281611.UAA01568@nagual.ru> Subject: Please add src-tools to supscan configuration To: current@freebsd.org (FreeBSD-current) Date: Wed, 28 Aug 1996 20:11:39 +0400 (MSD) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL25 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Because it is missing -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Wed Aug 28 09:57:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA13392 for current-outgoing; Wed, 28 Aug 1996 09:57:54 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA13383; Wed, 28 Aug 1996 09:57:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA26908; Wed, 28 Aug 1996 09:46:22 -0700 From: Terry Lambert Message-Id: <199608281646.JAA26908@phaeton.artisoft.com> Subject: Re: vclean (was The VIVA file system) To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 28 Aug 1996 09:46:22 -0700 (MST) Cc: terry@lambert.org, eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Aug 28, 96 08:37:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Yes. The number one problem is that the in-place freelist with valid > > buffers hanging off of them is not recoverable once the inode data has > > been disassociated. The vnode is effectively unrecoverable without > > the buffers being freed. > > This was the point I was missing. What is disassociating the inode and > when is it happening? vfs_subr.c: /* * Disassociate the underlying file system from a vnode. */ static void vclean(struct vnode *vp, int flags, struct proc *p) Any time vclean is called... 8-(. 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 Wed Aug 28 10:04:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA13788 for current-outgoing; Wed, 28 Aug 1996 10:04:39 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA13671; Wed, 28 Aug 1996 10:01:49 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA26928; Wed, 28 Aug 1996 09:50:18 -0700 From: Terry Lambert Message-Id: <199608281650.JAA26928@phaeton.artisoft.com> Subject: Re: vclean (was The VIVA file system) To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 28 Aug 1996 09:50:18 -0700 (MST) Cc: terry@lambert.org, eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Aug 28, 96 08:21:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This was the point I was missing. What is disassociating the inode and > > when is it happening? > > Yikes! I took a look below, but I didn't expect to see vgone() calls in > ufs_inactive(). > > if (vp->v_usecount == 0 && ip->i_mode == 0) > vgone(vp); > > I need to figure out what ip->i_mode == 0 means. The file type is a non-zero value in the high bits of the mode word; it means that the inode does not refer to real data any more. The vgone call is just part of the subsystem I think should be replaced wholesale; I'd like to see a per FS vrele() (back to locally managed pools) replace most of those calls. The vgone() calls vgone1() calls vclean, and we're back in my hate-zone. 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 Wed Aug 28 10:33:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA15625 for current-outgoing; Wed, 28 Aug 1996 10:33:47 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA15619; Wed, 28 Aug 1996 10:33:43 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id MAA00358; Wed, 28 Aug 1996 12:31:38 -0500 (EST) From: John Dyson Message-Id: <199608281731.MAA00358@dyson.iquest.net> Subject: Re: vclean (was The VIVA file system) To: terry@lambert.org (Terry Lambert) Date: Wed, 28 Aug 1996 12:31:38 -0500 (EST) Cc: michaelh@cet.co.jp, terry@lambert.org, eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199608281650.JAA26928@phaeton.artisoft.com> from "Terry Lambert" at Aug 28, 96 09:50:18 am Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The file type is a non-zero value in the high bits of the mode word; > it means that the inode does not refer to real data any more. > > The vgone call is just part of the subsystem I think should be replaced > wholesale; I'd like to see a per FS vrele() (back to locally managed > pools) replace most of those calls. The vgone() calls vgone1() calls > vclean, and we're back in my hate-zone. > > I tend to agree with you that it makes more sense to have VOP_VGET and friends be on a per-filesystem basis (well, you know what I mean -- we should consider creating VOP_VGET/VOP_VREF/VOP_VRELE/VOP_VPUT.) I think that it would certainly clean up the layering abstraction that we have. In fact, I had created ssuch a few years ago -- but like usual, VM issues take up all of my time. Right now, I am finding more problems with LFS than I had thought. Not to worry, should still have a soln this weekend. John From owner-freebsd-current Wed Aug 28 12:02:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA20955 for current-outgoing; Wed, 28 Aug 1996 12:02:16 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA20947 for ; Wed, 28 Aug 1996 12:02:12 -0700 (PDT) Received: by sovcom.kiae.su id AA13037 (5.65.kiae-1 for current@freebsd.org); Wed, 28 Aug 1996 21:56:31 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Wed, 28 Aug 96 21:56:30 +0300 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id WAA00351 for current@freebsd.org; Wed, 28 Aug 1996 22:56:26 +0400 (MSD) Message-Id: <199608281856.WAA00351@nagual.ru> Subject: Please fix current-src-etc SUP target to add tools/* collection To: current@freebsd.org (FreeBSD-current) Date: Wed, 28 Aug 1996 22:56:26 +0400 (MSD) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL25 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Subj. says all -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Wed Aug 28 13:03:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA23775 for current-outgoing; Wed, 28 Aug 1996 13:03:40 -0700 (PDT) Received: from wgrobez1.remote.louisville.edu (wgrobez1.remote.louisville.edu [136.165.243.183]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA23765 for ; Wed, 28 Aug 1996 13:03:36 -0700 (PDT) Received: from localhost (wangel@localhost) by wgrobez1.remote.louisville.edu (8.7.5/8.6.12) with SMTP id QAA10721 for ; Wed, 28 Aug 1996 16:03:45 -0400 (EDT) Date: Wed, 28 Aug 1996 16:03:44 -0400 (EDT) From: Gary Roberts To: freebsd-current@freebsd.org Subject: SAMBA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any software for freebsd that lets me mount my shared drives on my win95 machine? I know I can use smbclient, but I want to actually MOUNT the drive. Say I have a cd in my cdrom on my win95 machine, I want to be able to mount the cdrom, and then make an iso using mkisofs of that cdrom, is that possible? Thanks!! Gary Roberts System Admin. -- Altered Reality. http://136.165.243.183 -- Main User Pages From owner-freebsd-current Wed Aug 28 13:13:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24410 for current-outgoing; Wed, 28 Aug 1996 13:13:38 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA24379 for ; Wed, 28 Aug 1996 13:13:30 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA27351; Wed, 28 Aug 1996 12:59:31 -0700 From: Terry Lambert Message-Id: <199608281959.MAA27351@phaeton.artisoft.com> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: wollman@lcs.mit.edu (Garrett Wollman) Date: Wed, 28 Aug 1996 12:59:30 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, current@freebsd.org In-Reply-To: <9608281404.AA11859@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Aug 28, 96 10:04:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > [more stuff deleted...] > > Oh, gawd, FreeBSD is being overrun by a crowd of VMS weenies! Heh. Better call back the DOS weenies... "All is forgiven! Put the environment for the process into the process address space where the user can destroy it and make execve(2) fail! To hell with this Nazi concept 'memeory protection'!" 8-) 8-). 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 Wed Aug 28 13:15:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24609 for current-outgoing; Wed, 28 Aug 1996 13:15:51 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA24567 for ; Wed, 28 Aug 1996 13:15:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA27334; Wed, 28 Aug 1996 12:56:06 -0700 From: Terry Lambert Message-Id: <199608281956.MAA27334@phaeton.artisoft.com> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 28 Aug 1996 12:56:05 -0700 (MST) Cc: jkh@time.cdrom.com, phk@critter.tfs.com, terry@lambert.org, stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@freebsd.org In-Reply-To: <199608280329.MAA10965@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Aug 28, 96 12:59:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Time to take Terry up on his logicals concept. Anyone familiar enough with > the way that VMS handles/d these willing to talk for a while on it? I > seem to recall that you could create logicals on a system-wide basis as > well as per-session (or was that per-user?) > > There should be a way to integrate this with sysctl so that what are > currently sysctl variables become system-wide logicals with little or > no effective change, but the concept is extended to per-process group > (kinda like the environment), or summat similar. The tentative implementation I was favoring used the following model: 1) Process logical names o Hung of proc struct of current process o Inherited by reference ("copy on write") from parent process on fork() o Live across exec() o Replace getenv/setenv/putenv/unsetenv with library routines which interface to system calls; use of non-envp-based environment requires no changes to existing code linked shared. o A getenv of a name that is not in the process logical name table will inherit value from group, then system tables o A setenv/putenv of a name that exists in the group or system table will create a local entry that overrides via inheritance; the group/system table is not changable via setenv/putenv/unsetenv -- except as noted below o An unsetenv of an inherited value has no effect. You must use the LNM system interface to remove entries not in the local table o The POSIX interface is supported, but deprecated 2) Group logical names o Use process logical name table from controlling process of process group; no other related change necessary o Compare process ownership/credentials in modification case o Use same system call interface structure as that wrapped by getenv/setenv/putenv/unsetenv interface, where Process logical access through POSIX library wrappers imply user table o getenv/setenv/putenv/unsetenv will modify the process logical name table, even for the group leader; in the case of the group leader modifying their own table, the effect will be the same for the POSIX commands as for the process logical names, above. This is not the preferred interface for the group leader to set group logical name table values 3) System logical names o Uses process logical name table from init process (process ID 1). Since the init process normally operates without an environment (being hand-crafted), this is not antithetical to init o Compare ownership/process credentials in modification case (init runs with root credentials; therefore, effectively requires 'suser(cred) == TRUE') o Use same system call interface structure as that wrapped by getenv/setenv/putenv/unsetenv interface, where Process logical access through POSIX library wrappers imply user table o getenv/setenv/putenv/unsetenv will modify the process logical name table, even for the 'system leader'; in the case of the init process modifying its own table, the effect will be the same for the POSIX commands as for the process logical names, above. This is not the preferred interface for init to set system logical name table values What breaks: o The envp; it can be supported on a limited basis for compatability. POSIX exec envp compatability should be provided via library wrapper o An alternate implementation would be to dual map the table into the process address space and externally reference it via envp; this is necessary for binary compatability with statically linked programs, in any case. Because of this, the changeover would be most effective when the ELF binary changeover occurs, since the file magic number must change at that time, and the mapping can be handled via compatability calls for POSIX exec() implemented as a system call. What is enabled: o It is now possible to change the parent process's environment from the child. This has been a long desired feature o It is now possible to implement, simply and reliably, variant symbolic links. This has been a long desired feature o It is now possible for an execution class to impose path components based on per system emulation environment mechanisms. This resolves the ELF controversy, a well as the BSD compatability race with BSDI o It is possible to interface the init environment to replace the sysctl interface with a more generic mechanism. This is useful, both in moving to a central, and therefore simpler, contextual model, as well as allowing virtual system hosting to become more easily bound by moving sysctl references out of the system-wide scope of sysctl and into a per group scope for pseduo-group leaders other than init. This has profound implications for multiple hosting for ISP's, NSP's, and WSP's. I'd like to see Poul's stuff before I can comment on the merits of the model he has chosen, one way or the other. 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 Wed Aug 28 13:36:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA26400 for current-outgoing; Wed, 28 Aug 1996 13:36:05 -0700 (PDT) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA26395 for ; Wed, 28 Aug 1996 13:36:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by nlanr.net (8.7.3/8.7.3) with SMTP id NAA05076; Wed, 28 Aug 1996 13:33:18 -0700 (PDT) Message-Id: <199608282033.NAA05076@nlanr.net> To: Terry Lambert , jkh@time.cdrom.com, phk@critter.tfs.com, stesin@gu.kiev.ua, angio@aros.net, current@freebsd.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-reply-to: Your message of Wed, 28 Aug 1996 12:56:05 -0700 Date: Wed, 28 Aug 96 13:33:18 -0700 From: Duane Wessels X-Mts: smtp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please check your CC lists and stop polluting squid-users@nlanr.net with this thread which no longer has anything to do with the Squid software. Thanks, Duane W. From owner-freebsd-current Wed Aug 28 14:42:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA00450 for current-outgoing; Wed, 28 Aug 1996 14:42:22 -0700 (PDT) Received: from staff1.texas.net (ed@staff1.texas.net [206.127.0.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA00440 for ; Wed, 28 Aug 1996 14:42:15 -0700 (PDT) Received: from localhost (ed@localhost) by staff1.texas.net (TxNet/8.7.5) with SMTP id QAA28834; Wed, 28 Aug 1996 16:21:35 -0500 (CDT) X-Authentication-Warning: staff1.texas.net: ed owned process doing -bs Date: Wed, 28 Aug 1996 16:21:35 -0500 (CDT) From: Edward Henigin To: Terry Lambert cc: Michael Smith , jkh@time.cdrom.com, phk@critter.tfs.com, stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@freebsd.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-Reply-To: <199608281956.MAA27334@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This stuff all seems pretty cool.. 'cept it doesn't really seem squid related. May I respectfully suggest that further e-mails on this subject *not* include the squid-users list? Please edit your headers in future mail. Regards, Ed -- On Wed, 28 Aug 1996, Terry Lambert wrote: > The tentative implementation I was favoring used the following model: > > 1) Process logical names > [...] From owner-freebsd-current Wed Aug 28 14:49:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA00835 for current-outgoing; Wed, 28 Aug 1996 14:49:00 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA00826 for ; Wed, 28 Aug 1996 14:48:55 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA27534; Wed, 28 Aug 1996 14:36:45 -0700 From: Terry Lambert Message-Id: <199608282136.OAA27534@phaeton.artisoft.com> Subject: Re: SAMBA To: wangel@wgrobez1.remote.louisville.edu (Gary Roberts) Date: Wed, 28 Aug 1996 14:36:45 -0700 (MST) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Gary Roberts" at Aug 28, 96 04:03:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Is there any software for freebsd that lets me mount my shared drives on > my win95 machine? > > I know I can use smbclient, but I want to actually MOUNT the drive. Say I > have a cd in my cdrom on my win95 machine, I want to be able to mount the > cdrom, and then make an iso using mkisofs of that cdrom, is that possible? Wait for CIFS. It will supposedly use Kerberos 5 tickets for credential exchange. This will finally solve the "anti-UNIX" architecture problems of SMB. 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 Wed Aug 28 14:59:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA01551 for current-outgoing; Wed, 28 Aug 1996 14:59:24 -0700 (PDT) Received: from main.gbdata.com (Main.GBData.COM [207.90.222.20]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA01543 for ; Wed, 28 Aug 1996 14:59:18 -0700 (PDT) Received: (from gclarkii@localhost) by main.gbdata.com (8.7.5/8.6.9) id QAA24109 for freebsd-current@freebsd.org; Wed, 28 Aug 1996 16:58:02 -0500 (CDT) From: Gary Clark II Message-Id: <199608282158.QAA24109@main.gbdata.com> Subject: Strange interaction in current To: freebsd-current@freebsd.org Date: Wed, 28 Aug 1996 16:58:01 -0500 (CDT) 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I tried to build tk4.1 last night from the port. I'm running current with libtcl.so.75.0 installed in /usr/lib. I could not build tk. Can someone please re-do the port to take advantage of our present inclusion of tcl in the tree? If it had not been for the package, I would have had to build the tcl75 port again.... Gary -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups mail info@GBData.COM for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii From owner-freebsd-current Wed Aug 28 15:21:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA02863 for current-outgoing; Wed, 28 Aug 1996 15:21:14 -0700 (PDT) Received: from melb.werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA02858 for ; Wed, 28 Aug 1996 15:21:11 -0700 (PDT) Received: from cimaxp1.UUCP (uucp@localhost) by melb.werple.net.au (8.7.5/8.7.3/2) with UUCP id HAA17472 for mira!freebsd.org!freebsd-current; Thu, 29 Aug 1996 07:53:35 +1000 (EST) Message-Id: <199608282153.HAA17472@melb.werple.net.au> Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA07862; Thu, 29 Aug 1996 07:34:02 +1000 From: John Birrell Subject: Re: pthreads / libc_r To: stack.urc.tue.nl!xaa@melb.werple.net.au Date: Thu, 29 Aug 1996 07:34:02 +1000 (EST) Cc: freebsd.org!freebsd-current@melb.werple.net.au In-Reply-To: <199608271728.TAA10731@alterego.stack.urc.tue.nl> from "Mark Huizer" at Aug 27, 96 07:28:04 pm X-Mailer: ELM [version 2.4 PL24 ME8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > How up to date is this library? Yesterday I built myself a nice little > libc_r, but I couldn't really use it since e.g. pthread_attr_init and > others aren't exported in the resulting lib. Is this just an omission in > /usr/src/lib/libc_r/uthread/Makefile.inc or what? Omission. 8-(. /usr/src/lib/libc_r/uthread/Makefile.inc should contain _all_ of /usr/src/lib/libc_r/uthread/*.c. There are also a couple of places in libc where pthread_keycreate didn't get re-named to pthread_key_create. > Mark > ------------------------------------------------------------------------- > - Mark Huizer - xaa@stack.urc.tue.nl - rcbamh@urc.tue.nl - Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-current Wed Aug 28 15:43:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA04233 for current-outgoing; Wed, 28 Aug 1996 15:43:46 -0700 (PDT) Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA04225; Wed, 28 Aug 1996 15:43:43 -0700 (PDT) Received: from delphi.gordian.com (delphi.gordian.com [192.73.220.125]) by gordius.gordian.com (8.7.5/8.6.5) with ESMTP id PAA05413; Wed, 28 Aug 1996 15:43:44 -0700 (PDT) Received: (from steve@localhost) by delphi.gordian.com (8.7.2/8.6.9) id PAA19057; Wed, 28 Aug 1996 15:43:40 -0700 (PDT) Date: Wed, 28 Aug 1996 15:43:40 -0700 (PDT) Message-Id: <199608282243.PAA19057@delphi.gordian.com> From: Steve Khoo To: freebsd-current@freebsd.org CC: freebsd-scsi@freebsd.org, se@ZPR.Uni-Koeln.DE In-reply-to: Steve Khoo's message of Mon, 26 Aug 1996 12:15:09 -0700 (PDT) Subject: Re: problems booting with 2 drives on NCR8251D References: <199608261915.MAA10702@delphi.gordian.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk FYI: Well, I didn't get any response on this, but finally tracked down the problem to a flaky pin on one of the 68pin FWD SCSI connectors. SEK >>>>> "Steve" == Steve Khoo writes: Steve> setup: Steve> Asus MB(P55TP4XEG) 512K Cache Steve> 32MB RAM Steve> Fast Wide Differential SCSI Controller (NCR8251D) Steve> Seagate ST12550WD on SCSI ID #0 Steve> Seagate ST15150WD on SCSI ID #1 Steve> The system is running FreeBSD 2.2-CURRENT sup'd on 8/17/96. Steve> The system boots and runs find with just the first(Seagate Steve> ST12550WD) drive. When I added the second(Seagate Steve> ST15150WD) drive I get the following errors. I can boot Steve> dos and do fdisk/format and stuff on the second drive Steve> without any problems. Any ideas what the errors mean? Steve> I'd appreciate any help. Steve> Thanks! Steve> SEK Steve> FreeBSD 2.2-CURRENT #0: Mon Aug 19 12:48:53 PDT 1996 Steve> steve@metis.gordian.com:/usr/src/sys/compile/metis Steve> Calibrating clock(s) relative to mc146818A clock... Steve> i586 clock: 99465569 Hz, i8254 clock: 1193086 Hz Steve> CPU: Pentium (99.47-MHz 586-class CPU) Steve> Origin = "GenuineIntel" Id = 0x525 Stepping=5 Steve> Features=0x1bf Steve> real memory = 33554432 (32768K bytes) Steve> avail memory = 30695424 (29976K bytes) Steve> Probing for devices on PCI bus 0: Steve> chip0 rev 2 on pci0:0 Steve> chip1 rev 2 on pci0:7:0 Steve> pci0:7:1: Intel Corporation, device=0x1230, class=storage (ide) [no driver assigned] Steve> de0 rev 18 int a irq 12 on pci0:9 Steve> de0: SMC 9332 DC21140 [10-100Mb/s] pass 1.2 Steve> de0: address 00:00:c0:58:c3:e4 Steve> de0: enabling 10baseT port Steve> ncr0 rev 2 int a irq 10 on pci0:10 Steve> ncr0 waiting for scsi devices to settle Steve> (ncr0:0:0): "SEAGATE ST12550W 0004" type 0 fixed SCSI 2 Steve> sd0(ncr0:0:0): Direct-Access Steve> sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled. Steve> sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. Steve> 2040MB (4178874 512 byte sectors) Steve> (ncr0:1:0): "SEAGATE ST15150W 0023" type 0 fixed SCSI 2 Steve> sd1(ncr0:1:0): Direct-Access Steve> sd1(ncr0:1:0): WIDE SCSI (16 bit) enabled. Steve> ncr0:1: ERROR (80:91) (9-ae-0) (0/1b) @ (d8c:19000004). Steve> script cmd = 89030000 Steve> reg: da 10 80 1b 47 00 01 07 23 09 81 ae 80 00 0e 08. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> sd1 could not mode sense (4). Using ficticious geometry Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> ncr0: aborting job ... Steve> ncr0:0: ERROR (90:0) (8-a6-0) (0/13) @ (418:43000060). Steve> script cmd = 878b0000 Steve> reg: da 00 00 13 47 00 01 07 31 08 01 a6 80 00 0e 0a. Steve> ncr0: restart (fatal error). Steve> sd1(ncr0:1:0): COMMAND FAILED (9 ff) @f109b400. Steve> sd1: could not get size Steve> 0MB (0 512 byte sectors) From owner-freebsd-current Wed Aug 28 16:25:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA09067 for current-outgoing; Wed, 28 Aug 1996 16:25:48 -0700 (PDT) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA09056 for ; Wed, 28 Aug 1996 16:25:45 -0700 (PDT) Received: from fiber.eng.umd.edu (fiber.eng.umd.edu [129.2.98.185]) by po2.glue.umd.edu (8.7.5/8.7.3) with ESMTP id TAA04195; Wed, 28 Aug 1996 19:25:43 -0400 (EDT) Received: from localhost (chuckr@localhost) by fiber.eng.umd.edu (8.7.5/8.7.3) with SMTP id TAA13943; Wed, 28 Aug 1996 19:25:42 -0400 (EDT) X-Authentication-Warning: fiber.eng.umd.edu: chuckr owned process doing -bs Date: Wed, 28 Aug 1996 19:25:42 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@fiber.eng.umd.edu To: Gary Clark II cc: freebsd-current@freebsd.org Subject: Re: Strange interaction in current In-Reply-To: <199608282158.QAA24109@main.gbdata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 28 Aug 1996, Gary Clark II wrote: > Hello, > > I tried to build tk4.1 last night from the port. I'm running current with > libtcl.so.75.0 installed in /usr/lib. I could not build tk. > > Can someone please re-do the port to take advantage of our present inclusion > of tcl in the tree? If it had not been for the package, I would have had > to build the tcl75 port again.... Yeah, Gary, I know. I have sent so far two folks my patches to libtcl, so that this can happen. As soon as someone will review them, I'll commit them, then I'll work on tk41. I'm sorry you're caught waiting with me. Libtcl needs to install the rest of it's include files. > > Gary > > -- > Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company > gclarkii@GBData.COM | Member of the FreeBSD Doc Team > Providing Internet and ISP startups mail info@GBData.COM for information > FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Wed Aug 28 17:30:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA18534 for current-outgoing; Wed, 28 Aug 1996 17:30:30 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA18471; Wed, 28 Aug 1996 17:30:08 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA04895; Thu, 29 Aug 1996 00:29:07 GMT Date: Thu, 29 Aug 1996 09:29:07 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: vclean (was The VIVA file system) In-Reply-To: <199608281650.JAA26928@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 28 Aug 1996, Terry Lambert wrote: > > > This was the point I was missing. What is disassociating the inode and > > > when is it happening? > > > > Yikes! I took a look below, but I didn't expect to see vgone() calls in > > ufs_inactive(). > > > > if (vp->v_usecount == 0 && ip->i_mode == 0) > > vgone(vp); > > > > I need to figure out what ip->i_mode == 0 means. > > The file type is a non-zero value in the high bits of the mode word; > it means that the inode does not refer to real data any more. > > The vgone call is just part of the subsystem I think should be replaced > wholesale; I'd like to see a per FS vrele() (back to locally managed > pools) replace most of those calls. The vgone() calls vgone1() calls > vclean, and we're back in my hate-zone. My interpretation of the vnode global pool design was that vgone...->vclean wouldn't be called very often. It would only be called by getnewvnode() when free vnodes were not available and for cases when the vnode is deliberately revoked. Inactive() would mark both the vnode/inode inactive, but the data would be left intact even when usecount went to zero so that all the important data could be reactivated quickly. It's not working this way and it doesn't look trivial to get it work this way. Regarding local per fs pools you still need some kind of global memory management policy. It seems less complicated to manage a global pool, than local per fs pools with opaque VOP calls. Say you've got FFS, LFS, and NFS systems mounted and fs usage patterns migrate between the fs's. You've got limited memory resources. How do you determine which local pool to recover vnodes from? It'd be inefficient to leave the pools wired until the fs was unmounted. Complex LRU-like policies across multiple local per fs vnode pools also sound pretty complicated to me. We also need to preserve the vnode revoking semantics for situations like revoking the session terminals from the children of sesssion leaders. Regards, Mike Hancock From owner-freebsd-current Wed Aug 28 17:34:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA19336 for current-outgoing; Wed, 28 Aug 1996 17:34:08 -0700 (PDT) Received: from sting.artisoft.com (sting.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA19302 for ; Wed, 28 Aug 1996 17:34:01 -0700 (PDT) Received: (from mday@localhost) by sting.artisoft.com (8.7.5/8.7.3) id RAA14743 for freebsd-current@FreeBSD.org; Wed, 28 Aug 1996 17:33:22 -0700 (MST) Date: Wed, 28 Aug 1996 17:33:22 -0700 (MST) From: Matt Day Message-Id: <199608290033.RAA14743@sting.artisoft.com> To: freebsd-current@FreeBSD.org Subject: Re: SAMBA Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > wangel@wgrobez1.remote.louisville.edu (Gary Roberts) wrote: > > Is there any software for freebsd that lets me mount my shared drives on > > my win95 machine? > > > > I know I can use smbclient, but I want to actually MOUNT the drive. Say I > > have a cd in my cdrom on my win95 machine, I want to be able to mount the > > cdrom, and then make an iso using mkisofs of that cdrom, is that possible? > > Wait for CIFS. It will supposedly use Kerberos 5 tickets for > credential exchange. This will finally solve the "anti-UNIX" > architecture problems of SMB. That's not very correct. Microsoft's implementation of CIFS *might* use Kerberos v5 - they're still in the design phase. CIFS itself will probably not specify a particular authentication protocol. The CIFS designers are currently thinking of basing the authentication system on GSS-API (RFC 1508/1509) which would give the CIFS implementor the capability to choose the actual authentication protocol. CIFS may suggest Kerberos v5 as a possible protocol, but it probably won't require it. This is also in the design phase right now. The authentication issue isn't the only "anti-UNIX" problem, either. CIFS will need to solve many other issues, such as: UID mapping, file attribute/permission mapping, file name space differences, file locking mapping, date/time differences, UNICODE issues, and others. CIFS is going to try to address all these issues. If you want to mount Win95 drives from a FreeBSD system, please don't wait for CIFS - CIFS won't be ready for months, at least. Instead, port or write ksmbfs for FreeBSD! The ksmbfs kernel module for Linux (in Samba's contributed section) already provides the capability to mount SMB volumes from Linux. (Unfortunately, you can't NFS export stuff mounted by ksmbfs, due to limitations.) Getting ksmbfs on FreeBSD would also be a great way to help prepare FreeBSD for CIFS. Download ksmbfs from: ftp://samba.anu.edu.au/pub/samba/contributed/ksmbfs-0.2.4.tgz Matt Day From owner-freebsd-current Wed Aug 28 18:45:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA00173 for current-outgoing; Wed, 28 Aug 1996 18:45:38 -0700 (PDT) Received: from kenobi.pmr.com (kenobi.pmr.com [206.224.65.139]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA00163 for ; Wed, 28 Aug 1996 18:45:31 -0700 (PDT) Received: (from bob@localhost) by kenobi.pmr.com (8.7.5/8.7.3) id UAA03527 for freebsd-current@freefall.cdrom.com; Wed, 28 Aug 1996 20:45:29 -0500 (CDT) From: Bob Willcox Message-Id: <199608290145.UAA03527@kenobi.pmr.com> Subject: panic: ufs_unlock NOT LOCKED To: freebsd-current@freefall.FreeBSD.org (freebsd-current) Date: Wed, 28 Aug 1996 20:45:28 -0500 (CDT) 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have just recently (past couple of days) starting receiving the following panic on my -current test system whenever I reboot or halt it. cleaning up... Using obsolete shutdown callout.. update code to use at_shutdown() syncing disks... 4 4 done ufs_unlock: unlocked inode: type VBLK, usecount 2, writecount 0, refcount 3, tag VT_UFS, ino 815, on dev 4, 8 panoc: ufs_unlock NOT LOCKED The first two lines may not be relavent, but I don't remember seeing them before the panics started. Inode 815 on dev 4, 8 is the following special device on my root filesystemw 815 brw-r----- 1 root operator 4, 0x00020016 Mar 19 04:15 /dev/sd2s1g My local filesystems look like this: bob@han-p0 /dev> df -tlocal Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd1a 29727 15006 12343 55% / /dev/sd1s1e 98479 2849 87752 3% /var /dev/sd1s1g 49231 1 45292 0% /tmp /dev/sd1s1h 775231 398671 314542 56% /usr /dev/sd2s1e 148703 104527 32280 76% /usr/obj /dev/sd2s1f 297423 214021 59609 78% /usr/src /dev/sd2s1g 507183 1 466608 0% /stuff Anybody have an idea what is going wrong here? Thanks, -- Bob Willcox politics, n: bob@luke.pmr.com A strife of interests masquerading as a contest of Austin, TX principles. The conduct of public affairs for private advantage. -- Ambrose Bierce From owner-freebsd-current Wed Aug 28 19:42:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04675 for current-outgoing; Wed, 28 Aug 1996 19:42:32 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04661 for current; Wed, 28 Aug 1996 19:42:29 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199608290242.TAA04661@freefall.freebsd.org> Subject: [Q] mbuf 128 vs 1k bytes ?? To: current Date: Wed, 28 Aug 1996 19:42:28 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk an mbuf is 128 bytes. mbuf clusters are 2k. per my reading of /sys/i386/include/param.h why does "vmstat -m" report mbufs as being 1k in -current ?? are they allocated in 1kB blocks and then chopped up into 8 pieces? are mbuf clusters allocated....how...surely not two allocations of 1kB each. i took a stroll thru vmstat.c, uipc_mbuf.c, /sys/sys/malloc.h, vm_kern.c vm_page.c, vm_map.c....and i am glad that john dyson has his head around this code ;)) i sure dont't understand it near well enough. from uipc_mbuf.c line 110, i see that mbufs are "allocated" in units of pages but that only makes it worse....pages are 4kB (param.h again) Aspen:[117] uname -a FreeBSD Aspen.Woc.Atinc.COM 2.2-CURRENT FreeBSD 2.2-CURRENT #0: Wed Aug 21 20:04:37 EDT 1996 jmb@Aspen.Woc.Atinc.COM:/usr/src/sys/compile/ASPEN i386 Aspen:[118] vmstat -m | more [snip] Memory usage type by bucket size Size Type(s) [snip] 1K mbuf, devbuf, namei, UFS mount, VM pgdata, temp, BIO buffer [snip] Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) mbuf 1 1K 1K 8948K 1 0 0 1K freefall jmb[106] uname -a FreeBSD freefall.freebsd.org 2.1.5-RELEASE FreeBSD 2.1.5-RELEASE #0: Thu Aug 8 07:07:41 PDT 1996 davidg@freefall.freebsd.org:/f/src/sys/compile/FREEFALL i386 freefall jmb[107] vmstat -m | more [snip] Memory usage type by bucket size Size Type(s) [snip] 128 mbuf, devbuf, pcb, routetbl, fragtbl, zombie, ifaddr, soopts, cred, vnodes, VM map, VM object, VM pgdata, file desc, LFS segment, NFS srvsock, ip_moptions, ISOFS node, temp, ttys [snip] 4K mbuf, devbuf, VM pgdata, temp Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) mbuf 197 29K 121K 19661K 49212373 0 0 128,4K 4K--????? from /sys/i386/include/param.h /* * Constants related to network buffer management. * MCLBYTES must be no larger than CLBYTES (the software page size), and, * on machines that exchange pages of input or output buffers with mbuf * clusters (MAPPED_MBUFS), MCLBYTES must also be an integral multiple * of the hardware page size. */ #ifndef MSIZE #define MSIZE 128 /* size of an mbuf */ #endif /* MSIZE */ #ifndef MCLSHIFT #define MCLSHIFT 11 /* convert bytes to m_buf clusters */ #endif /* MCLSHIFT */ #define MCLBYTES (1 << MCLSHIFT) /* size of an m_buf cluster */ #define MCLOFSET (MCLBYTES - 1) /* offset within an m_buf cluster */ jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-current Wed Aug 28 19:59:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06467 for current-outgoing; Wed, 28 Aug 1996 19:59:39 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [204.214.4.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA06447 for ; Wed, 28 Aug 1996 19:59:33 -0700 (PDT) Received: from max2-150.HiWAAY.net by fly.HiWAAY.net; (5.65/1.1.8.2/21Sep95-1003PM) id AA23946; Wed, 28 Aug 1996 21:59:26 -0500 Message-Id: <32250737.41C67EA6@hiwaay.net> Date: Wed, 28 Aug 1996 21:57:59 -0500 From: Steve Price X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.2-CURRENT i386) Mime-Version: 1.0 To: freebsd-current@freebsd.org Subject: Problem with partition size on IDE drive and -current Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It seems I can only get a 1GB partition on my 2GB drive. Here is all the relevant info I can think of. --------------------------------->8-------------------------------- steve:~$ df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 1968668 1309088 502088 72% / procfs 8 8 0 100% /proc /dev/wd1c 1985694 1079790 747050 59% /u steve:~$ disklabel wd1 # /dev/rwd1c: type: ESDI disk: wd1s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 64 sectors/cylinder: 4032 cylinders: 1022 sectors/unit: 4124673 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 4124673 0 unused 0 0 # (Cyl. 0 - 1022*) steve:~$ fdisk wd1 ******* Working on device /dev/rwd1 ******* parameters extracted from in-core disklabel are: cylinders=1023 heads=64 sectors/track=63 (4032 blks/cyl) parameters to be used for BIOS calculations are: cylinders=1023 heads=64 sectors/track=63 (4032 blks/cyl) Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 63, size 4124673 (2014 Meg), flag 80 beg: cyl 0/ sector 1/ head 1; end: cyl 1022/ sector 63/ head 63 The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: steve:~$ cat > foo.c #include #include #include #include int main () { struct statfs statfsbuf; if (statfs("/", &statfsbuf) == 0) printf("/: f_bsize = %ld\n", statfsbuf.f_bsize); if (statfs("/u", &statfsbuf) == 0) printf("/u: f_bsize = %ld\n", statfsbuf.f_bsize); } ^D steve:~$ gcc foo.c steve:~$ ./a.out /: f_bsize = 2048 /u: f_bsize = 1024 steve:~$ --------------------------------->8-------------------------------- BTW, I am running -current as of 8/25/96 on a P5/90 w/64 MB of ram. The IDE drive mounted on / is 1GB and everything seems to be hunky-dorey. It seems to have something to do with f_bsize. I tried changing it with 'newfs -i 2048 wd1c', but to no avail. I also tried to use /stand/sysinstall but it returns an error about 'no drives found' when I try to repartition wd1. Anybody have any ideas what I'm missing? TIA, Steve From owner-freebsd-current Wed Aug 28 20:02:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA06788 for current-outgoing; Wed, 28 Aug 1996 20:02:12 -0700 (PDT) Received: from VX23.CC.MONASH.EDU.AU (vx23.cc.monash.edu.au [130.194.1.23]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA06783 for ; Wed, 28 Aug 1996 20:02:08 -0700 (PDT) Received: from moa.cc.monash.edu.au (george@moa.cc.monash.edu.au) by vaxc.cc.monash.edu.au (PMDF V5.0-6 #16291) id <01I8UKMZL38O984W34@vaxc.cc.monash.edu.au>; Thu, 29 Aug 1996 13:01:00 +1000 Received: (george@localhost) by moa.cc.monash.edu.au (8.6.10/8.6.4) id NAA08388; Thu, 29 Aug 1996 13:00:50 +1000 Date: Thu, 29 Aug 1996 13:00:50 +1000 From: George Scott Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: terry@lambert.org Cc: current@FreeBSD.org Message-id: <199608290300.NAA08388@moa.cc.monash.edu.au> Content-transfer-encoding: 7BIT Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The tentative implementation I was favoring used the following model: > > 1) Process logical names > > o Hung of proc struct of current process I'm not sure what this means! Could these logicals be accessed as a directory structure in procfs? Something like /proc/127/env/SHELL which can be read, written and unlinked to do getenv, setenv and unsetenv respectively for process 127? This would allow access to be controlled with the normal filesystem mode bits and would save us from having to have yet another set of system calls to implemented. The down side would be that having a procfs mounted would be almost mandatory. While I'm at it, creating a /proc/127/parent as a link to /proc/125 (meaning that pid 125 is the parent of pid 127) would allow neat things such as shell scripts that could set their parents environment variables with a simple: echo "new value" >/proc/curproc/parent/env/PATH George. -- George Scott George.Scott@cc.monash.edu.au Systems Programmer, Caulfield Computer Centre, Monash University From owner-freebsd-current Wed Aug 28 20:06:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA07073 for current-outgoing; Wed, 28 Aug 1996 20:06:52 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA07057; Wed, 28 Aug 1996 20:06:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id UAA20774; Wed, 28 Aug 1996 20:06:38 -0700 (PDT) Message-Id: <199608290306.UAA20774@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Jonathan M. Bresler" cc: current@freefall.freebsd.org Subject: Re: [Q] mbuf 128 vs 1k bytes ?? In-reply-to: Your message of "Wed, 28 Aug 1996 19:42:28 PDT." <199608290242.TAA04661@freefall.freebsd.org> From: David Greenman Reply-To: dg@root.com Date: Wed, 28 Aug 1996 20:06:38 -0700 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >an mbuf is 128 bytes. mbuf clusters are 2k. per my reading of >/sys/i386/include/param.h Yes, that is correct. >why does "vmstat -m" report mbufs as being 1k in -current ?? are Because mbufs are no longer allocated out of the malloc pool. The 1K entry that you are seeing is just some malloc() in the kernel that (probably bogusly) specified the M_MBUF type. I only have 1 of them on my machine: Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) mbuf 1 1K 1K 19661K 1 0 0 1K ...anyway, this is all much to do about nothing. To find out how many network buffers are in-use, use netstat -m. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Wed Aug 28 20:28:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA08450 for current-outgoing; Wed, 28 Aug 1996 20:28:40 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA08441; Wed, 28 Aug 1996 20:28:38 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199608290328.UAA08441@freefall.freebsd.org> Subject: Re: [Q] mbuf 128 vs 1k bytes ?? To: dg@root.com Date: Wed, 28 Aug 1996 20:28:37 -0700 (PDT) Cc: current@freefall.freebsd.org In-Reply-To: <199608290306.UAA20774@root.com> from "David Greenman" at Aug 28, 96 08:06:38 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote: > > Because mbufs are no longer allocated out of the malloc pool. The 1K entry > that you are seeing is just some malloc() in the kernel that (probably bogusly) > specified the M_MBUF type. I only have 1 of them on my machine: > > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > mbuf 1 1K 1K 19661K 1 0 0 1K > > ...anyway, this is all much to do about nothing. To find out how many > network buffers are in-use, use netstat -m. ah...that's might be all the hint that i needed: how about this code in machdep.c 1.199 1996/08/19 line 365 /* * Finally, allocate mbuf pool. Since mclrefcnt is an off-size * we use the more space efficient malloc in place of kmem_alloc. */ mclrefcnt = (char *)malloc(nmbclusters+PAGE_SIZE/MCLBYTES, M_MBUF, M_NOWAIT); bzero(mclrefcnt, nmbclusters+PAGE_SIZE/MCLBYTES); looking at /sys/sys/malloc.h, i dont see what else this might be classified as ;( jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-current Thu Aug 29 00:12:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA21069 for current-outgoing; Thu, 29 Aug 1996 00:12:48 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA21063; Thu, 29 Aug 1996 00:12:42 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id JAA02164; Thu, 29 Aug 1996 09:12:05 +0200 (MET DST) To: Garrett Wollman cc: "Jordan K. Hubbard" , current@FreeBSD.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. In-reply-to: Your message of "Wed, 28 Aug 1996 09:53:43 EDT." <9608281353.AA11942@halloran-eldar.lcs.mit.edu> Date: Thu, 29 Aug 1996 09:12:04 +0200 Message-ID: <2162.841302724@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <9608281353.AA11942@halloran-eldar.lcs.mit.edu>, Garrett Wollman wri tes: >< > said: > >> Aieee! Another file in /etc! sysctl! sysctl! :-) > >I don't see that this is an appropriate application of sysctl. I agree. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Aug 29 02:07:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA27172 for current-outgoing; Thu, 29 Aug 1996 02:07:37 -0700 (PDT) Received: from render.gu.kiev.ua (render.gu.kiev.ua [193.124.51.65]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA27112 for ; Thu, 29 Aug 1996 02:06:26 -0700 (PDT) Received: from creator.gu.kiev.ua (root@creator.gu.kiev.ua [193.124.51.73]) by render.gu.kiev.ua with ESMTP id JAA00050 for ; Thu, 29 Aug 1996 09:25:39 +0300 Received: (from stesin@localhost) by creator.gu.kiev.ua id JAA07365 for current@freebsd.org; Thu, 29 Aug 1996 09:24:17 +0300 Received: from acc0.elvisti.kiev.ua (acc0.elvisti.kiev.ua [193.125.28.132]) by creator.gu.kiev.ua with ESMTP id UAA02765 for ; Wed, 28 Aug 1996 20:39:08 +0300 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.129]) by acc0.elvisti.kiev.ua (8.7.5/8.7.3) with ESMTP id UAA20263 for ; Wed, 28 Aug 1996 20:41:17 +0300 (EET DST) Received: from brimstone.netspace.org ([128.148.157.143]) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id UAA23879 for ; Wed, 28 Aug 1996 20:40:09 +0300 Received: from netspace.org ([128.148.157.6]) by brimstone.netspace.org with ESMTP id <22756-9751>; Wed, 28 Aug 1996 13:34:15 -0500 Received: from netspace.org (netspace [128.148.157.6]) by netspace.org (8.7/8.6.12) with SMTP id NAA08273; Wed, 28 Aug 1996 13:28:15 -0400 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 310032 for BUGTRAQ@NETSPACE.ORG; Wed, 28 Aug 1996 12:57:19 -0400 Received: from netspace.org (netspace [128.148.157.6]) by netspace.org (8.7/8.6.12) with SMTP id MAA05096 for ; Wed, 28 Aug 1996 12:51:38 -0400 Approved-By: ALEPH1@UNDERGROUND.ORG Received: from mvmap66.ciw.uni-karlsruhe.de (mvmap66.ciw.uni-karlsruhe.de [129.13.110.66]) by netspace.org (8.7/8.6.12) with ESMTP id EAA29584 for ; Wed, 28 Aug 1996 04:29:26 -0400 Received: (from ig25@localhost) by mvmap66.ciw.uni-karlsruhe.de (8.7.5/8.6.12) id KAA00184; Wed, 28 Aug 1996 10:28:51 +0200 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Approved-By: Thomas Koenig Message-ID: <199608280828.KAA00184@mvmap66.ciw.uni-karlsruhe.de> Date: Wed, 28 Aug 1996 10:28:51 +0200 Reply-To: Bugtraq List From: Thomas Koenig Subject: Re: Tired of /tmp? Here's a proposed solution X-To: guido@dataweb.nl To: Multiple recipients of list BUGTRAQ In-Reply-To: <199608270848.KAA09177@this.is.my.net> from "Guido M. Witmond" at "Aug 27, 96 10:48:21 am" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Guido M. Witmond wrote: >Well, this is a good quick hack. What about removing the CONCEPT of >public writable filesystems like /tmp. Agree 100%. The best solution would be, IMHO, to give each user his or her personal temporary directory, under /tmp/username, mode 700. /tmp can stay 1777 for stuff like make files accessible to other users. Comments? -- Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet. The joy of engineering is to find a straight line on a double logarithmic diagram. From owner-freebsd-current Thu Aug 29 09:33:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA17371 for current-outgoing; Thu, 29 Aug 1996 09:33:34 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA17356; Thu, 29 Aug 1996 09:33:12 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA28774; Thu, 29 Aug 1996 09:16:20 -0700 From: Terry Lambert Message-Id: <199608291616.JAA28774@phaeton.artisoft.com> Subject: Re: vclean (was The VIVA file system) To: michaelh@cet.co.jp (Michael Hancock) Date: Thu, 29 Aug 1996 09:16:20 -0700 (MST) Cc: terry@lambert.org, eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Aug 29, 96 09:29:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > My interpretation of the vnode global pool design was that > vgone...->vclean wouldn't be called very often. It would only be called > by getnewvnode() when free vnodes were not available and for cases when > the vnode is deliberately revoked. > > Inactive() would mark both the vnode/inode inactive, but the data would be > left intact even when usecount went to zero so that all the important data > could be reactivated quickly. > > It's not working this way and it doesn't look trivial to get it work this > way. That's right. This is a natural consequence of moving the cache locality from its seperate location into its now unified location. Because you can not look up a buffer by device (and the device association would never be destroyed for a valid buffer in core, yet unreclaimed), the buffers on the vnodes in the pool lack the localitiy of the pre VM/cache unification code. The unification was such a tremendous win, that this was either hidden, or more likely, discounted. I'd like to see it revisited. > Regarding local per fs pools you still need some kind of global memory > management policy. It seems less complicated to manage a global pool, > than local per fs pools with opaque VOP calls. The amount of memeory is relatively small, and we are already running a modified zone allocator in any case. I don't see any conflict in the definition of a dditional zones. How do I reclaim packet reassembly buffer when I need another vnode? Right now, I don't. The conflict resoloution is intra-pool. Inter-pool conflicts are resolved either by static resource limits, or soft limits and/or watermarking. > Say you've got FFS, LFS, and NFS systems mounted and fs usage patterns > migrate between the fs's. You've got limited memory resources. How do > you determine which local pool to recover vnodes from? It'd be > inefficient to leave the pools wired until the fs was unmounted. Complex > LRU-like policies across multiple local per fs vnode pools also sound > pretty complicated to me. You keep a bias statistic, maintained on a per pool basis, for the reclaimation, and the reclaimer operates at a pool granularity, if in fact you allow such reclaimation to occur (see my paragraph preceeding for preferred approaches to a knowledgable reclaimer). > We also need to preserve the vnode revoking semantics for situations like > revoking the session terminals from the children of sesssion leaders. This is a tty subsystem function, and I do not agree with the current revocation semantics, mostly because I think tty devices should be instanced per controlling tty reference. This would allow the reference to be invalidated via flagging rather than using a seperate opv table. If you look for "struct fileops", you will see another bogosity that makes this this problematic. Resolve the struct fileops, and the carrying around of all that dead weight in the fd structs, and you have resolved the deadfs problem at the same time. The specfs stuff is going to go away with devfs, leaving UNIX domain sockets, pipes (which should be implemented as an opaque FS reference no exported as a mount point mapping to user space), and the VFS fileops (which should be the only ones, and therefore implicit, anyway). It's really not as complicated as you want to make it. 8-). 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 Aug 29 09:37:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA17649 for current-outgoing; Thu, 29 Aug 1996 09:37:50 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA17644 for ; Thu, 29 Aug 1996 09:37:48 -0700 (PDT) Received: from gemini.sdsp.mc.xerox.com ([13.231.132.20]) by alpha.xerox.com with SMTP id <15128(5)>; Thu, 29 Aug 1996 09:36:57 PDT Received: from gnu.mc.xerox.com (gnu.sdsp.mc.xerox.com) by gemini.sdsp.mc.xerox.com (4.1/SMI-4.1-TB) id AA00618; Thu, 29 Aug 96 12:37:09 EDT Received: by gnu.mc.xerox.com (4.1/SMI-4.1) id AA08771; Thu, 29 Aug 96 12:37:08 EDT Message-Id: <9608291637.AA08771@gnu.mc.xerox.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Matt Day Cc: freebsd-current@freebsd.org Subject: Re: SAMBA In-Reply-To: Your message of "Wed, 28 Aug 1996 17:33:22 PDT." <199608290033.RAA14743@sting.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Aug 1996 09:37:07 PDT From: "Marty Leisner" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > If you want to mount Win95 drives from a FreeBSD system, please > don't wait for CIFS - CIFS won't be ready for months, at least. > Instead, port or write ksmbfs for FreeBSD! The ksmbfs kernel module > for Linux (in Samba's contributed section) already provides the > capability to mount SMB volumes from Linux. (Unfortunately, you > can't NFS export stuff mounted by ksmbfs, due to limitations.) > Getting ksmbfs on FreeBSD would also be a great way to help prepare > FreeBSD for CIFS. > > Download ksmbfs from: > ftp://samba.anu.edu.au/pub/samba/contributed/ksmbfs-0.2.4.tgz > > Matt Day I've seen flakiness nfs exporting (my sun nfs mounted to a linux box, my linux box smbfs mounted to a pc). Sometimes I can get at files on the pc directly on the sun, most of the time I can't. Also, (I haven't looked into this) smbfs writing is incredibly slow. Pulling a file from a pc with samba is much, much faster than trying to push it through smbfs. smbfs on freebsd would be most welcome. -- marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom From owner-freebsd-current Thu Aug 29 11:03:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA22617 for current-outgoing; Thu, 29 Aug 1996 11:03:32 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA22511 for ; Thu, 29 Aug 1996 11:03:17 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA29043; Thu, 29 Aug 1996 10:51:37 -0700 From: Terry Lambert Message-Id: <199608291751.KAA29043@phaeton.artisoft.com> Subject: Re: SAMBA To: mday@Artisoft.COM (Matt Day) Date: Thu, 29 Aug 1996 10:51:37 -0700 (MST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199608290033.RAA14743@sting.artisoft.com> from "Matt Day" at Aug 28, 96 05:33:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [ ... CIFS information ... ] Thanks for the additional information; I wasn't sure if you would jump in on this or not. You are certainly more up to date on CIFS than any of the rest of us. > If you want to mount Win95 drives from a FreeBSD system, please > don't wait for CIFS - CIFS won't be ready for months, at least. > Instead, port or write ksmbfs for FreeBSD! The ksmbfs kernel module > for Linux (in Samba's contributed section) already provides the > capability to mount SMB volumes from Linux. (Unfortunately, you > can't NFS export stuff mounted by ksmbfs, due to limitations.) > Getting ksmbfs on FreeBSD would also be a great way to help prepare > FreeBSD for CIFS. > > Download ksmbfs from: > ftp://samba.anu.edu.au/pub/samba/contributed/ksmbfs-0.2.4.tgz How do you resolve: 1) It's GPL'ed code 2) It does not allow per-user enforcement of credential mapping The first is not really a kicker if it's distributed as an LKM, and the LKM is not distributed pre-loaded. Its just that you can't sell or even give away the agregate system because of the license conflicts. The second is a serious issue, since it damages the SMB server administrators management authority to have all users from a given UNIX box appear as as a single SMB client. This was my objection to the SMBFS suggestions I have seen in the past. I did an SMBFS for FreeBSD 1.1.5.1 (so it would be a hard port, and it is code Novell/USG claimed they owned because I was a Novell employee when I did it on my own time before Novell bought USL). The credential problem is significant, and I did not solve it in my prototype code. IF FreeBSD supported attaching additional credential information to a session (ie: it had the concept of a session manager, which it applied to normal console logins, as well as to "screen" and "xdm" logins), then it would be possible to implement a method of querying the user asynchronously for the information the kernel needs to establish a seperate connection credential for the user for a given mount. For remote sessions, and for TTY's, where it is impossible to pop up a "dialog" without potentially destroying unrecoverable screen contents, preauthentication would be required. This basically means adding an EAUTH error code to all pathing operations, and handling the error return in all programs which invoke those system/library calls. Then the applications can self-handle querying for authentication without damaging the application context. There is also the posibility of a Window95-style "password cache" in this scenario, the cache being managed by the session manager, and cache unlocking forced at login time along with standard system login. This incidently buys you the ability to have password protected directories and files, since the missing piece for that FS extentionis the ability to query the user for authentication data; same proble, different context. But short of this, porting SMBFS directly is a bad idea, since it damages existing security models on servers we can't do anything about because they come from Microsoft, or AT&T, or IBM, etc., an they don't have source code. There is no way to repair the damage, other than to note it, and have the SMB server administrator react appropriately (which is undefined, since the situation never arises without SMBFS rearing its ugly head). If you intentionally go ahead and damage someone elses security model by making an N:1 mapping of a resource which is, by design, expected to be 1:1 mapped by a single user client machine, be prepared to take on a lot of heat for doing it. This is *exactly* the problem the NUC (NetWare UNIX Client) people at Novell dealt with in UnixWare, NeXTStep, etc., and exactly the issue that caused them the most grief in their 20 man year (5 engineers over 4 years) project to solve the problem unformly and securely. My offer to help work on a session management interface (made in a Usenet posting on SMBFS) still stands; there did not seem to be a lot of interest in resolving the general problem, when a kludge soloution was so close. 8-(. Regards, 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 Aug 29 11:09:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA23638 for current-outgoing; Thu, 29 Aug 1996 11:09:24 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA23616 for ; Thu, 29 Aug 1996 11:09:19 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA29057; Thu, 29 Aug 1996 10:55:14 -0700 From: Terry Lambert Message-Id: <199608291755.KAA29057@phaeton.artisoft.com> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: George.Scott@cc.monash.edu.au (George Scott) Date: Thu, 29 Aug 1996 10:55:14 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: <199608290300.NAA08388@moa.cc.monash.edu.au> from "George Scott" at Aug 29, 96 01:00:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > The tentative implementation I was favoring used the following model: > > > > 1) Process logical names > > > > o Hung of proc struct of current process > > I'm not sure what this means! > > Could these logicals be accessed as a directory structure in procfs? > Something like /proc/127/env/SHELL which can be read, written and unlinked > to do getenv, setenv and unsetenv respectively for process 127? That's certianly one way of exporting per process information so it can be accessed and manipulated. > This would allow access to be controlled with the normal filesystem mode bits > and would save us from having to have yet another set of system calls to > implemented. The down side would be that having a procfs mounted would be > almost mandatory. The same argument gould be used to boundlessly expand the use of ioctl();s on the procfs, and throw out all the process tracing system calls, etc.. > While I'm at it, creating a /proc/127/parent as a link to /proc/125 (meaning > that pid 125 is the parent of pid 127) would allow neat things such as shell > scripts that could set their parents environment variables with a simple: > > echo "new value" >/proc/curproc/parent/env/PATH Yes; the main problem is establishing external control of the environment, however. Once that is done, then the door has been opened to a lot of uses and export implementations. 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 Aug 29 11:35:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA25633 for current-outgoing; Thu, 29 Aug 1996 11:35:06 -0700 (PDT) Received: from shadows.aeon.net (freebsd@shadows.aeon.net [194.100.41.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA25605 for ; Thu, 29 Aug 1996 11:34:59 -0700 (PDT) Received: (from freebsd@localhost) by shadows.aeon.net (8.7.5/8.6.9) id VAA05153 for freebsd-current@freebsd.org; Thu, 29 Aug 1996 21:35:12 +0300 (EET DST) From: Mr Operating System Message-Id: <199608291835.VAA05153@shadows.aeon.net> Subject: kernel and adaptec? To: freebsd-current@freebsd.org Date: Thu, 29 Aug 1996 21:35:12 +0300 (EET DST) 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk seems to me kernel srcs have serious problems with adaptec stuff... *shrug* i just updated my non scsi kernel and binaries to the latest sup, but i cant make scsi kernel... aha1542.o: Undefined symbol `_scsi_uto3b' referenced from text segment aha1542.o: Undefined symbol `_scsi_uto3b' referenced from text segment aha1542.o: Undefined symbol `_scsi_uto3b' referenced from text segment aha1542.o: Undefined symbol `_scsi_uto3b' referenced from text segment aha1542.o: More undefined symbol _scsi_uto3b refs follow aha1542.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_scsi_alloc_bus' referenced from text segment aic7xxx.o: Undefined symbol `_scsi_attachdevs' referenced from text segment aic7xxx.o: Undefined symbol `_scsi_alloc_bus' referenced from text segment aic7xxx.o: Undefined symbol `_scsi_attachdevs' referenced from text segment aic7xxx.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_sc_print_addr' referenced from text segment aic7xxx.o: Undefined symbol `_scsi_done' referenced from text segment aic7xxx.o: More undefined symbol _sc_print_addr refs follow *** Error code 1 Stop. that's only the end of the flood... ideas? fixes? mickey From owner-freebsd-current Thu Aug 29 12:14:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27748 for current-outgoing; Thu, 29 Aug 1996 12:14:21 -0700 (PDT) Received: from applink.applink.net (root@applink.applink.net [206.149.40.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA27742 for ; Thu, 29 Aug 1996 12:14:18 -0700 (PDT) From: eagle@applink.applink.net Received: from eagle.applink.net.applink.net (eagle.applink.net [206.149.40.181]) by applink.applink.net (8.6.12/8.6.12) with SMTP id OAA04776 for ; Thu, 29 Aug 1996 14:14:30 -0500 Message-Id: <199608291914.OAA04776@applink.applink.net> Comments: Authenticated sender is To: current@freebsd.org Date: Thu, 29 Aug 1996 14:14:57 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: building current Priority: normal X-mailer: Pegasus Mail for Win32 (v2.32a) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am trying to build current from a 2.1.5 system make world keeps crashing saying that somthing or other /g++/gnr i think is an directory.. kernel wont config.. it says that %SFILES in default makefile is invalid.. do i need to install the current 2.2 image before i compile current? From owner-freebsd-current Thu Aug 29 13:15:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02178 for current-outgoing; Thu, 29 Aug 1996 13:15:25 -0700 (PDT) Received: from mickey.umiacs.umd.edu (mickey.umiacs.umd.edu [128.8.120.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA02165 for ; Thu, 29 Aug 1996 13:15:22 -0700 (PDT) Received: (smpatel@localhost) by mickey.umiacs.umd.edu (8.7.5/UMIACS-0.9/04-05-88) id QAA02197; Thu, 29 Aug 1996 16:15:06 -0400 (EDT) Date: Thu, 29 Aug 1996 16:15:06 -0400 (EDT) From: Sujal Patel To: "Rodney W. Grimes" cc: Peter Wemm , current@freebsd.org Subject: Re: cvs commit: src/usr.sbin/bind - Imported sources In-Reply-To: <199608292001.NAA01710@GndRsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 29 Aug 1996, Rodney W. Grimes wrote: > GAG!!! This violates the BSD src tree paradigm of having the src tree > layout reflect the installtion directory and your going to have to > do a bunch of BINDIR=blah blah to make this work.... > > host, dig go in src/usr.bin > named, ndc, nslookup go in src/usr.sbin > named-xfer goes in src/libexec can we somehow have some symlinks from the "correct" spot to the spot in the source tree. This has already become a problem with GNU software (I can't always remember what's GNU and what isn't :-) Sujal From owner-freebsd-current Thu Aug 29 13:24:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02803 for current-outgoing; Thu, 29 Aug 1996 13:24:41 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA02796 for ; Thu, 29 Aug 1996 13:24:28 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id EAA02973; Fri, 30 Aug 1996 04:21:26 +0800 (WST) Message-Id: <199608292021.EAA02973@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: Sujal Patel cc: "Rodney W. Grimes" , Peter Wemm , current@freebsd.org Subject: Re: cvs commit: src/usr.sbin/bind - Imported sources In-reply-to: Your message of "Thu, 29 Aug 1996 16:15:06 -0400." Date: Fri, 30 Aug 1996 04:21:25 +0800 From: Peter Wemm Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sujal Patel wrote: > On Thu, 29 Aug 1996, Rodney W. Grimes wrote: > > > GAG!!! This violates the BSD src tree paradigm of having the src tree > > layout reflect the installtion directory and your going to have to > > do a bunch of BINDIR=blah blah to make this work.... > > > > host, dig go in src/usr.bin > > named, ndc, nslookup go in src/usr.sbin > > named-xfer goes in src/libexec > > can we somehow have some symlinks from the "correct" spot to the spot in > the source tree. This has already become a problem with GNU software (I > can't always remember what's GNU and what isn't :-) > > Sujal Just a followup on what I said before.. I realise that just because the tree layout isn't completely pure elsewhere doesn't make this "ok" automatically. My defence was that I wasn't the first.. No, symlinks dont come through CVS, so it'll have to be moved if that's what is the right thing to do (which I'm happy to do). Cheers, -Peter From owner-freebsd-current Thu Aug 29 13:26:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02917 for current-outgoing; Thu, 29 Aug 1996 13:26:29 -0700 (PDT) Received: from mickey.umiacs.umd.edu (mickey.umiacs.umd.edu [128.8.120.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA02912 for ; Thu, 29 Aug 1996 13:26:26 -0700 (PDT) Received: (smpatel@localhost) by mickey.umiacs.umd.edu (8.7.5/UMIACS-0.9/04-05-88) id QAA02533; Thu, 29 Aug 1996 16:26:16 -0400 (EDT) Date: Thu, 29 Aug 1996 16:26:16 -0400 (EDT) From: Sujal Patel To: Peter Wemm cc: "Rodney W. Grimes" , current@freebsd.org Subject: Re: cvs commit: src/usr.sbin/bind - Imported sources In-Reply-To: <199608292021.EAA02973@spinner.DIALix.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 30 Aug 1996, Peter Wemm wrote: > Just a followup on what I said before.. I realise that just because the > tree layout isn't completely pure elsewhere doesn't make this "ok" > automatically. My defence was that I wasn't the first.. I understand that this particular case may not be "ok", but for other distributions like tcl that live in contrib, it would nice to have a symlink from /usr/src/usr.bin/tclsh (maybe). > No, symlinks dont come through CVS, so it'll have to be moved if that's > what is the right thing to do (which I'm happy to do). I know that they don't work with CVS, but perhaps there is something we can do to make the source tree that we send out with the distributions have the right symlinks? Maybe a "make src_links" in the makefile? Sujal From owner-freebsd-current Thu Aug 29 13:37:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA03515 for current-outgoing; Thu, 29 Aug 1996 13:37:10 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA03503 for ; Thu, 29 Aug 1996 13:37:03 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA08116; Thu, 29 Aug 1996 14:36:44 -0600 (MDT) Date: Thu, 29 Aug 1996 14:36:44 -0600 (MDT) Message-Id: <199608292036.OAA08116@rocky.mt.sri.com> From: Nate Williams To: Sujal Patel Cc: "Rodney W. Grimes" , Peter Wemm , current@freebsd.org Subject: Re: cvs commit: src/usr.sbin/bind - Imported sources In-Reply-To: References: <199608292001.NAA01710@GndRsh.aac.dev.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sujal Patel writes: > On Thu, 29 Aug 1996, Rodney W. Grimes wrote: > > > GAG!!! This violates the BSD src tree paradigm of having the src tree > > layout reflect the installtion directory and your going to have to > > do a bunch of BINDIR=blah blah to make this work.... > > > > host, dig go in src/usr.bin > > named, ndc, nslookup go in src/usr.sbin > > named-xfer goes in src/libexec > > can we somehow have some symlinks from the "correct" spot to the spot in > the source tree. CVS doesn't support symlinks. Nate From owner-freebsd-current Thu Aug 29 14:00:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04592 for current-outgoing; Thu, 29 Aug 1996 14:00:21 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA04586 for ; Thu, 29 Aug 1996 14:00:16 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id EAA03454; Fri, 30 Aug 1996 04:59:57 +0800 (WST) Message-Id: <199608292059.EAA03454@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: Sujal Patel cc: "Rodney W. Grimes" , current@freebsd.org Subject: Re: cvs commit: src/usr.sbin/bind - Imported sources In-reply-to: Your message of "Thu, 29 Aug 1996 16:26:16 -0400." Date: Fri, 30 Aug 1996 04:59:57 +0800 From: Peter Wemm Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sujal Patel wrote: > On Fri, 30 Aug 1996, Peter Wemm wrote: > > Just a followup on what I said before.. I realise that just because the > > tree layout isn't completely pure elsewhere doesn't make this "ok" > > automatically. My defence was that I wasn't the first.. > > I understand that this particular case may not be "ok", but for other > distributions like tcl that live in contrib, it would nice to have a > symlink from /usr/src/usr.bin/tclsh (maybe). Incidently, the ncurses kit that I sent out to a few people does the same thing for similar reasons... The utilities that come with it access pretty deep into the internals of the library that are not exported to the public. One cannot easily arrange to have the usr.bin components built unless the lib components are already built and up to date. On the other hand, if it's a case of "compile time is irrelevant, take as long as you like", the machine generated internals could be duplicated and built in each of the directories that has ncurses components in it. BTW: other examples of places where packages are grouped together in the place of their primary function: gnu/libexec/uucp installs in /usr/bin, /usr/sbin, /usr/libexec gnu/usr.bin/cc installs in /usr/bin, /usr/libexec gnu/usr.bin/ld installs in /usr/bin, /usr/libexec libexec/bootbd installs in /usr/libexec, /usr/sbin usr.bin/lex installs in /usr/bin, /usr/lib usr.bin/locale installs in /usr/bin, /usr/libexec usr.bin/vgrind installs in /usr/bin, /usr/libexec usr.bin/xlint installs in /usr/bin, /usr/libexec usr.sbin/cron installs in /usr/sbin, /usr/bin usr.sbin/crunch installs in /usr/bin (!) usr.sbin/lpr installs in /usr/libexec, /usr/bin usr.sbin/sendmail installs in /usr/sbin, /usr/bin, /usr/libexec usr.sbin/xntpd installs in /usr/sbin, /usr/bin the old usr.sbin/named installed in /usr/sbin, /usr/libexec -Peter From owner-freebsd-current Thu Aug 29 14:09:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA05358 for current-outgoing; Thu, 29 Aug 1996 14:09:10 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA05350 for ; Thu, 29 Aug 1996 14:09:06 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id OAA01875; Thu, 29 Aug 1996 14:08:56 -0700 From: "Rodney W. Grimes" Message-Id: <199608292108.OAA01875@GndRsh.aac.dev.com> Subject: Re: cvs commit: src/usr.sbin/bind - Imported sources To: smpatel@umiacs.umd.edu (Sujal Patel) Date: Thu, 29 Aug 1996 14:08:56 -0700 (PDT) Cc: peter@freefall.freebsd.org, current@freebsd.org In-Reply-To: from Sujal Patel at "Aug 29, 96 04:15:06 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Thu, 29 Aug 1996, Rodney W. Grimes wrote: > > > GAG!!! This violates the BSD src tree paradigm of having the src tree > > layout reflect the installtion directory and your going to have to > > do a bunch of BINDIR=blah blah to make this work.... > > > > host, dig go in src/usr.bin > > named, ndc, nslookup go in src/usr.sbin > > named-xfer goes in src/libexec > > can we somehow have some symlinks from the "correct" spot to the spot in > the source tree. This has already become a problem with GNU software (I > can't always remember what's GNU and what isn't :-) Sorry now, we did that once, back in the 1.0 days, we even hacked CVS up to handle symlinks, it was a mess, it has been abandon as a solution. You might try this: set cdpath=(/sys/{i386,} /usr/src/{bin,sbin,usr.{bin,sbin},lib,libexec,share,contrib,etc,games,gnu/{games,include,lib,libexec,usr.bin,usr.sbin,},include,}) Then a ``cd blah'' will get you to the right place.... except now that bind has been imported this way you need to add usr.sbin/bind to that list... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Aug 29 14:17:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA05785 for current-outgoing; Thu, 29 Aug 1996 14:17:23 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA05773 for ; Thu, 29 Aug 1996 14:17:16 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id OAA01914; Thu, 29 Aug 1996 14:16:54 -0700 From: "Rodney W. Grimes" Message-Id: <199608292116.OAA01914@GndRsh.aac.dev.com> Subject: Re: cvs commit: src/usr.sbin/bind - Imported sources To: peter@spinner.DIALix.COM (Peter Wemm) Date: Thu, 29 Aug 1996 14:16:54 -0700 (PDT) Cc: smpatel@umiacs.umd.edu, current@freebsd.org In-Reply-To: <199608292059.EAA03454@spinner.DIALix.COM> from Peter Wemm at "Aug 30, 96 04:59:57 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ... > BTW: other examples of places where packages are grouped together in the > place of their primary function: > gnu/libexec/uucp installs in /usr/bin, /usr/sbin, /usr/libexec > gnu/usr.bin/cc installs in /usr/bin, /usr/libexec > gnu/usr.bin/ld installs in /usr/bin, /usr/libexec > libexec/bootbd installs in /usr/libexec, /usr/sbin > usr.bin/lex installs in /usr/bin, /usr/lib > usr.bin/locale installs in /usr/bin, /usr/libexec > usr.bin/vgrind installs in /usr/bin, /usr/libexec > usr.bin/xlint installs in /usr/bin, /usr/libexec > usr.sbin/cron installs in /usr/sbin, /usr/bin > usr.sbin/crunch installs in /usr/bin (!) > usr.sbin/lpr installs in /usr/libexec, /usr/bin > usr.sbin/sendmail installs in /usr/sbin, /usr/bin, /usr/libexec > usr.sbin/xntpd installs in /usr/sbin, /usr/bin > the old usr.sbin/named installed in /usr/sbin, /usr/libexec But _none_ of that is using the new src/contrib model, and I though that this is one of the nice things that could be fixed by that model. There _is_ a common place to reference from for all of these, src/contrib/foobar. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Aug 29 16:57:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA17154 for current-outgoing; Thu, 29 Aug 1996 16:57:13 -0700 (PDT) Received: from sting.artisoft.com (sting.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA17147 for ; Thu, 29 Aug 1996 16:57:09 -0700 (PDT) Received: (from mday@localhost) by sting.artisoft.com (8.7.5/8.7.3) id QAA16536 for freebsd-current@FreeBSD.org; Thu, 29 Aug 1996 16:56:36 -0700 (MST) Date: Thu, 29 Aug 1996 16:56:36 -0700 (MST) From: Matt Day Message-Id: <199608292356.QAA16536@sting.artisoft.com> To: freebsd-current@FreeBSD.org Subject: Re: SAMBA Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > Matt Day wrote: > > If you want to mount Win95 drives from a FreeBSD system, please > > don't wait for CIFS - CIFS won't be ready for months, at least. > > Instead, port or write ksmbfs for FreeBSD! The ksmbfs kernel module > > for Linux (in Samba's contributed section) already provides the > > capability to mount SMB volumes from Linux. (Unfortunately, you > > can't NFS export stuff mounted by ksmbfs, due to limitations.) > > Getting ksmbfs on FreeBSD would also be a great way to help prepare > > FreeBSD for CIFS. > > > > Download ksmbfs from: > > ftp://samba.anu.edu.au/pub/samba/contributed/ksmbfs-0.2.4.tgz > > How do you resolve: > > 1) It's GPL'ed code > > 2) It does not allow per-user enforcement of credential mapping > > The first is not really a kicker if it's distributed as an LKM, and the > LKM is not distributed pre-loaded. Its just that you can't sell or > even give away the agregate system because of the license conflicts. > > > The second is a serious issue, since it damages the SMB server > administrators management authority to have all users from a given > UNIX box appear as as a single SMB client. This was my objection > to the SMBFS suggestions I have seen in the past. > > [.. Terry's examination of authentication problem deleted ..] The authentication problem is certainly a difficult one to solve well, but I don't think it's an smbfs show-stopper. If someone out there is considering porting/writing smbfs for FreeBSD, my advice regarding the authentication issues is this: ignore them, for now. Getting an smbfs working to the point where one can mount an SMB volume and read/write files is enough of a challenge, and such an smbfs would be very valuable to many FreeBSD users (including me!). Lots of people want to share files between FreeBSD and SMB servers, but only a portion of those people care about security. So after the file sharing piece is working, we can deal with the security issues. Hopefully by then the CIFS guys will have come up with a way to do it, and we can just adopt their way and be even closer to being compatible with CIFS. The GPL issue is hardly worth thinking about. Rewrite the code under the Berkeley license if you like, or put the code under sys/gnu, like the ext2fs stuff. Matt Day From owner-freebsd-current Thu Aug 29 17:56:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA20382 for current-outgoing; Thu, 29 Aug 1996 17:56:18 -0700 (PDT) Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA20375 for ; Thu, 29 Aug 1996 17:56:13 -0700 (PDT) Received: (from ernie@localhost) by spooky.eis.net.au (8.7.5/8.6.12) id KAA19849 for freebsd-current@freebsd.org; Fri, 30 Aug 1996 10:55:38 +1000 (EST) From: Ernie Elu Message-Id: <199608300055.KAA19849@spooky.eis.net.au> Subject: newfs typo To: freebsd-current@freebsd.org Date: Fri, 30 Aug 1996 10:55:38 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just noticed an error in either newfs ot it's man page. It says in the paragraph that discribes the -i option that the default for newfs is 1 inode per 2048 bytes, in fact it seems to be one inode per 4096 bytes. I just ran out of inodes on my news server and I noticed the error. - Ernie. From owner-freebsd-current Thu Aug 29 21:18:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA03655 for current-outgoing; Thu, 29 Aug 1996 21:18:53 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (daemon@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA03643 for ; Thu, 29 Aug 1996 21:18:46 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.7.5/8.7.3) id OAA17477 for current@freebsd.org; Fri, 30 Aug 1996 14:18:37 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id OAA27053 for ; Fri, 30 Aug 1996 14:20:04 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id EAA05617 for ; Fri, 30 Aug 1996 04:21:28 GMT Message-Id: <199608300421.EAA05617@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: current@freebsd.org Subject: Makefile error in libc_r X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Aug 1996 14:21:28 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk rec_comp.c is not around anymore (net/Makefile.inc), which gives the following during a make world # make depend make: don't know how to make res_comp.c. Stop # pwd /usr/src/lib/libc_r Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-current Thu Aug 29 23:52:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA13793 for current-outgoing; Thu, 29 Aug 1996 23:52:46 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA13780 for ; Thu, 29 Aug 1996 23:52:43 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA24010; Fri, 30 Aug 1996 08:51:55 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA28878; Fri, 30 Aug 1996 08:51:54 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id IAA29143; Fri, 30 Aug 1996 08:49:33 +0200 (MET DST) From: J Wunsch Message-Id: <199608300649.IAA29143@uriah.heep.sax.de> Subject: Re: kernel and adaptec? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 30 Aug 1996 08:49:33 +0200 (MET DST) Cc: freebsd@shadows.aeon.net (Mr Operating System) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199608291835.VAA05153@shadows.aeon.net> from Mr Operating System at "Aug 29, 96 09:35:12 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Mr Operating System wrote: > i just updated my non scsi kernel and binaries to the latest sup, > but i cant make scsi kernel... > > aha1542.o: Undefined symbol `_scsi_uto3b' referenced from text segment > aha1542.o: Undefined symbol `_scsi_uto3b' referenced from text segment I think you forgot to include the generic SCSI code in your config file: controller scbus0 device sd0 device st0 device cd0 device od0 -- 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 Fri Aug 30 00:14:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA16428 for current-outgoing; Fri, 30 Aug 1996 00:14:10 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA16414; Fri, 30 Aug 1996 00:14:05 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id JAA05045; Fri, 30 Aug 1996 09:13:23 +0200 (MET DST) To: "Rodney W. Grimes" cc: peter@spinner.DIALix.COM (Peter Wemm), smpatel@umiacs.umd.edu, current@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/bind - Imported sources In-reply-to: Your message of "Thu, 29 Aug 1996 14:16:54 PDT." <199608292116.OAA01914@GndRsh.aac.dev.com> Date: Fri, 30 Aug 1996 09:13:22 +0200 Message-ID: <5043.841389202@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <199608292116.OAA01914@GndRsh.aac.dev.com>, "Rodney W. Grimes" write s: >... >> BTW: other examples of places where packages are grouped together in the >> place of their primary function: >> gnu/libexec/uucp installs in /usr/bin, /usr/sbin, /usr/libexec >> ... > >But _none_ of that is using the new src/contrib model, and I though >that this is one of the nice things that could be fixed by that model. I do agree a little bit with Rod here... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Fri Aug 30 00:25:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA17437 for current-outgoing; Fri, 30 Aug 1996 00:25:41 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA17429 for ; Fri, 30 Aug 1996 00:25:36 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA24820; Fri, 30 Aug 1996 09:23:00 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA29408; Fri, 30 Aug 1996 09:22:59 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA29378; Fri, 30 Aug 1996 09:02:15 +0200 (MET DST) From: J Wunsch Message-Id: <199608300702.JAA29378@uriah.heep.sax.de> Subject: Re: Problem with partition size on IDE drive and -current To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 30 Aug 1996 09:02:14 +0200 (MET DST) Cc: sprice@hiwaay.net (Steve Price) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32250737.41C67EA6@hiwaay.net> from Steve Price at "Aug 28, 96 09:57:59 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Steve Price wrote: > It seems I can only get a 1GB partition on my 2GB drive. Here is > all the relevant info I can think of. > > --------------------------------->8-------------------------------- > steve:~$ df > Filesystem 512-blocks Used Avail Capacity Mounted on > /dev/wd0a 1968668 1309088 502088 72% / > procfs 8 8 0 100% /proc > /dev/wd1c 1985694 1079790 747050 59% /u Dunno whether this is your problem, but creating a file system on the `c' partition is considered no good. If you want a filesystem covering the entire slice/disk, run disklabel -e, clone the `c' line, add the 4.2BSD 1024 8192 numbers, and use the new partition for the filesystem. -- 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 Fri Aug 30 00:56:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA19145 for current-outgoing; Fri, 30 Aug 1996 00:56:26 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [193.91.212.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA19137 for ; Fri, 30 Aug 1996 00:56:17 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail-queue invoked from smtpd); 30 Aug 1996 07:55:46 +0000 (GMT) Received: from localhost (HELO verdi.nethelp.no) (@127.0.0.1) by localhost with SMTP; 30 Aug 1996 07:55:45 +0000 (GMT) To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.org Subject: Re: Problem with partition size on IDE drive and -current In-Reply-To: Your message of "Fri, 30 Aug 1996 09:02:14 +0200 (MET DST)" References: <199608300702.JAA29378@uriah.heep.sax.de> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 30 Aug 1996 09:55:45 +0200 Message-ID: <23523.841391745@verdi.nethelp.no> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Dunno whether this is your problem, but creating a file system on the > `c' partition is considered no good. If you want a filesystem > covering the entire slice/disk, run disklabel -e, clone the `c' line, > add the 4.2BSD 1024 8192 numbers, and use the new partition for the > filesystem. Is there any specific reason why using the c partition is bad when you specifically want a file system to cover the entire disk? I did this many times with SunOS 4.1.x when I was working with that. I never saw a problem. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current Fri Aug 30 01:02:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA19644 for current-outgoing; Fri, 30 Aug 1996 01:02:02 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA19632 for ; Fri, 30 Aug 1996 01:01:58 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id RAA23775; Fri, 30 Aug 1996 17:31:27 +0930 From: Michael Smith Message-Id: <199608300801.RAA23775@genesis.atrad.adelaide.edu.au> Subject: Re: Problem with partition size on IDE drive and -current To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 30 Aug 1996 17:31:26 +0930 (CST) Cc: freebsd-current@FreeBSD.org, sprice@hiwaay.net In-Reply-To: <199608300702.JAA29378@uriah.heep.sax.de> from "J Wunsch" at Aug 30, 96 09:02:14 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch stands accused of saying: > > Dunno whether this is your problem, but creating a file system on the > `c' partition is considered no good. If you want a filesystem This is news to me. When did this become popular? > cheers, J"org -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Fri Aug 30 03:56:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA06065 for current-outgoing; Fri, 30 Aug 1996 03:56:59 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA06057 for ; Fri, 30 Aug 1996 03:56:56 -0700 (PDT) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.7.5/8.6.9) with SMTP id MAA06427 for ; Fri, 30 Aug 1996 12:01:19 +0100 (BST) Date: Fri, 30 Aug 1996 12:01:19 +0100 (BST) From: Developer To: freebsd-current@freebsd.org Subject: File handle -> char* ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any way in which I can pass a routine a file handle and make the data just go into a buffer which I can then use as a char* later? The only way Ive thought of doing it at the moment is saving it to a temp file and then reading it back, but that is very inefficent.. I can`t really do it with a pipe because the function I am calling has side effects and I`d need to fork.. thus losing them.. Any ideas? Regards, Trefor S. From owner-freebsd-current Fri Aug 30 06:11:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA17385 for current-outgoing; Fri, 30 Aug 1996 06:11:25 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA17374; Fri, 30 Aug 1996 06:11:19 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id XAA02481; Fri, 30 Aug 1996 23:08:30 +1000 Date: Fri, 30 Aug 1996 23:08:30 +1000 From: Bruce Evans Message-Id: <199608301308.XAA02481@godzilla.zeta.org.au> To: dyson@freebsd.org Subject: early use of vm by debuggers seems to be broken Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After booting with -d: 1. As I reported before, `w 0xf0000000 0' causes a nonfatal trap. 2. More seriously, `b main', `c', `c' stops correctly at the breakpoint but then causes a fatal memory trap in bcopy. Bruce From owner-freebsd-current Fri Aug 30 06:28:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA18527 for current-outgoing; Fri, 30 Aug 1996 06:28:08 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA18518 for ; Fri, 30 Aug 1996 06:28:06 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [204.214.4.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id GAA05838 for ; Fri, 30 Aug 1996 06:28:05 -0700 (PDT) Received: from max14-161.HiWAAY.net by fly.HiWAAY.net; (5.65/1.1.8.2/21Sep95-1003PM) id AA12828; Fri, 30 Aug 1996 08:26:34 -0500 Message-Id: <3226EBBC.446B9B3D@hiwaay.net> Date: Fri, 30 Aug 1996 08:25:16 -0500 From: Steve Price X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.2-CURRENT i386) Mime-Version: 1.0 To: freebsd-current@FreeBSD.org Cc: joerg_wunsch@uriah.heep.sax.de Subject: Re: Problem with partition size on IDE drive and -current References: <199608300702.JAA29378@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > Dunno whether this is your problem, but creating a file system on the > `c' partition is considered no good. If you want a filesystem > covering the entire slice/disk, run disklabel -e, clone the `c' line, > add the 4.2BSD 1024 8192 numbers, and use the new partition for the > filesystem. > > -- > 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. ;-) Yes it was. It seems that 'c' *is* a special partition that needs to stay but must remain unused. I created an 'a' partition and everything works beautifully. Thanks for the help. Steve From owner-freebsd-current Fri Aug 30 07:26:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA22756 for current-outgoing; Fri, 30 Aug 1996 07:26:16 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA22744 for ; Fri, 30 Aug 1996 07:26:10 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id AAA06236; Sat, 31 Aug 1996 00:21:43 +1000 Date: Sat, 31 Aug 1996 00:21:43 +1000 From: Bruce Evans Message-Id: <199608301421.AAA06236@godzilla.zeta.org.au> To: joerg_wunsch@uriah.heep.sax.de, sthaug@nethelp.no Subject: Re: Problem with partition size on IDE drive and -current Cc: freebsd-current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Is there any specific reason why using the c partition is bad when you >specifically want a file system to cover the entire disk? I did this >many times with SunOS 4.1.x when I was working with that. I never saw >a problem. Error checking is weaker for the c partition. E.g., the c partition can be opened even if the disk label is corrupted, and some drivers don't check the block number for access to it. This might make other errors more serious. Bruce From owner-freebsd-current Fri Aug 30 08:48:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27917 for current-outgoing; Fri, 30 Aug 1996 08:48:36 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA27903 for ; Fri, 30 Aug 1996 08:48:29 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id RAA15836 for ; Fri, 30 Aug 1996 17:43:27 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id RAA27638 for freebsd-current@freefall.cdrom.com; Fri, 30 Aug 1996 17:56:04 +0200 Date: Fri, 30 Aug 1996 17:56:04 +0200 From: Christoph Kukulies Message-Id: <199608301556.RAA27638@gilberto.physik.rwth-aachen.de> To: freebsd-current@freefall.FreeBSD.org Subject: qcam probe with newer kernel fails Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk With a newer kernel (Aug 28) my qcam0 isn't get probed properly any longer. For comparison here an excerpt of dmesg when booting with the old vs. new kernel on the same hardware: FreeBSD 2.2-CURRENT #2: Wed Aug 28 16:37:55 MET DST 1996 kuku@isdn-kukulies.dialup.rwth-aachen.de:/usr/src/sys/compile/MONKTELES Calibrating clock(s) relative to mc146818A clock... i8254 clock: 1252834 Hz 1252834 Hz differs from default of 1193182 Hz by more than 1% CPU: AMD Am5x86 Write-Through (486-class CPU) Origin = "AuthenticAMD" Id = 0x4e4 real memory = 67108864 (65536K bytes) avail memory = 62746624 (61276K bytes) qcam0 not found at 0x378 :-( lpt1 at 0x378-0x37f irq 7 on isa lpt1: Interrupt-driven port lp1: TCP/IP capable interface FreeBSD 2.2-CURRENT #0: Sun Aug 25 12:45:37 MET DST 1996 root@isdn-kukulies.dialup.rwth-aachen.de:/usr/src/sys/compile/MONKTELES Calibrating clock(s) relative to mc146818A clock... i8254 clock: 1205066 Hz CPU: AMD Am5x86 Write-Through (486-class CPU) Origin = "AuthenticAMD" Id = 0x4e4 real memory = 67108864 (65536K bytes) avail memory = 62750720 (61280K bytes) qcam0 at 0x378 on isa :-) qcam0: unidirectional parallel port lpt1 at 0x378-0x37f irq 7 on isa lpt1 not probed due to I/O address conflict with qcam0 at 0x378 This log btw shows the healing patches to the clock calibration code introduced recently :-) --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Fri Aug 30 11:47:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA13626 for current-outgoing; Fri, 30 Aug 1996 11:47:42 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA13619 for ; Fri, 30 Aug 1996 11:47:39 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id UAA17322 for ; Fri, 30 Aug 1996 20:47:35 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id UAA01279 for freebsd-current@FreeBSD.org; Fri, 30 Aug 1996 20:46:46 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.9/keltia-uucp-2.9) id UAA22835; Fri, 30 Aug 1996 20:36:08 +0200 (MET DST) Message-Id: <199608301836.UAA22835@keltia.freenix.fr> Date: Fri, 30 Aug 1996 20:36:08 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-current@FreeBSD.org Subject: Re: File handle -> char* ? In-Reply-To: ; from Developer on Aug 30, 1996 12:01:19 +0100 References: X-Mailer: Mutt 0.41 Mime-Version: 1.0 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Developer: > Is there any way in which I can pass a routine a file handle and make the > data just go into a buffer which I can then use as a char* later? The only mmap(2) is your friend. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 From owner-freebsd-current Fri Aug 30 11:47:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA13638 for current-outgoing; Fri, 30 Aug 1996 11:47:45 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA13620 for ; Fri, 30 Aug 1996 11:47:39 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id UAA17324 for ; Fri, 30 Aug 1996 20:47:36 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id UAA01277 for current@FreeBSD.org; Fri, 30 Aug 1996 20:46:46 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.9/keltia-uucp-2.9) id UAA22771; Fri, 30 Aug 1996 20:27:16 +0200 (MET DST) Message-Id: <199608301827.UAA22771@keltia.freenix.fr> Date: Fri, 30 Aug 1996 20:27:16 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: current@FreeBSD.org Subject: Re: building current In-Reply-To: <199608291914.OAA04776@applink.applink.net>; from eagle@applink.applink.net on Aug 29, 1996 14:14:57 +0000 References: <199608291914.OAA04776@applink.applink.net> X-Mailer: Mutt 0.41 Mime-Version: 1.0 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to eagle@applink.applink.net: > I am trying to build current from a 2.1.5 system > make world keeps crashing saying that somthing or other /g++/gnr i > think is an directory.. I don't know about that one but... > kernel wont config.. > it says that %SFILES in default makefile is invalid.. ... that is easy. ALWAYS get and compile usr.sbin/config BEFORE trying to make a kernel. Sometimes I wonder if we should move config into /sys... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 From owner-freebsd-current Fri Aug 30 11:47:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA13658 for current-outgoing; Fri, 30 Aug 1996 11:47:47 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA13625 for ; Fri, 30 Aug 1996 11:47:42 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id UAA17328 for ; Fri, 30 Aug 1996 20:47:37 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id UAA01278 for freebsd-current@freebsd.org; Fri, 30 Aug 1996 20:46:46 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.9/keltia-uucp-2.9) id UAA22811; Fri, 30 Aug 1996 20:34:30 +0200 (MET DST) Message-Id: <199608301834.UAA22811@keltia.freenix.fr> Date: Fri, 30 Aug 1996 20:34:30 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-current@FreeBSD.org Subject: Re: newfs typo In-Reply-To: <199608300055.KAA19849@spooky.eis.net.au>; from Ernie Elu on Aug 30, 1996 10:55:38 +1000 References: <199608300055.KAA19849@spooky.eis.net.au> X-Mailer: Mutt 0.41 Mime-Version: 1.0 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Ernie Elu: > I just noticed an error in either newfs ot it's man page. > It says in the paragraph that discribes the -i option that the default for > newfs is 1 inode per 2048 bytes, in fact it seems to be one inode per 4096 > bytes. I just ran out of inodes on my news server and I noticed the error. It should be written as: The default is to an inode for 4 (four) times the size of a fragment in bytes. That is, on a 4 KB/512 bytes FS, the default is to create an inode for each 2 KB of data and one for each 4 KB for a 8 KB/1KB FS. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 From owner-freebsd-current Fri Aug 30 13:03:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16534 for current-outgoing; Fri, 30 Aug 1996 13:03:04 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA16508; Fri, 30 Aug 1996 13:02:58 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.6.12/8.6.12) with SMTP id NAA13518; Fri, 30 Aug 1996 13:02:57 -0700 Date: Fri, 30 Aug 1996 13:02:56 -0700 (PDT) From: Jaye Mathisen To: current@freebsd.org, hackers@freebsd.org Subject: How about putting in bind 4.9.4-P1 in the tree? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Seems to work just fine for my stuff, and I hate doing make worlds that I then hav eto go back and re-fix stuff. From owner-freebsd-current Fri Aug 30 13:45:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA20275 for current-outgoing; Fri, 30 Aug 1996 13:45:08 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA20246 for ; Fri, 30 Aug 1996 13:44:47 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id WAA03430; Fri, 30 Aug 1996 22:15:37 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.5/8.7.3) with SMTP id WAA00405; Fri, 30 Aug 1996 22:18:32 +0200 (MET DST) Date: Fri, 30 Aug 1996 22:18:32 +0200 (MET DST) From: Andreas Klemm To: Christoph Kukulies cc: freebsd-current@freefall.freebsd.org Subject: cvsup.de.freebsd.org request In-Reply-To: <199608301556.RAA27638@gilberto.physik.rwth-aachen.de> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 30 Aug 1996, Christoph Kukulies wrote: Would it be possible to create a german (or generally national) cvsup server ... The protocol is great !!! I love it ... The only disadvantage is, that the US servers sometimes aren't good reachable because of net load ... It would be great, if someone could make something like cvsup.de.freebsd.org ... ;-))) Thanks ! Andreas /// -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Fri Aug 30 14:31:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25856 for current-outgoing; Fri, 30 Aug 1996 14:31:55 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA25821; Fri, 30 Aug 1996 14:31:46 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id XAA17479; Fri, 30 Aug 1996 23:31:36 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id XAA02770; Fri, 30 Aug 1996 23:30:35 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.9/keltia-uucp-2.9) id XAA26876; Fri, 30 Aug 1996 23:05:51 +0200 (MET DST) Message-Id: <199608302105.XAA26876@keltia.freenix.fr> Date: Fri, 30 Aug 1996 23:05:51 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: current@freebsd.org, hackers@freebsd.org Subject: Re: How about putting in bind 4.9.4-P1 in the tree? In-Reply-To: ; from Jaye Mathisen on Aug 30, 1996 13:02:56 -0700 References: X-Mailer: Mutt 0.41 Mime-Version: 1.0 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Jaye Mathisen: > Seems to work just fine for my stuff, and I hate doing make worlds that I > then hav eto go back and re-fix stuff. Oh, you mean this one ? I am afraid Peter beat you on it :-) peter 96/08/29 12:43:00 src/usr.sbin/bind - Imported sources peter 96/08/29 13:15:12 Modified: usr.sbin Makefile Log: Swing the SUBDIR entry across for the new bind-4.9.4-p1 dir.. Peter: how about modifying "log_accum.pl" to include contrib/ logs (I know log_accum.pl is a can of worms but it would be nice) ? -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 From owner-freebsd-current Fri Aug 30 15:40:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA03879 for current-outgoing; Fri, 30 Aug 1996 15:40:38 -0700 (PDT) Received: from terra.stack.urc.tue.nl (terra.stack.urc.tue.nl [131.155.140.128]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA03870 for ; Fri, 30 Aug 1996 15:40:35 -0700 (PDT) Received: from xaa.stack.urc.tue.nl (uucp@localhost) by terra.stack.urc.tue.nl (8.7.5) with UUCP id AAA07319; Sat, 31 Aug 1996 00:40:07 +0200 (MET DST) Received: (from freebsd@localhost) by xaa.stack.urc.tue.nl (8.7.5/8.6.12) id AAA02135; Sat, 31 Aug 1996 00:38:10 +0200 (MET DST) From: FreeBSD matters of Mark Huizer (xaa) Message-Id: <199608302238.AAA02135@xaa.stack.urc.tue.nl> Subject: Re: cvsup.de.freebsd.org request In-Reply-To: from Andreas Klemm at "Aug 30, 96 10:18:32 pm" To: andreas@klemm.gtn.com (Andreas Klemm) Date: Sat, 31 Aug 1996 00:38:10 +0200 (MET DST) Cc: kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org Reply-To: xaa@stack.urc.tue.nl (Mark Huizer) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Would it be possible to create a german (or generally > national) cvsup server ... The protocol is great !!! > I love it ... > > The only disadvantage is, that the US servers sometimes > aren't good reachable because of net load ... > > It would be great, if someone could make something > like cvsup.de.freebsd.org ... ;-))) You could try cvsup.nl.freebsd.org It's closer than the USA :-) Mark Huizer From owner-freebsd-current Fri Aug 30 19:12:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA14686 for current-outgoing; Fri, 30 Aug 1996 19:12:03 -0700 (PDT) Received: from dot.ishiboo.com (user@dot.ishiboo.com [208.128.22.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA14670 for ; Fri, 30 Aug 1996 19:12:00 -0700 (PDT) From: nirva@ishiboo.com Received: (qmail-queue invoked by uid 509); 31 Aug 1996 02:11:02 -0000 Message-ID: <19960831021102.21803.qmail@dot.ishiboo.com> Subject: -current make world failure To: freebsd-current@freebsd.org Date: Fri, 30 Aug 1996 20:11:02 -0600 (MDT) X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Going from 2.1.0-RELEASE to -current, make world does this after I did make bootstrap: building shared c library (version 3.0) nm: bt_debug.so: no name list. nm: euc.so: no name list. nm: utf2.so: no name list. res_data.so: Definition of symbol `__res_resultcodes' (multiply defined) res_data.so: Size element definition of symbol `__res_resultcodes' (multiply def ined) res_data.so: Definition of symbol `__res_opcodes' (multiply defined) res_data.so: Size element definition of symbol `__res_opcodes' (multiply defined ) res_debug.so: Definition of symbol `__res_resultcodes' (multiply defined) res_debug.so: Size element definition of symbol `__res_resultcodes' (multiply de fined) res_debug.so: Definition of symbol `__res_opcodes' (multiply defined) res_debug.so: Size element definition of symbol `__res_opcodes' (multiply define d) *** Error code 1 Stop. New one for me, I have never gotten -current to compile cleanly all the way through from 2.1.0-RELEASE. Some minor amount of tweaking is always needed.. but this is beyond me. Doing an nm on the .so, with irrelevant parts clipped, returns: 00000040 ? __res_opcodes 000029d0 D __res_opcodes 00000040 ? __res_resultcodes 00002a10 D __res_resultcodes Suggestions to avoid/solve this problem? --------------------------------------------------------------------------- Danny Dulai Feet. Pumice. Lotion. http://www.ishiboo.com/~nirva/ nirva@ishiboo.com --------------------------------------------------------------------------- From owner-freebsd-current Sat Aug 31 02:51:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA02313 for current-outgoing; Sat, 31 Aug 1996 02:51:51 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA02302 for ; Sat, 31 Aug 1996 02:51:43 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id LAA17846 for ; Sat, 31 Aug 1996 11:51:39 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id LAA09487 for freebsd-current@FreeBSD.ORG; Sat, 31 Aug 1996 11:50:44 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.9/keltia-uucp-2.9) id LAA00327; Sat, 31 Aug 1996 11:49:46 +0200 (MET DST) Message-Id: <199608310949.LAA00327@keltia.freenix.fr> Date: Sat, 31 Aug 1996 11:49:45 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-current@FreeBSD.ORG (FreeBSD Current Users' list) Subject: IPFW changes X-Mailer: Mutt 0.41 Mime-Version: 1.0 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Can anyone tell me what changed in IPFW between Aug, 18th and now ? I just rebooted after "make world" and ipfw rejected one the following rules (without telling me the one but I know it is the first one): add deny all from 127.0.0.0/8 to 0/0 via ppp0 add deny all from 127.0.0.0/8 to 0/0 via tun0 add deny all from 10.0.0.0/8 to 0/0 via ppp0 add deny all from 172.16.0.0/12 to 0/0 via ppp0 add deny all from 192.168.0.0/16 to 0/0 via ppp0 add deny all from 10.0.0.0/8 to 0/0 via tun0 add deny all from 172.16.0.0/12 to 0/0 via tun0 add deny all from 192.168.0.0/16 to 0/0 via tun0 add deny all from 163.5.0.0/16 to 0/0 via tun0 add deny all from 163.5.0.0/16 to 0/0 via ppp0 add deny all from 10.0.0.0/8 to 0/0 via ed0 add deny all from 163.5.0.0/16 to 0/0 via ed0 add deny all from 172.16.0.0/12 to 0/0 via ed0 add deny all from 192.168.0.0/16 to 0/0 via ed0 add accept all from 127.0.0.1 to 127.0.0.1 add accept all from 193.56.58.0/24 to 0/0 via ed0 add accept all from 0/0 to 193.56.58.0/24 via ed0 add 65000 pass all from any to any 201 [11:45] root@keltia:~# ipfw add deny all from 127.0.0.0/8 to 0/0 via ppp0 ipfw: ERROR - ip number It seems that neither "all" nor "ip" is recognized after the "deny"... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 From owner-freebsd-current Sat Aug 31 02:54:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA02408 for current-outgoing; Sat, 31 Aug 1996 02:54:27 -0700 (PDT) Received: from isdn-kukulies.dialup.rwth-aachen.de (isdn-kukulies.dialup.RWTH-Aachen.DE [137.226.145.27]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA02401 for ; Sat, 31 Aug 1996 02:54:14 -0700 (PDT) Received: from isdn-kukulies.dialup.rwth-aachen.de (localhost [127.0.0.1]) by isdn-kukulies.dialup.rwth-aachen.de (8.7.5/8.6.9) with SMTP id MAA23665; Sat, 31 Aug 1996 12:00:56 +0200 (MET DST) Message-ID: <32280D58.794BDF32@gil.physik.rwth-aachen.de> Date: Sat, 31 Aug 1996 12:00:56 +0200 From: "Christoph P. Kukulies" Organization: I. Physikalisches Institut X-Mailer: Mozilla 3.0 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Andreas Klemm CC: Christoph Kukulies , freebsd-current@freefall.freebsd.org Subject: Re: cvsup.de.freebsd.org request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm wrote: > > > > Would it be possible to create a german (or generally > national) cvsup server ... The protocol is great !!! > I love it ... I'm in the course of reorganizing ftp.de.freebsd.org as well as sup.de.freebsd.org (more disk space, faster CPU, more RAM). When done this (hopefully end of September) I'll look into cvsup. > > The only disadvantage is, that the US servers sometimes > aren't good reachable because of net load ... > > It would be great, if someone could make something > like cvsup.de.freebsd.org ... ;-))) > > Thanks ! > > Andreas /// > > -- > andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH > Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de > pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< > ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -- Christoph Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Sat Aug 31 03:00:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA02550 for current-outgoing; Sat, 31 Aug 1996 03:00:15 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA02541; Sat, 31 Aug 1996 03:00:10 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id JAA10724; Sat, 31 Aug 1996 09:59:58 GMT Date: Sat, 31 Aug 1996 18:59:57 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: eric@ms.uky.edu, freebsd-fs@freebsd.org, current@freebsd.org Subject: Re: vclean (was The VIVA file system) In-Reply-To: <199608291616.JAA28774@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 29 Aug 1996, Terry Lambert wrote: > The amount of memeory is relatively small, and we are already running > a modified zone allocator in any case. I don't see any conflict in > the definition of a dditional zones. How do I reclaim packet reassembly > buffer when I need another vnode? Right now, I don't. The conflict > resoloution is intra-pool. Inter-pool conflicts are resolved either > by static resource limits, or soft limits and/or watermarking. I think watermarking is a good model to program to. From the point of view of users you want it see it unless you run into a problem where you need to look at them. I'd like to see some kind of automatic setting of low/high watermarks based on the resources of the computer that can be overridden by the admin. > > > > Say you've got FFS, LFS, and NFS systems mounted and fs usage patterns > > migrate between the fs's. You've got limited memory resources. How do > > you determine which local pool to recover vnodes from? It'd be > > inefficient to leave the pools wired until the fs was unmounted. Complex > > LRU-like policies across multiple local per fs vnode pools also sound > > pretty complicated to me. > > You keep a bias statistic, maintained on a per pool basis, for the > reclaimation, and the reclaimer operates at a pool granularity, if > in fact you allow such reclaimation to occur (see my paragraph preceeding > for preferred approaches to a knowledgable reclaimer). I'd like to revisit this later. I'm not sure I'd want to see the ability to reclaim go away. > > We also need to preserve the vnode revoking semantics for situations like > > revoking the session terminals from the children of sesssion leaders. > > This is a tty subsystem function, and I do not agree with the current > revocation semantics, mostly because I think tty devices should be > instanced per controlling tty reference. This would allow the reference > to be invalidated via flagging rather than using a seperate opv table. > > If you look for "struct fileops", you will see another bogosity that > makes this this problematic. Resolve the struct fileops, and the > carrying around of all that dead weight in the fd structs, and you have > resolved the deadfs problem at the same time. The specfs stuff is going > to go away with devfs, leaving UNIX domain sockets, pipes (which should > be implemented as an opaque FS reference no exported as a mount point > mapping to user space), and the VFS fileops (which should be the only > ones, and therefore implicit, anyway). Hanging the deadfs ops on the vnode seemed like a cool idea even though it looks like a little extra baggage. I guess we can revisit all this again later after the lite2 merge. Regards, Mike Hancock From owner-freebsd-current Sat Aug 31 05:43:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA11828 for current-outgoing; Sat, 31 Aug 1996 05:43:15 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA11821 for ; Sat, 31 Aug 1996 05:43:13 -0700 (PDT) Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id HAA15696; Sat, 31 Aug 1996 07:43:12 -0500 (CDT) Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.13) id ; Sat, 31 Aug 96 07:43 CDT Date: Sat, 31 Aug 1996 07:43:11 -0500 (CDT) From: Alex Nash X-Sender: nash@Venus.mcs.com To: Ollivier Robert cc: "FreeBSD Current Users' list" Subject: Re: IPFW changes In-Reply-To: <199608310949.LAA00327@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Can anyone tell me what changed in IPFW between Aug, 18th and now ? Nothing. > I just rebooted after "make world" and ipfw rejected one the following > rules (without telling me the one but I know it is the first one): > > [...] > > 201 [11:45] root@keltia:~# ipfw add deny all from 127.0.0.0/8 to 0/0 via ppp0 > ipfw: ERROR - ip number > > It seems that neither "all" nor "ip" is recognized after the "deny"... ipfw is complaining that it can't resolve the address '0' which is being caused by the newly merged bind-4.9.4-P1 resolver (merged in 3 days ago). For the time being, use the "any" keyword instead of "0/0". Now the question is: Is it legal to call the resolver with an address of 0? I thought that the default action in such cases is to append ".0"'s to the end of the address until you had a 32-bit address. Alex From owner-freebsd-current Sat Aug 31 09:31:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA24921 for current-outgoing; Sat, 31 Aug 1996 09:31:55 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA24907 for ; Sat, 31 Aug 1996 09:31:50 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id SAA18074 for ; Sat, 31 Aug 1996 18:31:40 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id SAA15922 for freebsd-current@FreeBSD.ORG; Sat, 31 Aug 1996 18:31:10 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.9/keltia-uucp-2.9) id LAA00327; Sat, 31 Aug 1996 11:49:46 +0200 (MET DST) Message-Id: <199608310949.LAA00327@keltia.freenix.fr> Date: Sat, 31 Aug 1996 11:49:45 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-current@FreeBSD.ORG (FreeBSD Current Users' list) Subject: IPFW changes X-Mailer: Mutt 0.41 Mime-Version: 1.0 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Can anyone tell me what changed in IPFW between Aug, 18th and now ? I just rebooted after "make world" and ipfw rejected one the following rules (without telling me the one but I know it is the first one): add deny all from 127.0.0.0/8 to 0/0 via ppp0 add deny all from 127.0.0.0/8 to 0/0 via tun0 add deny all from 10.0.0.0/8 to 0/0 via ppp0 add deny all from 172.16.0.0/12 to 0/0 via ppp0 add deny all from 192.168.0.0/16 to 0/0 via ppp0 add deny all from 10.0.0.0/8 to 0/0 via tun0 add deny all from 172.16.0.0/12 to 0/0 via tun0 add deny all from 192.168.0.0/16 to 0/0 via tun0 add deny all from 163.5.0.0/16 to 0/0 via tun0 add deny all from 163.5.0.0/16 to 0/0 via ppp0 add deny all from 10.0.0.0/8 to 0/0 via ed0 add deny all from 163.5.0.0/16 to 0/0 via ed0 add deny all from 172.16.0.0/12 to 0/0 via ed0 add deny all from 192.168.0.0/16 to 0/0 via ed0 add accept all from 127.0.0.1 to 127.0.0.1 add accept all from 193.56.58.0/24 to 0/0 via ed0 add accept all from 0/0 to 193.56.58.0/24 via ed0 add 65000 pass all from any to any 201 [11:45] root@keltia:~# ipfw add deny all from 127.0.0.0/8 to 0/0 via ppp0 ipfw: ERROR - ip number It seems that neither "all" nor "ip" is recognized after the "deny"... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 From owner-freebsd-current Sat Aug 31 10:01:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA28434 for current-outgoing; Sat, 31 Aug 1996 10:01:27 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA28406 for ; Sat, 31 Aug 1996 10:01:18 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id TAA18094 for ; Sat, 31 Aug 1996 19:01:10 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id TAA16233 for freebsd-current@FreeBSD.org; Sat, 31 Aug 1996 19:00:42 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.9/keltia-uucp-2.9) id SAA01875; Sat, 31 Aug 1996 18:55:01 +0200 (MET DST) Message-Id: <199608311655.SAA01875@keltia.freenix.fr> Date: Sat, 31 Aug 1996 18:55:01 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-current@FreeBSD.org (FreeBSD Current Users' list) Subject: Re: IPFW changes In-Reply-To: ; from Alex Nash on Aug 31, 1996 7:43:11 -0500 References: X-Mailer: Mutt 0.41 Mime-Version: 1.0 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Alex Nash: > ipfw is complaining that it can't resolve the address '0' which is > being caused by the newly merged bind-4.9.4-P1 resolver (merged in 3 > days ago). For the time being, use the "any" keyword instead of > "0/0". OK, that's working now. Another question, why the sysctl variables for IPFW not there ? 239 [18:47] root@keltia:/sys/netinet# sysctl net.inet.ip net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.last: 5000 net.inet.ip.portrange.hifirst: 40000 net.inet.ip.portrange.hilast: 44999 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.subnets_are_local: 1 They're defined in ip_fw.c but they do not appear with sysctl... SYSCTL_NODE(net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); SYSCTL_INT(net_inet_ip_fw, OID_AUTO, debug, CTLFLAG_RW, &fw_debug, 0, ""); SYSCTL_INT(net_inet_ip_fw, OID_AUTO, verbose, CTLFLAG_RW, &fw_verbose, 0, ""); SYSCTL_INT(net_inet_ip_fw, OID_AUTO, verbose_limit, CTLFLAG_RW, &fw_verbose_limit, 0, ""); Note: I don't use it as LKM but directly within the kernel... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #20: Fri Aug 30 23:00:02 MET DST 1996 From owner-freebsd-current Sat Aug 31 10:30:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA01063 for current-outgoing; Sat, 31 Aug 1996 10:30:48 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA01058 for ; Sat, 31 Aug 1996 10:30:46 -0700 (PDT) Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id MAA22745; Sat, 31 Aug 1996 12:30:45 -0500 (CDT) Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.13) id ; Sat, 31 Aug 96 12:30 CDT Date: Sat, 31 Aug 1996 12:30:44 -0500 (CDT) From: Alex Nash X-Sender: nash@Venus.mcs.com To: Ollivier Robert cc: "FreeBSD Current Users' list" Subject: Re: IPFW changes In-Reply-To: <199608311655.SAA01875@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 Aug 1996, Ollivier Robert wrote: > According to Alex Nash: > > ipfw is complaining that it can't resolve the address '0' which is > > being caused by the newly merged bind-4.9.4-P1 resolver (merged in 3 > > days ago). For the time being, use the "any" keyword instead of > > "0/0". > > OK, that's working now. > > Another question, why the sysctl variables for IPFW not there ? This was on my TODO list from several months ago :( Any sysctl experts out there want to give this a shot? Alex From owner-freebsd-current Sat Aug 31 10:42:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA01989 for current-outgoing; Sat, 31 Aug 1996 10:42:52 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA01980; Sat, 31 Aug 1996 10:42:48 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id JAA10437; Sat, 31 Aug 1996 09:48:11 +0200 (MET DST) To: Alex Nash cc: Ollivier Robert , "FreeBSD Current Users' list" Subject: Re: IPFW changes In-reply-to: Your message of "Sat, 31 Aug 1996 12:30:44 CDT." Date: Sat, 31 Aug 1996 09:48:11 +0200 Message-ID: <10435.841477691@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message , Alex Nash writes: >> Another question, why the sysctl variables for IPFW not there ? > >This was on my TODO list from several months ago :( Any sysctl experts >out there want to give this a shot? I'll look at it. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Sat Aug 31 12:21:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA06931 for current-outgoing; Sat, 31 Aug 1996 12:21:55 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA06926 for ; Sat, 31 Aug 1996 12:21:51 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA03889; Sun, 1 Sep 1996 05:18:32 +1000 Date: Sun, 1 Sep 1996 05:18:32 +1000 From: Bruce Evans Message-Id: <199608311918.FAA03889@godzilla.zeta.org.au> To: adam@veda.is Subject: Re: bin/1560: Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > /usr/include/termcap.h declares tputs() as type void, whereas in > /usr/include/*curses.h it says an integer is returned. This results > in a type conflict and programs don't compile. Someone "cleaned up" the termcap version. It used to return a garbage int. Bruce From owner-freebsd-current Sat Aug 31 12:25:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA07029 for current-outgoing; Sat, 31 Aug 1996 12:25:45 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA07023 for ; Sat, 31 Aug 1996 12:25:39 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id VAA02870; Sat, 31 Aug 1996 21:00:38 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.5/8.7.3) with SMTP id SAA00349; Sat, 31 Aug 1996 18:54:26 +0200 (MET DST) Date: Sat, 31 Aug 1996 18:54:26 +0200 (MET DST) From: Andreas Klemm To: "Christoph P. Kukulies" cc: freebsd-current@freefall.freebsd.org Subject: Re: cvsup.de.freebsd.org request In-Reply-To: <32280D58.794BDF32@gil.physik.rwth-aachen.de> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 Aug 1996, Christoph P. Kukulies wrote: > I'm in the course of reorganizing ftp.de.freebsd.org as well as > sup.de.freebsd.org (more disk space, faster CPU, more RAM). > When done this (hopefully end of September) I'll look into > cvsup. This would be very fine, thanks. Andreas /// -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Sat Aug 31 12:35:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA07317 for current-outgoing; Sat, 31 Aug 1996 12:35:21 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA07309; Sat, 31 Aug 1996 12:35:17 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id VAA10611; Sat, 31 Aug 1996 21:34:51 +0200 (MET DST) To: Alex Nash cc: Ollivier Robert , "FreeBSD Current Users' list" Subject: Re: IPFW changes In-reply-to: Your message of "Sat, 31 Aug 1996 12:30:44 CDT." Date: Sat, 31 Aug 1996 21:34:51 +0200 Message-ID: <10609.841520091@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message , Alex Nash writes: >On Sat, 31 Aug 1996, Ollivier Robert wrote: >> Another question, why the sysctl variables for IPFW not there ? > >This was on my TODO list from several months ago :( Any sysctl experts >out there want to give this a shot? Try this patch: Index: ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.48 diff -u -r1.48 ip_fw.c --- ip_fw.c 1996/08/13 19:43:40 1.48 +++ ip_fw.c 1996/08/31 19:33:37 @@ -57,10 +57,10 @@ LIST_HEAD (ip_fw_head, ip_fw_chain) ip_fw_chain; #ifdef SYSCTL_NODE -SYSCTL_NODE(net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); -SYSCTL_INT(net_inet_ip_fw, OID_AUTO, debug, CTLFLAG_RW, &fw_debug, 0, ""); -SYSCTL_INT(net_inet_ip_fw, OID_AUTO, verbose, CTLFLAG_RW, &fw_verbose, 0, ""); -SYSCTL_INT(net_inet_ip_fw, OID_AUTO, verbose_limit, CTLFLAG_RW, &fw_verbose_limit, 0, ""); +SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, debug, CTLFLAG_RW, &fw_debug, 0, ""); +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose, CTLFLAG_RW, &fw_verbose, 0, ""); +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose_limit, CTLFLAG_RW, &fw_verbose_limit, 0, ""); #endif #define dprintf(a) if (!fw_debug); else printf a -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Sat Aug 31 14:03:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA11808 for current-outgoing; Sat, 31 Aug 1996 14:03:12 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA11803 for ; Sat, 31 Aug 1996 14:03:09 -0700 (PDT) Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id QAA26958; Sat, 31 Aug 1996 16:03:02 -0500 (CDT) Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.13) id ; Sat, 31 Aug 96 16:03 CDT Date: Sat, 31 Aug 1996 16:03:01 -0500 (CDT) From: Alex Nash X-Sender: nash@Venus.mcs.com To: Poul-Henning Kamp cc: Ollivier Robert , "FreeBSD Current Users' list" Subject: Re: IPFW changes In-Reply-To: <10609.841520091@critter.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 Aug 1996, Poul-Henning Kamp wrote: > >> Another question, why the sysctl variables for IPFW not there ? > > > >This was on my TODO list from several months ago :( Any sysctl experts > >out there want to give this a shot? > > Try this patch: Worked like a charm. I'll check this in right now. Alex From owner-freebsd-current Sat Aug 31 15:50:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA22745 for current-outgoing; Sat, 31 Aug 1996 15:50:46 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA22740 for ; Sat, 31 Aug 1996 15:50:40 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.7.5/8.7.3) id WAA28955; Sat, 31 Aug 1996 22:50:18 GMT From: Adam David Message-Id: <199608312250.WAA28955@veda.is> Subject: Re: bin/1560: To: bde@zeta.org.au (Bruce Evans) Date: Sat, 31 Aug 1996 22:50:16 +0000 (GMT) Cc: current@freebsd.org In-Reply-To: <199608311918.FAA03889@godzilla.zeta.org.au> from Bruce Evans at "Sep 1, 96 05:18:32 am" 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > /usr/include/termcap.h declares tputs() as type void, whereas in > > /usr/include/*curses.h it says an integer is returned. This results > > in a type conflict and programs don't compile. > > Someone "cleaned up" the termcap version. It used to return a garbage > int. > > Bruce > Uh, this means *curses needs to be brought into sync, right? Adam From owner-freebsd-current Sat Aug 31 17:27:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA26471 for current-outgoing; Sat, 31 Aug 1996 17:27:51 -0700 (PDT) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA26462 for ; Sat, 31 Aug 1996 17:27:49 -0700 (PDT) Received: by sequent.kiae.su id AA06299 (5.65.kiae-2 ); Sun, 1 Sep 1996 04:25:10 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sun, 1 Sep 96 04:25:10 +0400 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id EAA04448; Sun, 1 Sep 1996 04:21:09 +0400 (MSD) Message-Id: <199609010021.EAA04448@nagual.ru> Subject: Re: bin/1560: In-Reply-To: <199608312250.WAA28955@veda.is> from "Adam David" at "Aug 31, 96 10:50:16 pm" To: adam@veda.is (Adam David) Date: Sun, 1 Sep 1996 04:21:08 +0400 (MSD) Cc: bde@zeta.org.au, current@FreeBSD.ORG From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL25 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > /usr/include/termcap.h declares tputs() as type void, whereas in > > > /usr/include/*curses.h it says an integer is returned. This results > > > in a type conflict and programs don't compile. > > > > Someone "cleaned up" the termcap version. It used to return a garbage > > int. > > > > Bruce > > > > Uh, this means *curses needs to be brought into sync, right? Ncurses declare it as void too. Old curses+termlib will be removed in future. -- Andrey A. Chernov http://www.nagual.ru/~ache/