From owner-freebsd-stable Sun May 12 20:05:53 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA06948 for stable-outgoing; Sun, 12 May 1996 20:05:53 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA06931 for ; Sun, 12 May 1996 20:05:48 -0700 (PDT) Received: (from imp@localhost) by rover.village.org (8.7.5/8.6.6) id VAA00436; Sun, 12 May 1996 21:05:44 -0600 (MDT) Date: Sun, 12 May 1996 21:05:44 -0600 (MDT) From: Warner Losh Message-Id: <199605130305.VAA00436@rover.village.org> To: stable@freebsd.org Subject: ext2fs patches -- bad news Cc: dworkin@rover.village.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk OK. I didn't get *ANY* mail from my mailing lists for the last 48 houts. Why? I'm not 100% sure. I was seeing odd things happening. refile wasn't working. It would unlink from my inbox, but never link in my destination file. Ditto my slocal script. Ditto mv!!!! So, I've backed out the kernel that I built with the ext2fs file system stuff and won't be making patches available. In fact, I'd *STRONGLY* suggest that a good fs kernel hacker take a good, long look at the code. I think I'd see the same sorts of things if I was running -current given the nature of the changes of the code. On a related note, does anybody know how to tell FreeBSD to force fsck to *ALWAYS*ALWAYS*ALWAYS* fsck the disk, ignoring the Clean flag? I found about 10 very large files that weren't referenced anywhere and I had assumed the dialy cron job output was merely reporting the tmp files that were for the batch jobs running at the time. I'll go poking in my rc files, but thought someone might know. Didn't see anything in sysconfig. I was hitting my system very hard. Like doing all kinds of CVS operations on the entire linux source tree (my own private CVS tree) which is about a 25M tree. I upgraded from 1.3.68 -> 1.3.96 in about 25 steps doing builds, commits, updates -jx -jy, tags, etc. It appears that the unlinked files (which were a little corrupted, btw) don't correlate to this at all, but all but 10 were from the time I started with the new kernel. The 10 date from when I was installing 2.1R. Yow! Be careful out there! Warner From owner-freebsd-stable Mon May 13 01:47:53 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA01617 for stable-outgoing; Mon, 13 May 1996 01:47:53 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA01595 Mon, 13 May 1996 01:47:47 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id BAA04203; Mon, 13 May 1996 01:47:44 -0700 (PDT) Date: Mon, 13 May 1996 01:47:44 -0700 (PDT) Message-Id: <199605130847.BAA04203@silvia.HIP.Berkeley.EDU> To: current@freebsd.org, stable@freebsd.org CC: nisha@cs.berkeley.edu Subject: Heads-up: ccd offset 16 change committed From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just committed changes to ccd.c to not use the first 16 blocks in each of the underlying partitions. What this means is that you can stop worrying about starting the partitions for ccd too close to the beginning of the slice. Anything that works for FFS will also work for ccd, including the "c" partition (which, I think, is what most people would want to use for ccd anyway). The downside of this is that if you already have a ccd set up on your machine, it will stop working when you recompile the kernel from the latest sources. To avoid this, you should either (1) change the disklabel to move the partitions 16 sectors towards the beginning of the disk, or (2) change the definition of CCD_OFFSET to 0 in sys/dev/ccd/ccd.c. Or just back up, recompile, and restore. I believe this would be the last major change in the ccd layout in the forseeable future. (Well there still might be, but at least I don't anticipate anything anytime soon, that's why it's called "forseeable". :> ) Happy concatenating! Satoshi From owner-freebsd-stable Mon May 13 04:18:21 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA12847 for stable-outgoing; Mon, 13 May 1996 04:18:21 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA12827 Mon, 13 May 1996 04:18:14 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id EAA10401; Mon, 13 May 1996 04:18:10 -0700 (PDT) Date: Mon, 13 May 1996 04:18:10 -0700 (PDT) Message-Id: <199605131118.EAA10401@silvia.HIP.Berkeley.EDU> To: current@freebsd.org, stable@freebsd.org CC: ccd@stampede.cs.berkeley.edu In-reply-to: <199605130847.BAA04203@silvia.HIP.Berkeley.EDU> (asami@cs.berkeley.edu) Subject: Re: Heads-up: ccd offset 16 change committed From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * The downside of this is that if you already have a ccd set up on your * machine, it will stop working when you recompile the kernel from the * latest sources. To avoid this, you should either (1) change the * disklabel to move the partitions 16 sectors towards the beginning of * the disk, or (2) change the definition of CCD_OFFSET to 0 in * sys/dev/ccd/ccd.c. Or just back up, recompile, and restore. Per Paul-Henning's request, I added an #ifndef-#else around the CCD_OFFSET so you can do a options "CCD_OFFSET=0" (double-quotes mandatory) in your kernel config file if you don't want to modify the source and still keep the old ccd volumes. Satoshi From owner-freebsd-stable Mon May 13 05:57:51 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA18233 for stable-outgoing; Mon, 13 May 1996 05:57:51 -0700 (PDT) Received: from eac.iafrica.com (slipper101136.iafrica.com [196.7.101.136]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA18203 for ; Mon, 13 May 1996 05:57:45 -0700 (PDT) Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id OAA00207; Mon, 13 May 1996 14:52:12 +0200 From: Robert Nordier Message-Id: <199605131252.OAA00207@eac.iafrica.com> Subject: Re: ext2fs patches -- bad news To: imp@village.org (Warner Losh) Date: Mon, 13 May 1996 14:52:11 +0200 (SAT) Cc: stable@freebsd.org In-Reply-To: <199605130305.VAA00436@rover.village.org> from "Warner Losh" at May 12, 96 09:05:44 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > On a related note, does anybody know how to tell FreeBSD to force fsck > to *ALWAYS*ALWAYS*ALWAYS* fsck the disk, ignoring the Clean flag? 'fsck -pf' will do that. -- Robert Nordier From owner-freebsd-stable Mon May 13 06:13:06 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA19324 for stable-outgoing; Mon, 13 May 1996 06:13:06 -0700 (PDT) Received: from eac.iafrica.com (h196-7-192-141.iafrica.com [196.7.192.141]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA19317 for ; Mon, 13 May 1996 06:12:45 -0700 (PDT) Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id PAA00314; Mon, 13 May 1996 15:08:22 +0200 From: Robert Nordier Message-Id: <199605131308.PAA00314@eac.iafrica.com> Subject: Re: ext2fs patches -- bad news To: imp@village.org (Warner Losh) Date: Mon, 13 May 1996 15:08:20 +0200 (SAT) Cc: stable@freebsd.org In-Reply-To: from "rnordier" at May 13, 96 02:52:11 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Robert Nordier wrote: > > Warner Losh wrote: > > > On a related note, does anybody know how to tell FreeBSD to force fsck > > to *ALWAYS*ALWAYS*ALWAYS* fsck the disk, ignoring the Clean flag? > > 'fsck -pf' will do that. Replacing 'fsck -p' in '/etc/rc', I meant. -- Robert Nordier From owner-freebsd-stable Mon May 13 07:36:27 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA24614 for stable-outgoing; Mon, 13 May 1996 07:36:27 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA24606 for ; Mon, 13 May 1996 07:36:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with SMTP id IAA02669; Mon, 13 May 1996 08:36:13 -0600 (MDT) Message-Id: <199605131436.IAA02669@rover.village.org> To: Robert Nordier Subject: Re: ext2fs patches -- bad news Cc: stable@freebsd.org In-reply-to: Your message of Sat, 13 May 1996 15:08:20 +0200 Date: Mon, 13 May 1996 08:36:13 -0600 From: Warner Losh Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk : Replacing 'fsck -p' in '/etc/rc', I meant. Thanks! Warner From owner-freebsd-stable Mon May 13 13:21:21 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA18807 for stable-outgoing; Mon, 13 May 1996 13:21:21 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA18777 Mon, 13 May 1996 13:20:52 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id NAA11363; Mon, 13 May 1996 13:20:46 -0700 (PDT) Date: Mon, 13 May 1996 13:20:46 -0700 (PDT) Message-Id: <199605132020.NAA11363@silvia.HIP.Berkeley.EDU> To: current@freebsd.org, stable@freebsd.org CC: ccd@stampede.cs.berkeley.edu In-reply-to: <199605131433.AAA09670@al.imforei.apana.org.au> (message from Peter Childs on Tue, 14 May 1996 00:03:38 +0930 (CST)) Subject: Re: (fwd) Re: Heads-up: ccd offset 16 change committed From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I received a few questions about which branch this change was committed. It is in BOTH -current and -stable. Granted we didn't test this change in our machines for several months (the usual prerequisite for something major, like a >5-line patch, to go into -stable) but I thought it would be very bad to have incompatible (as in "can't share the ccd filesystems") versions in -current and -stable. Hope this restores peace in many people's minds. Satoshi From owner-freebsd-stable Thu May 16 14:27:42 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05885 for stable-outgoing; Thu, 16 May 1996 14:27:42 -0700 (PDT) Received: from chain.iafrica.com (root@chain.iafrica.com [196.7.74.174]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA05879 for ; Thu, 16 May 1996 14:27:33 -0700 (PDT) Received: (from khetan@localhost) by chain.iafrica.com (8.7.5/8.6.12) id XAA03139; Thu, 16 May 1996 23:27:21 +0200 (SAT) Date: Thu, 16 May 1996 23:27:19 +0200 (SAT) From: Khetan Gajjar To: stable@freebsd.org Subject: Ports Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello all. How do I get the latest ports stuff from the cvs tree ? I tried cvs co -rRELENG_2_1_0 ports and that just extracted the whole structure, but everything had a ,v after it. What am I doing wrong ? --- Khetan Gajjar Visit at http://www.iafrica.com/~khetan/ UUNet-Internet Africa Operations help@iafrica.com or 0800-030-002 From owner-freebsd-stable Thu May 16 14:30:17 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA06082 for stable-outgoing; Thu, 16 May 1996 14:30:17 -0700 (PDT) Received: from chain.iafrica.com (root@chain.iafrica.com [196.7.74.174]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA06074 for ; Thu, 16 May 1996 14:30:08 -0700 (PDT) Received: (from khetan@localhost) by chain.iafrica.com (8.7.5/8.6.12) id XAA03164; Thu, 16 May 1996 23:29:46 +0200 (SAT) Date: Thu, 16 May 1996 23:29:46 +0200 (SAT) From: Khetan Gajjar To: stable@freebsd.org Subject: CVS command(s) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello all. I am a little unsure of the cvs command to update my src directory after applying the latest ctm changes (deltas). I tried cd /usr and then cvs update -rRELENG_2_1_0 src, but this did not do very much. What is the command ? Should I cd /usr/src and then cvs update -rRELENG_2_1_0 src ? I am on stable, btw. --- Khetan Gajjar Visit at http://www.iafrica.com/~khetan/ UUNet-Internet Africa Operations help@iafrica.com or 0800-030-002 From owner-freebsd-stable Thu May 16 15:14:40 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA09847 for stable-outgoing; Thu, 16 May 1996 15:14:40 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA09841 for ; Thu, 16 May 1996 15:14:36 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id PAA07067; Thu, 16 May 1996 15:14:26 -0700 From: "Rodney W. Grimes" Message-Id: <199605162214.PAA07067@GndRsh.aac.dev.com> Subject: Re: CVS command(s) To: khetan@iafrica.com (Khetan Gajjar) Date: Thu, 16 May 1996 15:14:25 -0700 (PDT) Cc: stable@freebsd.org In-Reply-To: from Khetan Gajjar at "May 16, 96 11:29:46 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-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hello all. > > I am a little unsure of the cvs command to update my src directory > after applying the latest ctm changes (deltas). > > I tried cd /usr and then cvs update -rRELENG_2_1_0 src, but this > did not do very much. What is the command ? > > Should I cd /usr/src and then cvs update -rRELENG_2_1_0 src ? > > I am on stable, btw. cd /usr/src cvs update -P -rRELENG_2_1_0 That -P is very important to prune out things that are no longer on the branch. You may also want to add -q to quite the output somewhat: cvs -q update -P -rRELENG_2_1_0 -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-stable Thu May 16 16:05:57 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA13385 for stable-outgoing; Thu, 16 May 1996 16:05:57 -0700 (PDT) Received: from cook.brunel.ac.uk (pp@cook.brunel.ac.uk [134.83.128.246]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA13373 for ; Thu, 16 May 1996 16:05:49 -0700 (PDT) Received: from palmer.demon.co.uk by cook.brunel.ac.uk with SMTP (PP); Fri, 17 May 1996 00:05:40 +0100 Received: from palmer.demon.co.uk (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-1) with ESMTP id XAA08594; Thu, 16 May 1996 23:59:04 +0100 (BST) To: Khetan Gajjar cc: stable@FreeBSD.ORG From: Gary Palmer Subject: Re: CVS command(s) In-reply-to: Your message of "Sat, 16 May 1996 23:29:46 +0200." Date: Thu, 16 May 1996 23:59:03 +0100 Message-ID: <8592.832287543@palmer.demon.co.uk> Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Khetan Gajjar wrote in message ID : > Hello all. > > I am a little unsure of the cvs command to update my src directory > after applying the latest ctm changes (deltas). > > I tried cd /usr and then cvs update -rRELENG_2_1_0 src, but this > did not do very much. What is the command ? > > Should I cd /usr/src and then cvs update -rRELENG_2_1_0 src ? > > I am on stable, btw. The command(s) I use are: cd /usr/src cvs -q update -Pd -rRELENG_2_1_0 which does the trick. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD - Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info. From owner-freebsd-stable Thu May 16 16:19:30 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA14626 for stable-outgoing; Thu, 16 May 1996 16:19:30 -0700 (PDT) Received: from DATAPLEX.NET (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA14614 for ; Thu, 16 May 1996 16:19:24 -0700 (PDT) Received: from 199.183.109.242 by DATAPLEX.NET with SMTP (MailShare 1.0fc5); Thu, 16 May 1996 18:15:59 -0600 Message-ID: Date: 16 May 1996 18:15:46 -0500 From: "Richard Wackerbarth" Subject: Standard Shipping Containers - A Proposal for Distributing FreeBSD To: "FreeBSD Hackers" Cc: "FreeBSD Current" , "freebsd-stable@freebsd.org" X-Mailer: Mail*Link PT/Internet 1.6.0 Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I see what appears to me to be a problem in the distribution of FreeBSD sources. I also propose a solution. I welcome your discussion. Richard The Problem: There are too many different variations of the same basic information. The Product: There are, and logically should be, four different "product lines". At the moment, they are 2.1, 2.2, "current", and "cvs". Each has its purpose and I don't intend to comment on that except to note that the similarities in the first three exceed their differences. The Distribution: There are seven distribution channels upon which I will comment. 1) Direct access to the master tree. This really applies only to the cvs tree and is "the only way to go" for commiters who are well connected. 2) Using "mirror". 3) Using "mirror" with directory listing cached on the server. 4) Using "sup". 5) Using "ctm". 6) Using distribution tarballs. 7) Using the "live file system" from CD. Characteristics of the Distribution Mechanisms. a) Only (1) and (2) provide "up to the minute" copies. All the rest give only a snapshot at server defined intervals. However, they exert an extremely heavy load on the server. The remainder compromise (in a reasonable mannner) by reusing the tree scan for multiple users at the expense of a delay in the update. b) (3) and (4) are functionally similar c) (1) thru (5) offer incremental updates. The Specific Difficulty. Each distribution mechanism has its own way of getting started. If I start with a clean disk, I must obtain a very large (28M compressed for the whole source) "update" to get started. In general, I cannot use the results of another distribution in place of a large portion of that transfer. CTM is perhaps better in that with it, we can create an update to transform one tree into another. However, it is significant work to attempt to identify and create the transformations from multiple starting points. The Proposal. Since all the reasonable distribution mechanisms are based upon server initiated snapshots, I suggest that, for each product, we do the following: 1) Have a single mechanism to define the snapshots that will be delivered. Then assure that everyone delivers exactly the same "product". 2) Include with that distribution the identifier(s) which would allow a user to use that distribution as a starting place for another distribution method. (In the case of CTM, this would mean the .ctm_status file.) Suggested details. 1) Since we are running CTM for each of the products, I would start by having the CTM servers define the snapshots. The .ctm_status file would then become a part of the source tree and everyone would distribute it. In particular, it would get included on the sup servers, in the distribution tarballs, and on the live file system CD. This would allow anyone who has a copy of the tree from any of these sources to update it by applying the ctm files. 2) I would also make available the directory of sup update keys. Although the one on the CD should match that distribution, they do not have to be maintained totally up-to-date. If you use a slightly out-of-date version, sup will simply replace a few additional files. 3) In order to coordinate these events, the sup servers would trigger their updates on the basis of the receipt of a ctm update. 4) In preparing a CD-ROM, we need to either a) freeze the source tree far enough in advance of the release to allow the updates to make the update circuit, or, b) freeze the update circuit and anticipate the effect of the final update or, c) use a combination of the two. Freeze the ctm updates before the fact. Allow the sup update to propogate. for inclusion on the CD. Anticipate the ctm update by adding one to the last count propogated if there were any changes. After the CD is frozen, use it to generate the next input to the ctm sequence. Conclusions: 1) Such a methodology will assure that it is easy for any user to jump from a CD or tarball to ctm or sup without having to re-aquire the bulk of the sources. 2) Sup can be used to repair a damaged tree when a complete ctm sequence is not available locally. 3) Ctm can be used for routine updates to avoid transferring the entire file to realize a minor change. 4) We need to enhance ctm to allow it to recognize intentionally pruned trees and ignore that portion of the update. (The argument for this conclusion was not included in this document) -- ...computers in the future may have only 1,000 vacuum tubes and weigh only 1/2 tons. -- Popular Mechanics, March 1949 From owner-freebsd-stable Thu May 16 17:41:06 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA20797 for stable-outgoing; Thu, 16 May 1996 17:41:06 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA20754; Thu, 16 May 1996 17:40:56 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA25150; Thu, 16 May 1996 18:40:46 -0600 Date: Thu, 16 May 1996 18:40:46 -0600 From: Nate Williams Message-Id: <199605170040.SAA25150@rocky.sri.MT.net> To: "Richard Wackerbarth" Cc: "FreeBSD Hackers" , "FreeBSD Current" , "freebsd-stable@freebsd.org" Subject: Re: Standard Shipping Containers - A Proposal for Distributing FreeBSD In-Reply-To: References: Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The Distribution: > There are seven distribution channels upon which I will comment. > 1) Direct access to the master tree. This really applies only > to the cvs tree and is "the only way to go" for commiters > who are well connected. > 2) Using "mirror". > 3) Using "mirror" with directory listing cached on the server. > 4) Using "sup". > 5) Using "ctm". > 6) Using distribution tarballs. > 7) Using the "live file system" from CD. > > Characteristics of the Distribution Mechanisms. > a) Only (1) and (2) provide "up to the minute" copies. Not true. If you have direct access to freefall (developers only), you can use (4-sup) to get "up to the minute" copies of the CVS tree. Occassionaly I re-sup the tree in the middle of the day if I want to make sure the changes I've made are valid. > The Proposal. > Since all the reasonable distribution mechanisms are based upon > server initiated snapshots Since your assumptions are invalid for one of the two most common distribution method, the rest of the proposal is not completely valid. nate From owner-freebsd-stable Thu May 16 21:00:22 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA07321 for stable-outgoing; Thu, 16 May 1996 21:00:22 -0700 (PDT) Received: from DATAPLEX.NET (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA07313 for ; Thu, 16 May 1996 21:00:17 -0700 (PDT) Received: from 199.183.109.242 by DATAPLEX.NET with SMTP (MailShare 1.0fc5); Thu, 16 May 1996 23:00:03 -0600 Message-ID: Date: 16 May 1996 22:59:43 -0500 From: "Richard Wackerbarth" Subject: Re(2): Standard Shipping Containers - A Proposal for Distributing FreeBSD To: "FreeBSD Current" , "FreeBSD Hackers" , "freebsd-stable@freebsd.org" , "Nate Williams" X-Mailer: Mail*Link PT/Internet 1.6.0 Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Not true. If you have direct access to freefall (developers only), you can use (4-sup) to get "up to the minute" copies of the CVS tree. If YOU can get "up to the minute" updates via sup, it is only because you fall in my category (1). My proposal does not affect a sup server that does not provide synchronous snapshots. > > The Proposal. > > Since all the reasonable distribution mechanisms are based upon server initiated snapshots > > Since your assumptions are invalid for one of the two most common > distribution method, the rest of the proposal is not completely valid. Since those who have the direct access are not really inhibited by this proposal, I suggest that you reconsider it in view of the other 99.99% of the folks for whom my assumptions apply. I hope there is somebody out there who cares about the difficulties of the "average joe" and doesn't simply brush off those problems because they are a member of the elite class who get to play by their own rules. -- ...computers in the future may have only 1,000 vacuum tubes and weigh only 1/2 tons. -- Popular Mechanics, March 1949 From owner-freebsd-stable Thu May 16 21:22:16 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA09143 for stable-outgoing; Thu, 16 May 1996 21:22:16 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA09138; Thu, 16 May 1996 21:22:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with SMTP id WAA06771; Thu, 16 May 1996 22:21:34 -0600 (MDT) Message-Id: <199605170421.WAA06771@rover.village.org> To: Nate Williams Subject: Re: Standard Shipping Containers - A Proposal for Distributing FreeBSD Cc: "Richard Wackerbarth" , "FreeBSD Hackers" , "FreeBSD Current" , "freebsd-stable@freebsd.org" In-reply-to: Your message of Thu, 16 May 1996 18:40:46 MDT Date: Thu, 16 May 1996 22:21:33 -0600 From: Warner Losh Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The Distribution: > There are seven distribution channels upon which I will comment. > 1) Direct access to the master tree. This really applies only > to the cvs tree and is "the only way to go" for commiters > who are well connected. > 2) Using "mirror". > 3) Using "mirror" with directory listing cached on the server. > 4) Using "sup". > 5) Using "ctm". > 6) Using distribution tarballs. > 7) Using the "live file system" from CD. > > Characteristics of the Distribution Mechanisms. > a) Only (1) and (2) provide "up to the minute" copies. Err, ummm, ctm provides me with up to the last four hour update copies of the development tree. And I have my email setup to automatically apply it, so it is no muss, no fuss. Easily more up to date that sup ever was for me. I resisted for a long time going to ctm because I thought it wouldn't give me the access that sup gave me. It has worked 1000% better than sup ever did for me. This is usually sufficient because relatively little changes in any given four hour period. Warner From owner-freebsd-stable Thu May 16 22:21:00 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA13492 for stable-outgoing; Thu, 16 May 1996 22:21:00 -0700 (PDT) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA13472; Thu, 16 May 1996 22:20:55 -0700 (PDT) Received: by haven.uniserve.com id <30776-159>; Thu, 16 May 1996 22:24:22 -0800 Date: Thu, 16 May 1996 22:24:17 -0700 (PDT) From: Tom Samplonius To: stable@freebsd.org, ports@freebsd.org Subject: NIS & wu-ftpd Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've found that users listed in NIS can not login via wu-ftpd, but can with the stock ftpd. Anyone seen this before? Tom From owner-freebsd-stable Thu May 16 22:59:57 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA17016 for stable-outgoing; Thu, 16 May 1996 22:59:57 -0700 (PDT) Received: from ns.uninet.ee (ns.uninet.ee [194.204.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA16954; Thu, 16 May 1996 22:59:42 -0700 (PDT) Received: (from taavi@localhost) by ns.uninet.ee (8.6.12/8.6.12) id IAA29902; Fri, 17 May 1996 08:59:15 +0300 Date: Fri, 17 May 1996 08:59:14 +0300 (EET DST) From: Taavi Talvik To: Richard Wackerbarth cc: FreeBSD Hackers , FreeBSD Current , "freebsd-stable@freebsd.org" Subject: Re: Standard Shipping Containers - A Proposal for Distributing FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 16 May 1996, Richard Wackerbarth wrote: > The Distribution: > There are seven distribution channels upon which I will comment. > 1) Direct access to the master tree. This really applies only > to the cvs tree and is "the only way to go" for commiters > who are well connected. > 2) Using "mirror". > 3) Using "mirror" with directory listing cached on the server. > 4) Using "sup". > 5) Using "ctm". > 6) Using distribution tarballs. > 7) Using the "live file system" from CD. > > Characteristics of the Distribution Mechanisms. > a) Only (1) and (2) provide "up to the minute" copies. All the > rest give only a snapshot at server defined intervals. > However, they exert an extremely heavy load on the server. > The remainder compromise (in a reasonable mannner) by reusing > the tree scan for multiple users at the expense of a delay > in the update. I am trying to mirror FreeBSD distributions for ftp.ee.freebsd.org. So far i not very successful in keeping my server up to date. For example last nite mirror retrieved onlyabout 50 files before ftp server went away. Restarting means retreieving another 30M of directory listing... There should be better way. Mirrored FreeBSD-current (ftp.freebsd.org:/pub/FreeBSD/FreeBSD-current -> /disk2d/ftp/pub/unix/FreeBSD/FreeBSD-current) FreeBSD-current @ Fri May 17 00:15:49 EET DST 1996 Got ports/LEGAL 2093 Got ports/www/netscape3/files/netscape.sh 281 Got ports/www/apache/patches/patch-ae 1755 Got ports/archivers/Makefile 386 Got ports/archivers/rar/Makefile 630 Got ports/archivers/rar/pkg/COMMENT 31 Got ports/archivers/rar/pkg/DESCR 244 Got ports/archivers/rar/pkg/PLIST 23 Got ports/archivers/rar/files/md5 54 Got ports/archivers/unrar/Makefile 503 Got ports/archivers/unrar/pkg/PLIST 11 Got ports/archivers/unrar/pkg/COMMENT 43 Got ports/archivers/unrar/files/md5 111 Got ports/games/Makefile 867 Got ports/games/imaze/Makefile 687 Got ports/games/xskat/Makefile 505 Got ports/games/xskat/pkg/COMMENT 25 Got ports/games/xskat/pkg/DESCR 216 Got ports/games/xskat/pkg/PLIST 30 Got ports/games/xskat/files/Imakefile 606 Got ports/games/xskat/files/md5 58 Got ports/x11/FWF/Makefile 433 Got ports/misc/less/Makefile 615 Got ports/print/psutils/Makefile 2170 Got ports/print/teTeX/Makefile 1163 Got ports/print/teTeX/scripts/post-install 3268 Got ports/print/teTeX/scripts/pre-extract 957 Got ports/print/teTeX/pkg/PLIST 621 Got ports/print/teTeX/files/vars 86 Got ports/print/teTeX/files/md5 1099 Got ports/lang/tclX75/Makefile 1914 Got ports/lang/tclX75/pkg/PLIST 9161 Got ports/graphics/Mesa/Makefile 375 Got ports/graphics/Mesa/pkg/PLIST 408 Got ports/graphics/Mesa/pkg/DESCR 574 Got ports/graphics/Mesa/pkg/COMMENT 52 Got ports/graphics/Mesa/patches/patch-aa 1366 Got ports/graphics/Mesa/patches/patch-ab 358 Got ports/graphics/Mesa/files/md5 59 Got ports/audio/gmod/Makefile 510 Got ports/shells/zsh/Makefile 850 Got ports/shells/zsh/files/md5 63 Got ports/shells/zsh/pkg/COMMENT 39 Got ports/shells/zsh/pkg/PLIST 575 Got ports/shells/pdksh/Makefile 459 Got ports/shells/pdksh/files/md5 60 Got ports/comms/rzsz/files/md5 54 Got src/usr.sbin/ppp/os.c 8048 Got src/usr.sbin/ctm/mkCTM/mkctm.c 14215 Got src/usr.sbin/ctm/mkCTM/Makefile 482 Got src/usr.bin/sgmlfmt/sgmlfmt.pl 15872 (file shrunk from 17699!) Failed to get src/usr.bin/f2c/f2c.1: timed out Failed to get src/usr.bin/calendar/calendar.1: 200 PORT command successful. Failed to get src/sys/i386/conf/LINT: 150 Opening BINARY mode data connection for src/usr.bin/calendar/calendar.1 (7411 bytes). Failed to get src/sys/i386/conf/GENERIC: remote server gone away unlink /disk2d/ftp/pub/unix/FreeBSD/FreeBSD-current/src/games/hack/hack.onames.h best regards, taavi From owner-freebsd-stable Thu May 16 23:20:04 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA18432 for stable-outgoing; Thu, 16 May 1996 23:20:04 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA18359; Thu, 16 May 1996 23:19:56 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id XAA17489 ; Thu, 16 May 1996 23:19:49 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA10859; Fri, 17 May 1996 15:56:56 +0930 From: Michael Smith Message-Id: <199605170626.PAA10859@genesis.atrad.adelaide.edu.au> Subject: Re: Standard Shipping Containers - A Proposal for Distributing FreeBSD To: imp@village.org (Warner Losh) Date: Fri, 17 May 1996 15:56:56 +0930 (CST) Cc: nate@sri.MT.net, rkw@dataplex.net, hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org In-Reply-To: <199605170421.WAA06771@rover.village.org> from "Warner Losh" at May 16, 96 10:21:33 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh stands accused of saying: > apply it, so it is no muss, no fuss. Easily more up to date that sup > ever was for me. I resisted for a long time going to ctm because I > thought it wouldn't give me the access that sup gave me. It has > worked 1000% better than sup ever did for me. This is usually > sufficient because relatively little changes in any given four hour > period. All this discussion is telling us is that there are several different ways by which FreeBSD source code is distributed, and each of these different ways works well for different people. What's wrong with things as they are? Why should anyone feel compelled to change things if they're not broken? > Warner -- ]] 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-stable Fri May 17 04:26:18 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA09795 for stable-outgoing; Fri, 17 May 1996 04:26:18 -0700 (PDT) Received: from chain.iafrica.com (root@chain.iafrica.com [196.7.74.174]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA09789 for ; Fri, 17 May 1996 04:26:04 -0700 (PDT) Received: (from khetan@localhost) by chain.iafrica.com (8.7.5/8.6.12) id NAA14563; Fri, 17 May 1996 13:25:56 +0200 (SAT) Date: Fri, 17 May 1996 13:25:56 +0200 (SAT) From: Khetan Gajjar To: stable@freebsd.org Subject: rmail setup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello all. I've setup ctm : "|ctm_rmail -p /home/ctm/tmp -d /home/ctm/cvs-cur/ -l /home/ctm/ctm.log" owner-ctm : root in my aliases file. Does this read ok ? I just want it to collect the deltas, not apply them --- Khetan Gajjar Visit at http://www.iafrica.com/~khetan/ UUNet-Internet Africa Operations help@iafrica.com or 0800-030-002 From owner-freebsd-stable Fri May 17 06:59:40 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA18241 for stable-outgoing; Fri, 17 May 1996 06:59:40 -0700 (PDT) Received: from distortion.eng.umd.edu (distortion.eng.umd.edu [129.2.98.6]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA18236; Fri, 17 May 1996 06:59:37 -0700 (PDT) Received: from maryann.eng.umd.edu (maryann.eng.umd.edu [129.2.98.209]) by distortion.eng.umd.edu (8.7.5/8.7.3) with ESMTP id JAA12806; Fri, 17 May 1996 09:59:35 -0400 (EDT) Received: (from chuckr@localhost) by maryann.eng.umd.edu (8.7.5/8.7.3) id JAA26502; Fri, 17 May 1996 09:59:34 -0400 (EDT) Date: Fri, 17 May 1996 09:59:32 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@maryann.eng.umd.edu To: Richard Wackerbarth cc: FreeBSD Current , FreeBSD Hackers , "freebsd-stable@freebsd.org" , Nate Williams Subject: Re: Re(2): Standard Shipping Containers - A Proposal for Distributing FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On 16 May 1996, Richard Wackerbarth wrote: > > Since those who have the direct access are not really inhibited by this > proposal, I suggest that you reconsider it in view of the other 99.99% of the > folks for whom my assumptions apply. > > I hope there is somebody out there who cares about the difficulties of the > "average joe" and doesn't simply brush off those problems because they are a > member of the elite class who get to play by their own rules. If you would make clear that your realize that your comments don't apply to those who are net connected, you wouldn't have everyone complaining. Your comments so far have been incorrect in how sup and ctm really work. No one would argue about upgrading ctm, but you seem to be making claims about both sup and ctm that don't apply to both. You ask who cares about those not net-connected, but your own comments seem to betray a prejudice against those who ARE net-connected. How about caring for both? That's why there's TWO tools, not one. > > -- > > ...computers in the future may have only 1,000 vacuum tubes and weigh > only 1/2 tons. -- Popular Mechanics, March 1949 > > ----------------------------+----------------------------------------------- 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-stable Fri May 17 09:16:12 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA28101 for stable-outgoing; Fri, 17 May 1996 09:16:12 -0700 (PDT) Received: from zip0.zipnet.net (root@zip0.zipnet.net [199.232.240.20]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA28080; Fri, 17 May 1996 09:16:08 -0700 (PDT) Received: (from ejon@localhost) by zip0.zipnet.net (8.7.3/8.6.12) id MAA29232; Fri, 17 May 1996 12:16:07 -0400 (EDT) From: "Eric H. Jones" Message-Id: <199605171616.MAA29232@zip0.zipnet.net> Subject: Series of (VM-related?) crashes on 2.1-stable To: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Date: Fri, 17 May 1996 12:16:07 -0400 (EDT) Cc: wink@zip0.zipnet.net (Jim Winkleman), ejon@zip0.zipnet.net (Eric H. Jones) X-Mailer: ELM [version 2.4 PL24 ME8] Content-Type: text Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings BSDers, We're running a soon-to-be-huge ISP on FreeBSD-stable (last SUP roughly February), and have suddenly started seeing ugly crashes on our news server. I'm wondering if anybody else has seen similar. FYI, the machine is a P133 with 64 MB, scads of swap, about 28 GB of disk on two controllers (Adaptec 2940), SMC 100baseT card, vanilla Trident VGA card. The disks are Quantum 34300's plus one Compaq M1606S (well that's what it calls itself!) My first reaction was that there may be a problem with the VM code, but now I'm starting to think that we might be seeing a memory error up in the pages that the kernel keeps locked down for its own use. Opinions? Below is what info I've been able to glean from the messages files: May 2 crash: /kernel: kernel page directory invalid pdir=0x3d5e023, va=0xefbfe000 /kernel: panic: invalid kernel page directory /kernel: /kernel: syncing disks... FreeBSD 2.1-STABLE #0: Wed Mar 27 07:10:02 EST 1996 --------------------- May 8 crash: innd: newsie.dmc.com connected 26 (8 minute delay with no messages) /kernel: FreeBSD 2.1-STABLE #0: Wed Mar 27 07:10:02 EST 1996 --------------------- May 10 crash 1: /kernel: panic: unwire: page not in pmap /kernel: /kernel: syncing disks... FreeBSD 2.1-STABLE #0: Wed Mar 27 07:10:02 EST 1996 --------------------- May 10 crash 2 (about 1 hr after crash 1): /kernel: /kernel: /kernel: Fatal trap 1 (for some reason the reboot messages are missing here) --------------------- May 17 crash: /kernel: /kernel: /kernel: Fatal trap 12: page fault while in kernel mode /kernel: fault virtual address = 0xfffbeff8 /kernel: fault code = supervisor write, protection violation /kernel: instruction pointer = 0x8:0xf01945e4 /kernel: code segment = base 0x0, limit 0xfffff, type 0x1b /kernel: = DPL 0, pres 1, def32 1, gran 1 /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 /kernel: current process = 17105 (sh) /kernel: interrupt mask = net tty bio /kernel: panic: page fault /kernel: /kernel: syncing disks... FreeBSD 2.1-STABLE #0: Wed Mar 27 07:10:02 EST 1996 From owner-freebsd-stable Fri May 17 13:27:09 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA16078 for stable-outgoing; Fri, 17 May 1996 13:27:09 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA16067; Fri, 17 May 1996 13:27:03 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA20585; Fri, 17 May 1996 13:22:47 -0700 From: Terry Lambert Message-Id: <199605172022.NAA20585@phaeton.artisoft.com> Subject: Re: Re(2): Standard Shipping Containers - A Proposal for Distributing FreeBSD To: rkw@dataplex.net (Richard Wackerbarth) Date: Fri, 17 May 1996 13:22:46 -0700 (MST) Cc: freebsd-current@FreeBSD.org, hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, nate@sri.MT.net In-Reply-To: from "Richard Wackerbarth" at May 16, 96 10:59:43 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-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Not true. If you have direct access to freefall (developers only), you can > use (4-sup) to get "up to the minute" copies of the CVS tree. > > If YOU can get "up to the minute" updates via sup, it is only because you fall > in my category (1). My proposal does not affect a sup server that does not > provide synchronous snapshots. If the mirror servers fired three times a day, and your pull from the mirror fired once a day, you'd be set. You only need an "up to the minute" version if that's how you locally maintain your changes -- by communicating them through the master SUP server. This assumes commit privs. If you don't have commit privs, once a day or once a week (depending on your level of activity) is enough to handle it for you. You can cut the intermediate sup server traffic by 33% if you institute multiple reader/single writer locks and use a pseudo writer lock for the SUP area mirroring. If commiters follow the "it must run before you release the writer lock" protocol, then you will be guaranteed a buildable image on every SUP. > > Since your assumptions are invalid for one of the two most common > > distribution method, the rest of the proposal is not completely valid. > > Since those who have the direct access are not really inhibited by this > proposal, I suggest that you reconsider it in view of the other 99.99% of the > folks for whom my assumptions apply. I don't totally agree with all aspects of the proposal, since I have multple trees for multiple concurrent projects, and it won't help me out that much because of it. But this is a point in its favor. 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-stable Fri May 17 13:49:25 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA18069 for stable-outgoing; Fri, 17 May 1996 13:49:25 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA18062; Fri, 17 May 1996 13:49:21 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA20637; Fri, 17 May 1996 13:44:28 -0700 From: Terry Lambert Message-Id: <199605172044.NAA20637@phaeton.artisoft.com> Subject: Re: Re(2): Standard Shipping Containers - A Proposal for Distributing FreeBSD To: chuckr@Glue.umd.edu (Chuck Robey) Date: Fri, 17 May 1996 13:44:27 -0700 (MST) Cc: rkw@dataplex.net, freebsd-current@FreeBSD.ORG, hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, nate@sri.MT.net In-Reply-To: from "Chuck Robey" at May 17, 96 09:59:32 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-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I hope there is somebody out there who cares about the difficulties of the > > "average joe" and doesn't simply brush off those problems because they are a > > member of the elite class who get to play by their own rules. > > If you would make clear that your realize that your comments don't apply > to those who are net connected, you wouldn't have everyone complaining. > Your comments so far have been incorrect in how sup and ctm really work. > No one would argue about upgrading ctm, but you seem to be making claims > about both sup and ctm that don't apply to both. Actually, I am net connected, but I do not have commit privs. I have some strong objections to using the CVS tree as an experimental code communcation medium for a working group, even if I did have commit privs. I agree with him. There are problems for the programmer without commit priviledges; specifically, I can't have both local source code control for my changes and have up to date integration of other's changes at the same time. Where I differ is that I believe this is a *purely* CTM/SUP problem, because of the way updates are made by these tools. It isn't clear to me whether CVS itself can support the concepts necessary to fix the problem, in any case. The other issue that I disagree on is more one of policy enforcement than anything else. At Novell, we used CVS for tree maintenance, but we supported a multiple reader/single writer locking mechanism. You could checkout sources without acquiring a reader lock, but doing so put you at risk of having an unbuildable source tree. A writer lock could not be acquired while a reader lock was asserted, and vice versa. The correct method of making a tree snapshot for SUP or CTM such that the resulting tree is guaranteed to be guildable is to not release the writer lock until the tree builds. A writer lock is followed by a CVS update, conflict resoloution, a test build, and delta checking The CVS tree should be buildable at all revision tag levels. Period. This would drop 33% of the SUP overhead off of Freefall immediately, and 50% of the SUP overhead on the mirrors, as updates are not required to be retried. It would also make FreeBSD look better. It would be impossible to check out an unbuildable tree following a SUP. No more "xxx breaks yyy" traffic on -current (at least for structural changes to the build environment). Policy has little or nothing to do with implementation. The reason I suggested locking was as a means of implementing the policy. It is not the only means, and personal restraint is obviously possible. if the integration update policy is followed. 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-stable Sat May 18 07:54:55 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA04743 for stable-outgoing; Sat, 18 May 1996 07:54:55 -0700 (PDT) Received: from hermes.algonet.se (mail.algonet.se [193.12.207.206]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA04735; Sat, 18 May 1996 07:54:49 -0700 (PDT) Received: from (johang@sophocles.algonet.se [193.12.207.10]) by hermes.algonet.se (8.7.4/hdw.1.0) with SMTP id QAA27423; Sat, 18 May 1996 16:54:31 +0200 (MET DST) Message-Id: <199605181454.QAA27423@hermes.algonet.se> Comments: Authenticated sender is From: "Johan Granlund" To: stable@FreeBSD.ORG Date: Sat, 18 May 1996 17:51:34 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: AHA2940UW with nonultra disks broke. CC: gibbs@freefall.freebsd.org Priority: normal X-mailer: Pegasus Mail for Windows (v2.33) Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk First FreeBSD-stable is running great, but... In the period between 5 may and 15 may the aha2940 driver broke when using the 2940UW adapter in ultra mode with only Fast/narrow disks. If i disable "Ultra mode it works, but breaks with it enabled. I could have the adapter in "Ultra mode" before may 5. Justin (I guess) commited three changes in CTM patches 95,96 and 97. This after som traffic in the -stable list about a broken driver. I had no problems then :-) The top of my dmesg output with "Ultra mode" disabled: FreeBSD 2.1-STABLE #0: Thu May 16 11:39:13 MET DST 1996 root@phoenix.deltasys.se:/home/FreeBSD-2.1-stable/src/sys/compile/ HOENIX CPU: 133-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping=11 Features=0x1bf real memory = 16777216 (16384K bytes) avail memory = 14811136 (14464K bytes) pcibus_setup(1): mode1res=0x80000000 (0x80000000), mode2res=0xff (0x0e) pcibus_setup(2): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=122d8086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7 vga0 rev 0 int a irq 11 on pci0:13 mapreg[10] type=0 addr=ff000000 size=800000. ahc0 rev 0 int a irq 10 on pci0:14 mapreg[10] type=1 addr=0000fc00 size=0100. mapreg[14] type=0 addr=fffbf000 size=1000. ahc0: BurstLen = 8DWDs, Latency Timer = 64PCLKS ahc0: Reading SEEPROM...done. ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A ahc0 waiting for scsi devices to settle ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "SEAGATE ST11900N 8650" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1621MB (3320691 512 byte sectors) sd0(ahc0:0:0): with 2621 cyls, 15 heads, and an average 84 sectors/track ahc0: target 1 synchronous at 10.0MHz, offset = 0xf ahc0: target 1 Tagged Queuing Device (ahc0:1:0): "HP C3725S 5153" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 2047MB (4194058 512 byte sectors) sd1(ahc0:1:0): with 3703 cyls, 9 heads, and an average 125 sectors/track (ahc0:6:0): "WangDAT Model 3100 02.2" type 1 removable SCSI 2 st0(ahc0:6:0): Sequential-Access density code 0x13, drive empty pci0: uses 8392704 bytes of memory from ff000000 upto fffbffff. pci0: uses 256 bytes of I/O space from fc00 upto fcff. ----------------------------------------------------- With "ultra mode" enabled i get the line: ahc0: target 0 synchronous at 5.7MHZ, offset 0xf and the SCSI-bus hangs. /Johan ___________________________________________________________ Internet: Johang@Algonet.se I don't even speak for myself From owner-freebsd-stable Sat May 18 12:38:28 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA15949 for stable-outgoing; Sat, 18 May 1996 12:38:28 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA15943; Sat, 18 May 1996 12:38:26 -0700 (PDT) Message-Id: <199605181938.MAA15943@freefall.freebsd.org> To: "Johan Granlund" cc: stable@FreeBSD.ORG Subject: Re: AHA2940UW with nonultra disks broke. In-reply-to: Your message of "Sat, 18 May 1996 17:51:34 -0000." <199605181454.QAA27423@hermes.algonet.se> Date: Sat, 18 May 1996 12:38:26 -0700 From: "Justin T. Gibbs" Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The problem is that the 5.7MHz syncrate seems to be invalid when in Ultra mode. The fix I'm working on now is to dynamically enable/disable ultra mode on a per device basis so that the entire range of sync rates are availible to all devices. Although the driver worked before, it was improperly reporting 10MHz when the setting really resulted in 5MHz (Not all settings are clock doubled when in Ultra mode). Unfortunately, the documentation on how the aic7880 works in Ultra mode was unavailible when I did the work and the information I used came to me through "unofficial" channels. Now that the documentation is availible, my copy is still on back order. 8-( -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-stable Sat May 18 15:36:59 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA25489 for stable-outgoing; Sat, 18 May 1996 15:36:59 -0700 (PDT) Received: from hermes.algonet.se (mail.algonet.se [193.12.207.206]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA25478; Sat, 18 May 1996 15:36:48 -0700 (PDT) Received: from (johang@aristotle.algonet.se [193.12.207.1]) by hermes.algonet.se (8.7.4/hdw.1.0) with SMTP id AAA23054; Sun, 19 May 1996 00:36:34 +0200 (MET DST) Message-Id: <199605182236.AAA23054@hermes.algonet.se> Comments: Authenticated sender is From: "Johan Granlund" To: "Justin T. Gibbs" , stable@FreeBSD.ORG Date: Sun, 19 May 1996 01:33:40 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: AHA2940UW with nonultra disks broke. CC: stable@FreeBSD.ORG Priority: normal X-mailer: Pegasus Mail for Windows (v2.33) Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The problem is that the 5.7MHz syncrate seems to be invalid when in Ultra > mode. Correcti think, according to the BIOS. Minimum syncrate is 10MHZ > The fix I'm working on now is to dynamically enable/disable ultra > mode on a per device basis so that the entire range of sync rates are > availible to all devices. Great, wonder why Adaptec wasn't thinking of that? > Although the driver worked before, it was > improperly reporting 10MHz when the setting really resulted in 5MHz (Not > all settings are clock doubled when in Ultra mode). Maybe i was unclear, but the target 0 disk is a fast/narrow SCSIdevice and should sync at 10MHZ. The dmesg output was from the adapter in NON-ULTRA mode. When in Ultra mode the SCSI bus was hanging after the driver had put out the "speed" line. I also have a DAT tape that is sync. on 5MHZ (i didn't know that at first). When setting the adapter in Ultra mode the driver correctly said that 5.0 MHZ was to low and set it for async (4MHZ). Ok what is a MHZ between friends. The problem was that when i was trying to use the tape the driver went nuts and tried to fallforward to 5MHZ sync. Lots of complaints of course. This was before the last patches and i haven't tried it again. I'm perfectly willing to do so and send the output to you if you want to. > Unfortunately, the > documentation on how the aic7880 works in Ultra mode was unavailible when I > did the work and the information I used came to me through "unofficial" > channels. Now that the documentation is availible, my copy is still > on back order. 8-( That figures. Why send dokumentation to developers :-) > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== > > ___________________________________________________________ Internet: Johang@Algonet.se I don't even speak for myself From owner-freebsd-stable Sat May 18 15:51:09 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA26374 for stable-outgoing; Sat, 18 May 1996 15:51:09 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA26365; Sat, 18 May 1996 15:51:06 -0700 (PDT) Message-Id: <199605182251.PAA26365@freefall.freebsd.org> To: "Johan Granlund" cc: stable@FreeBSD.ORG Subject: Re: AHA2940UW with nonultra disks broke. In-reply-to: Your message of "Sun, 19 May 1996 01:33:40 -0000." <199605182236.AAA23054@hermes.algonet.se> Date: Sat, 18 May 1996 15:51:06 -0700 From: "Justin T. Gibbs" Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The problem is that the 5.7MHz syncrate seems to be invalid when in Ultra >> mode. >Correcti think, according to the BIOS. Minimum syncrate is 10MHZ That only specifies where syncronous negotiation starts. The chip can do sync all the way down to 3.6MHz. >> The fix I'm working on now is to dynamically enable/disable ultra >> mode on a per device basis so that the entire range of sync rates are >> availible to all devices. > >Great, wonder why Adaptec wasn't thinking of that? They probably did. >> Although the driver worked before, it was >> improperly reporting 10MHz when the setting really resulted in 5MHz (Not >> all settings are clock doubled when in Ultra mode). > >Maybe i was unclear, but the target 0 disk is a fast/narrow SCSIdevice and >should sync at 10MHZ. The dmesg output was from the adapter in >NON-ULTRA mode. When in Ultra mode the SCSI bus was hanging after the >driver had put out the "speed" line. Perhaps I wasn't clear. You can't do 10MHz sync when the adapter is in Ultra mode. It looks like you can do 20, 16, 13.4, and 5. The old code used to report the 5 MHz entry as 10 because it assumed at all settings in ultra mode are clock doubled. The second dmesg output reported the disk at 5.7Mhz which was an entry I added recently but doesn't seem to function. >I also have a DAT tape that is sync. on 5MHZ (i didn't know that at >first). When setting the adapter in Ultra mode the driver correctly >said that 5.0 MHZ was too low and set it for async (4MHZ). Ok what is >a MHZ between friends. The problem was that when i was trying to use >the tape the driver went nuts and tried to fallforward to 5MHZ sync. >Lots of complaints of course. This was before the last patches and i >haven't tried it again. It should work fine in non-Ultra mode and will properly sync at 5MHz regardless of which mode you set in SCSI-Select as soon as I finish my changes. >___________________________________________________________ > >Internet: Johang@Algonet.se > >I don't even speak for myself > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-stable Sat May 18 17:39:14 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA19425 for stable-outgoing; Sat, 18 May 1996 17:39:14 -0700 (PDT) Received: from UABDPO.DPO.UAB.EDU (UABDPO.DPO.UAB.EDU [138.26.1.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA19410 for ; Sat, 18 May 1996 17:39:10 -0700 (PDT) Received: from jason.scott.net by UABDPO.DPO.UAB.EDU (IBM VM SMTP V2R2) with TCP; Sat, 18 May 96 19:38:27 CDT Message-ID: <319DD5A9.41C67EA6@scott.net> Date: Sat, 18 May 1996 08:51:37 -0500 From: Jason Gilbert X-Mailer: Mozilla 3.0b2 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: stable@freebsd.org Subject: Quickcam kernel driver support in stable Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has the quickcam kernel driver that is supposedly supported on 2.1 and is included in current been incorporated into the stable source tree? jason