From owner-freebsd-current Sun Sep 17 02:51:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA06590 for current-outgoing; Sun, 17 Sep 1995 02:51:18 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA06577 for ; Sun, 17 Sep 1995 02:51:04 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA08597 for current@freebsd.org; Sun, 17 Sep 1995 19:48:54 +1000 Date: Sun, 17 Sep 1995 19:48:54 +1000 From: Bruce Evans Message-Id: <199509170948.TAA08597@godzilla.zeta.org.au> To: current@freebsd.org Subject: assorted cdrom driver and nfs bugs Sender: owner-current@freebsd.org Precedence: bulk I tried this to demonstrate a bug in the SCSI cdrom driver: Mount a cdrom on cd0a. # OK. Attempt to eject cdrom. # OK, this fails because of locking. dd if=/dev/rcd0a of=/dev/null count=1. # Peek at complementary device # to demonstrate broken # close(). Attempt to eject cdrom. # BUG, this succeeds. All or almost all cdrom drivers have this bug. It is most easily fixed by letting the slice driver keep track of opens. Attempting to recover from this showed a bug in nfsv3: Reload cdrom. # OK. umount /dev/cd0a. # OK. Mount cdrom on cd0a again. # OK. Now on a client running nfsv3 with the cdrom nfs-mounted through all this: df. # Panic (null pointer in nfs_statfs()). Reboot client. # OK df. # Panic (as above). Bruce From owner-freebsd-current Sun Sep 17 05:03:43 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA11853 for current-outgoing; Sun, 17 Sep 1995 05:03:43 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA11848 for ; Sun, 17 Sep 1995 05:03:39 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id OAA23470; Sun, 17 Sep 1995 14:03:33 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id OAA11712; Sun, 17 Sep 1995 14:03:32 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id MAA11197; Sun, 17 Sep 1995 12:24:47 +0200 From: J Wunsch Message-Id: <199509171024.MAA11197@uriah.heep.sax.de> Subject: Re: pci bus and current?? To: kmitch@nando.net (kmitch) Date: Sun, 17 Sep 1995 12:24:47 +0200 (MET DST) Cc: current@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9509161048.AA06366@nando.net.nando.net> from "kmitch" at Sep 16, 95 06:48:08 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 547 Sender: owner-current@FreeBSD.org Precedence: bulk As kmitch wrote: > > > I just upgraded to the current (9-15), and now my kernel does not > probe my pci bus anymore, and thus can't find my hard drives. Perhaps we could exchange something? My plain old 386sx/16 ISA testbed now starts probing for PCI -- and it actually claims it has FOUND something. :-) (This is with a GENERIC kernel from a self-compiled RELEASE as of one week ago CVS sources.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 17 05:04:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA11901 for current-outgoing; Sun, 17 Sep 1995 05:04:07 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA11892 for ; Sun, 17 Sep 1995 05:04:02 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id OAA23458; Sun, 17 Sep 1995 14:03:29 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id OAA11709; Sun, 17 Sep 1995 14:03:28 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id LAA10739; Sun, 17 Sep 1995 11:23:21 +0200 From: J Wunsch Message-Id: <199509170923.LAA10739@uriah.heep.sax.de> Subject: Re: libforms - thumbs up or down? To: paul@FreeBSD.org Date: Sun, 17 Sep 1995 11:23:21 +0200 (MET DST) Cc: joerg_wunsch@uriah.heep.sax.de, current@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199509161626.RAA03380@server.netcraft.co.uk> from "Paul Richards" at Sep 16, 95 05:26:41 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 730 Sender: owner-current@FreeBSD.org Precedence: bulk As Paul Richards wrote: > > Hmm, OK. Clear bit rot taken place I think. I've removed libdialog > from the example and it now compiles and runs. Not a very interesting example > really but it works now. Hmm, okay, now (including the changes of your last commit) it seems to work. Odd points: the frame is drawn as "qxl" characters on an xterm, and going up with the arrow keys from the QUIT field leaves a "Ca" on the bottom line (from a previous "Can't go up from this field" message). I'm not sure if this is a shortcoming of your example only, but i guess it's a libforms problem. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 17 06:56:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA15665 for current-outgoing; Sun, 17 Sep 1995 06:56:24 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA15659 for ; Sun, 17 Sep 1995 06:56:20 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id JAA12517 for current@freebsd.org; Sun, 17 Sep 1995 09:48:15 -0400 From: Peter Dufault Message-Id: <199509171348.JAA12517@hda.com> Subject: aha1542 patches to test To: current@freebsd.org Date: Sun, 17 Sep 1995 09:48:15 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 737 Sender: owner-current@freebsd.org Precedence: bulk I've dropped a patch to i386/isa/aha1542.c in "freebsd.org:~ftp/incoming/1542cp.diff". It supports the new 1542CP. If you have any 1542 willing would you test the patch and let me know if it works OK? I know they are trivial but I still want them tested before committing them. It lets the driver work with the new 1542CP (plug 'n play) by recognizing the revision, and should support any new revision boards by assuming that if it looks like a new revision it probably is a new revision. There have been two failures I know of due to this in recent weeks. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-current Sun Sep 17 07:21:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA16103 for current-outgoing; Sun, 17 Sep 1995 07:21:49 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA16096 ; Sun, 17 Sep 1995 07:21:44 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id PAA02732; Sun, 17 Sep 1995 15:20:40 +0100 From: Paul Richards Message-Id: <199509171420.PAA02732@server.netcraft.co.uk> Subject: Re: Which SUP files are available and where ? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 17 Sep 1995 15:20:39 +0100 (BST) Cc: gibbs@freefall.freebsd.org, paul@FreeBSD.org, pete@sms.fi, davidg@Root.COM, current@FreeBSD.org In-Reply-To: <21442.811300450@time.cdrom.com> from "Jordan K. Hubbard" at Sep 16, 95 06:14:10 pm Reply-to: paul@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2058 Sender: owner-current@FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who said > > Well, I don't expect that the "switch will be thrown" quite as neatly > as some here might hope. I'm more inclined to suspect that 2.1 will > be followed by 2.1.1, 2.1.2, etc. 2.2 will be released with its own > experimental enhancements going on point releases of 2.2, etc. I hope not. While there's an option to do *critical* patch updates for a 2.1.1 it's not something we should be keen to do. I'd be really pissed if people get the idea that there'll be a 2.1.1 that has some of the bits that look OK out of the -current branch. > > The only serious question still to be resolved is just when the > "rollover" happens? Does 2.1.x live forever, or does it get abandoned > with 2.2.x is "stable?" Does 2.1 just become 2.3 at some point, > leaving the odd numbered releases as the "stable" ones and the even > numbered ones as "experimental?" When does 2.2.x get abandoned in > favor of 2.4 then? 2.1 should get abandoned immediately with the exception that a truly killer bug that is so bad that people can't just work around it until the next release may get fixed with a 2.1.1 update. There should be a freeze date on 2.2 when no more experimental or major changes are made and after a brief period, say a week or two to make sure it's basically safe, it should move over to the stable branch. Once 2.1 is out that experimental freeze should be quite soon, basically as soon as the current major developments have been fixed. People can get straight on with finishing other experimental code then while the 2.2 candidate gets a prolonged period of bug squishing on the stable branch. This is simply a more organised release cycle than we've previously had with a pending release candidate having a prolonged period of code freeze so all the little bugs can be shaken out while wild and crazy development is not curtailed because of a code freeze.. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Sun Sep 17 10:59:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA20781 for current-outgoing; Sun, 17 Sep 1995 10:59:13 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA20765 for ; Sun, 17 Sep 1995 10:59:10 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id KAA04017 for ; Sun, 17 Sep 1995 10:45:08 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id NAA17420; for ; Sun, 17 Sep 1995 13:45:36 -0400 Date: Sun, 17 Sep 95 13:43:19 PDT From: "Ugen J.S.Antsilevich" Subject: COMPAT_43 To: freebsd-current@FreeBSD.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk Well..I removed "COMPAT_43" from 2.0.5 kernel and all the tty stuff went boogey... Actually libc function ttyname was based on ioctl() TIOCGETP which is only left as a compatibility to 4.3 routine. I wonder if this is still happening and COMPAT_43 mandatory ? --Ugen From owner-freebsd-current Sun Sep 17 10:59:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA20849 for current-outgoing; Sun, 17 Sep 1995 10:59:23 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA20831 ; Sun, 17 Sep 1995 10:59:20 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id JAA28189 ; Sun, 17 Sep 1995 09:14:14 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA21366; Sun, 17 Sep 1995 09:14:39 -0700 To: paul@FreeBSD.org cc: gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@FreeBSD.org Subject: Re: Which SUP files are available and where ? In-reply-to: Your message of "Sun, 17 Sep 1995 15:20:39 BST." <199509171420.PAA02732@server.netcraft.co.uk> Date: Sun, 17 Sep 1995 09:14:38 -0700 Message-ID: <21364.811354478@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > 2.1 should get abandoned immediately with the exception that a truly killer > bug that is so bad that people can't just work around it until the next relea se > may get fixed with a 2.1.1 update. This seems contradictory. If 2.1 is "abandoned" then where does 2.1.1 come from? I think it goes without saying that 2.1 will have problems which could be fixed in a 2.1.1 and that people will strongly urge us to do so. We *always* have problems with each release. It's a truism. > There should be a freeze date on 2.2 when no more experimental or major > changes are made and after a brief period, say a week or two to make sure it' s > basically safe, it should move over to the stable branch. Once 2.1 is out tha That sounds OK in theory, but it both assumes that 2.2 is going to be ready in a timeframe congruent with when people are expecting "their bugs to be fixed" and that those bugs *will* be fixed in 2.2. Some 3-5 months after 2.1 we WILL be sitting on a list of problems that people are getting impatient with and it will be no trivial matter to just assume that 2.2 will fill the bill. I see experimental changes going into there for awhile yet, and that doesn't translate to the kind of "incrementally debugged" release that 2.1.1 would represent. Given that, well, it still doesn't seem so cut and dried to me. Jordan From owner-freebsd-current Sun Sep 17 10:59:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA20793 for current-outgoing; Sun, 17 Sep 1995 10:59:14 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA20772 ; Sun, 17 Sep 1995 10:59:11 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id KAA03398 ; Sun, 17 Sep 1995 10:43:39 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id NAA17325; for ; Sun, 17 Sep 1995 13:44:06 -0400 Date: Sun, 17 Sep 95 13:40:29 PDT From: "Ugen J.S.Antsilevich" Subject: IDE CDROM.... To: freebsd-current@FreeBSD.org, serge@FreeBSD.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk Hmm..so here is the question.. both in -current and in patched by me to include atapi & ide cdrom 2.0.5 kernel things go like that: on the bootup wcd0 found and attached on the wdc1 controller (actually my sound card acts like one), the type determined correctly (this is Hitachi)... Then whatever operation i try to do , i get the responce that operation aborted , error 54 or something like that. Any action on /dev/rwcd0c get me "Device not configured" message.. Any clues? --Ugen From owner-freebsd-current Sun Sep 17 11:04:06 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA21438 for current-outgoing; Sun, 17 Sep 1995 11:04:06 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA21430 for ; Sun, 17 Sep 1995 11:03:57 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA11943 (5.65c8/HUTCS-S 1.4 for ); Sun, 17 Sep 1995 19:46:15 +0300 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id TAA01366; Sun, 17 Sep 1995 19:46:13 +0300 Date: Sun, 17 Sep 1995 19:46:13 +0300 Message-Id: <199509171646.TAA01366@shadows.cs.hut.fi> From: Heikki Suonsivu To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@freefall.FreeBSD.org In-Reply-To: J Wunsch's message of 17 Sep 1995 15:06:23 +0300 Subject: Re: pci bus and current?? Organization: Helsinki University of Technology, Otaniemi, Finland Sender: owner-current@FreeBSD.org Precedence: bulk As kmitch wrote: > I just upgraded to the current (9-15), and now my kernel does not > probe my pci bus anymore, and thus can't find my hard drives. Perhaps we could exchange something? My plain old 386sx/16 ISA testbed now starts probing for PCI -- and it actually claims it has FOUND something. :-) Ditto here, with a 386-40 and a 386-33 ISA. It does not seem to harm anything. I didn't care about this originally as diagnostics programs saw ghost devices in 386-33 before (non-existant joystick. If you put one in, none were found :). (How to make buffers larger to catch more of the messages in dmesg?) Sep 17 02:30:12 router /kernel: 32(ffffff80) Sep 17 02:30:12 router /kernel: map(24): mem32(ffffff80) Sep 17 02:30:13 router /kernel: pci0:14: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:13 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:14 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:14 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:16 router /kernel: pci0:15: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:16 router /kernel: pci0:16: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:16 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:16 router /kernel: pci0:17: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:16 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:16 router /kernel: map(24): mem32(ffffff80) Sep 17 02:30:16 router /kernel: pci0:18: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:16 router /kernel: pci0:19: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:16 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:17 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:17 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:17 router /kernel: pci0:20: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:17 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:17 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:17 router /kernel: pci0:21: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:17 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:17 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:18 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:18 router /kernel: map(1c): mem32(ffffff80) Sep 17 02:30:18 router /kernel: map(20): mem32(ffffff80) Sep 17 02:30:18 router /kernel: map(24): mem32(ffffff80) Sep 17 02:30:18 router /kernel: pci0:22: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:18 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:18 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:18 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:18 router /kernel: pci0:23: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:18 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:18 router /kernel: pci0:24: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:19 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:19 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:19 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:19 router /kernel: map(1c): mem32(ffffff80) Sep 17 02:30:19 router /kernel: map(20): mem32(ffffff80) Sep 17 02:30:19 router /kernel: map(24): mem32(ffffff80) Sep 17 02:30:19 router /kernel: pci0:25: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:19 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:19 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:19 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:20 router /kernel: map(1c): mem32(ffffff80) Sep 17 02:30:20 router /kernel: map(20): mem32(ffffff80) Sep 17 02:30:20 router /kernel: pci0:26: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:20 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:20 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:20 router /kernel: pci0:27: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:20 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:20 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:20 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:21 router /kernel: map(1c): mem32(ffffff80) Sep 17 02:30:21 router /kernel: map(20): mem32(ffffff80) Sep 17 02:30:21 router /kernel: map(24): mem32(ffffff80) Sep 17 02:30:21 router /kernel: pci0:28: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:21 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:21 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:21 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:21 router /kernel: map(1c): mem32(ffffff80) Sep 17 02:30:21 router /kernel: map(20): mem32(ffffff80) Sep 17 02:30:22 router /kernel: pci0:29: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:22 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:22 router /kernel: map(14): mem32(ffffff80) Sep 17 02:30:22 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:22 router /kernel: pci0:30: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:22 router /kernel: map(10): mem32(ffffff80) Sep 17 02:30:22 router /kernel: pci0:31: vendor=0xff80, device=0xffff [no driver assigned] Sep 17 02:30:22 router /kernel: map(18): mem32(ffffff80) Sep 17 02:30:23 router /kernel: map(1c): mem32(ffffff80) Sep 17 02:30:23 router /kernel: map(20): mem32(ffffff80) Sep 17 02:30:23 router /kernel: bpf: ds0 attached Sep 17 02:30:23 router /kernel: bpf: lo0 attached Sep 17 02:30:23 router /kernel: bpf: ppp0 attached Sep 17 02:30:23 router /kernel: bpf: ppp1 attached Sep 17 02:30:24 router /kernel: bpf: ppp2 attached Sep 17 02:30:24 router /kernel: bpf: ppp3 attached Sep 17 02:30:24 router /kernel: bpf: ppp4 attached Sep 17 02:30:24 router /kernel: bpf: ppp5 attached Sep 17 02:30:24 router /kernel: bpf: ppp6 attached Sep 17 02:30:24 router /kernel: bpf: ppp7 attached Sep 17 02:30:25 router /kernel: bpf: ppp8 attached Sep 17 02:30:25 router /kernel: bpf: ppp9 attached Sep 17 02:30:25 router /kernel: bpf: ppp10 attached Sep 17 02:30:25 router /kernel: bpf: ppp11 attached Sep 17 02:30:25 router /kernel: bpf: ppp12 attached Sep 17 02:30:25 router /kernel: bpf: ppp13 attached Sep 17 02:30:26 router /kernel: bpf: ppp14 attached Sep 17 02:30:26 router /kernel: bpf: ppp15 attached Sep 17 02:30:26 router /kernel: bpf: ppp16 attached Sep 17 02:30:26 router /kernel: bpf: ppp17 attached Sep 17 02:30:26 router /kernel: bpf: ppp18 attached Sep 17 02:30:27 router /kernel: bpf: ppp19 attached Sep 17 02:30:27 router /kernel: bpf: ppp20 attached Sep 17 02:30:27 router /kernel: bpf: ppp21 attached Sep 17 02:30:27 router /kernel: bpf: ppp22 attached Sep 17 02:30:27 router /kernel: bpf: ppp23 attached Sep 17 02:30:28 router /kernel: bpf: ppp24 attached Sep 17 02:30:28 router /kernel: bpf: ppp25 attached Sep 17 02:30:28 router /kernel: bpf: ppp26 attached Sep 17 02:30:28 router /kernel: bpf: ppp27 attached Sep 17 02:30:28 router /kernel: bpf: ppp28 attached Sep 17 02:30:29 router /kernel: bpf: ppp29 attached Sep 17 02:30:29 router /kernel: bpf: ppp30 attached Sep 17 02:30:29 router /kernel: bpf: ppp31 attached Sep 17 02:30:29 router /kernel: bpf: sl0 attached Sep 17 02:30:29 router /kernel: bpf: sl1 attached Sep 17 02:30:29 router /kernel: bpf: sl2 attached Sep 17 02:30:29 router /kernel: bpf: sl3 attached Sep 17 02:30:29 router /kernel: bpf: sl4 attached Sep 17 02:30:30 router /kernel: bpf: sl5 attached Sep 17 02:30:30 router /kernel: bpf: sl6 attached Sep 17 02:30:30 router /kernel: bpf: sl7 attached Sep 17 02:30:30 router /kernel: bpf: sl8 attached Sep 17 02:30:30 router /kernel: bpf: sl9 attached Sep 17 02:30:30 router /kernel: bpf: sl10 attached Sep 17 02:30:30 router /kernel: bpf: sl11 attached Sep 17 02:30:30 router /kernel: bpf: sl12 attached Sep 17 02:30:30 router /kernel: bpf: sl13 attached Sep 17 02:30:30 router /kernel: bpf: sl14 attached Sep 17 02:30:30 router /kernel: bpf: sl15 attached Sep 17 02:30:30 router /kernel: bpf: tun0 attached Sep 17 02:30:30 router /kernel: bpf: tun1 attached Sep 17 02:30:30 router /kernel: bpf: tun2 attached Sep 17 02:30:30 router /kernel: bpf: tun3 attached Sep 17 02:30:30 router /kernel: bpf: tun4 attached Sep 17 02:30:31 router /kernel: bpf: tun5 attached Sep 17 02:30:31 router /kernel: bpf: tun6 attached Sep 17 02:30:31 router /kernel: bpf: tun7 attached Sep 17 02:30:31 router /kernel: bpf: tun8 attached Sep 17 02:30:31 router /kernel: bpf: tun9 attached Sep 17 02:30:31 router /kernel: bpf: tun10 attached Sep 17 02:30:31 router /kernel: bpf: tun11 attached Sep 17 02:30:31 router /kernel: bpf: tun12 attached Sep 17 02:30:31 router /kernel: bpf: tun13 attached Sep 17 02:30:31 router /kernel: bpf: tun14 attached Sep 17 02:30:31 router /kernel: bpf: tun15 attached Sep 17 02:30:31 router /kernel: bpf: tun16 attached Sep 17 02:30:31 router /kernel: bpf: tun17 attached Sep 17 02:30:32 router /kernel: bpf: tun18 attached Sep 17 02:30:32 router /kernel: bpf: tun19 attached Sep 17 02:30:32 router /kernel: bpf: tun20 attached Sep 17 02:30:32 router /kernel: bpf: tun21 attached Sep 17 02:30:32 router /kernel: bpf: tun22 attached Sep 17 02:30:32 router /kernel: bpf: tun23 attached Sep 17 02:30:32 router /kernel: bpf: tun24 attached Sep 17 02:30:32 router /kernel: bpf: tun25 attached Sep 17 02:30:32 router /kernel: bpf: tun26 attached Sep 17 02:30:32 router /kernel: bpf: tun27 attached Sep 17 02:30:32 router /kernel: bpf: tun28 attached Sep 17 02:30:32 router /kernel: bpf: tun29 attached Sep 17 02:30:32 router /kernel: bpf: tun30 attached Sep 17 02:30:33 router /kernel: bpf: tun31 attached Sep 17 02:30:33 router /kernel: WARNING: / was not properly dismounted. Sep 17 02:30:23 router lpd[99]: restarted -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Sun Sep 17 11:19:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA21998 for current-outgoing; Sun, 17 Sep 1995 11:19:30 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA21993 for ; Sun, 17 Sep 1995 11:19:27 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id PAA02784; Sun, 17 Sep 1995 15:28:20 +0100 From: Paul Richards Message-Id: <199509171428.PAA02784@server.netcraft.co.uk> Subject: Re: libforms - thumbs up or down? To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 17 Sep 1995 15:28:20 +0100 (BST) Cc: paul@FreeBSD.org, current@freefall.freebsd.org In-Reply-To: <199509170923.LAA10739@uriah.heep.sax.de> from "J Wunsch" at Sep 17, 95 11:23:21 am Reply-to: paul@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1370 Sender: owner-current@FreeBSD.org Precedence: bulk In reply to J Wunsch who said > > As Paul Richards wrote: > > > > Hmm, OK. Clear bit rot taken place I think. I've removed libdialog > > from the example and it now compiles and runs. Not a very interesting example > > really but it works now. > > Hmm, okay, now (including the changes of your last commit) it seems to > work. > > Odd points: the frame is drawn as "qxl" characters on an xterm, and Doesn't on mine. Umm, what are "qxl" characters. This is probably something to do with your setup. libforms just uses ncurses and ncurses decides what a ACS_VLINE etc actually is for a particular terminal. > going up with the arrow keys from the QUIT field leaves a "Ca" on the > bottom line (from a previous "Can't go up from this field" message). Looks like a bug. I don't see much point in carrying on with fixing little things like this since this thread started because people want to yank it. I only wanted to fix a few little things to make it actually run so those who were interested could see what the basic idea behind it was. I'll come back to libforms sometime soon since it's actually very close to being finished now that I look at it again but it'll probably not be as part of the FreeBSD project. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Sun Sep 17 11:44:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA22575 for current-outgoing; Sun, 17 Sep 1995 11:44:55 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA22569 ; Sun, 17 Sep 1995 11:44:51 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id TAA04538; Sun, 17 Sep 1995 19:44:13 +0100 From: Paul Richards Message-Id: <199509171844.TAA04538@server.netcraft.co.uk> Subject: Re: Which SUP files are available and where ? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 17 Sep 1995 19:44:12 +0100 (BST) Cc: paul@FreeBSD.org, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@FreeBSD.org In-Reply-To: <21364.811354478@time.cdrom.com> from "Jordan K. Hubbard" at Sep 17, 95 09:14:38 am Reply-to: paul@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3400 Sender: owner-current@FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who said > > > 2.1 should get abandoned immediately with the exception that a truly killer > > bug that is so bad that people can't just work around it until the next relea > se > > may get fixed with a 2.1.1 update. > > This seems contradictory. If 2.1 is "abandoned" then where does 2.1.1 > come from? > > I think it goes without saying that 2.1 will have problems which could > be fixed in a 2.1.1 and that people will strongly urge us to do so. > We *always* have problems with each release. It's a truism. > > > There should be a freeze date on 2.2 when no more experimental or major > > changes are made and after a brief period, say a week or two to make sure it' > s > > basically safe, it should move over to the stable branch. Once 2.1 is out tha > > That sounds OK in theory, but it both assumes that 2.2 is going to be > ready in a timeframe congruent with when people are expecting "their > bugs to be fixed" and that those bugs *will* be fixed in 2.2. Some > 3-5 months after 2.1 we WILL be sitting on a list of problems that > people are getting impatient with and it will be no trivial matter to > just assume that 2.2 will fill the bill. I see experimental changes > going into there for awhile yet, and that doesn't translate to the > kind of "incrementally debugged" release that 2.1.1 would represent. > Well, we're just never going to agree on a release strategy. Who's going to be maintaing 2.1? There may well be a long list of bugs that have surfaced in 2.1 but you're going to have to sit down and work out solutions for most of them independantly of current since it's almost always the case that the bugs we find these days are conceptual problems that are fixed by completely redesigning portions of the system. It's certainly never been easy in the past to retrofit fixes in current to older releases for this very reason. 2 releases a year is probably enough. People just don't want to upgrade much more often than that. 6 months should be more than enough time to get all but the most uncommon bugs out of a release. The problem has always been in the past that no-one is willing to clamp down on current and if people are stilling adding experimental code in 3-5 moths then it'll never converge to a stable state. If we could stick to a 6 month release cycle then there'd be no need for a 2.1.1 release, and if the 6 months is used to properly test the next release then there wouldn't be the continual screw-ups that require point release days after the cdrom ships. As long as the actual task of cutting the cdrom doesn't introduce any bugs then I doubt that 2.1 will have any serious bugs that *require* a point release, since this is the first release in a long time that's had a decent period of testing. If there are no serious bugs then people can wait 6 months until the next release. Would a 2.1.1 release go through the same vigourous testing as 2.1 did, if not I wouldn't consider it an upgrade. Having the ability to do a 2.1.1 release is good, if there are serious bugs we have the ability to fix them but you seem to be suggesting that we continue to work on a 2.1.1 branch while we wait for current to stabilise I wouldn't consider that a very sane idea. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Sun Sep 17 12:15:36 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA23133 for current-outgoing; Sun, 17 Sep 1995 12:15:36 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA23125 for ; Sun, 17 Sep 1995 12:15:17 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA02817; Sun, 17 Sep 1995 21:15:07 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA15625; Sun, 17 Sep 1995 21:15:07 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id TAA15479; Sun, 17 Sep 1995 19:01:16 +0200 From: J Wunsch Message-Id: <199509171701.TAA15479@uriah.heep.sax.de> Subject: Re: libforms - thumbs up or down? To: paul@FreeBSD.org Date: Sun, 17 Sep 1995 19:01:14 +0200 (MET DST) Cc: joerg_wunsch@uriah.heep.sax.de, current@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199509171428.PAA02784@server.netcraft.co.uk> from "Paul Richards" at Sep 17, 95 03:28:20 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 878 Sender: owner-current@FreeBSD.org Precedence: bulk As Paul Richards wrote: > > > Odd points: the frame is drawn as "qxl" characters on an xterm, and > > Doesn't on mine. Umm, what are "qxl" characters. This is probably something > to do with your setup. libforms just uses ncurses and ncurses decides > what a ACS_VLINE etc actually is for a particular terminal. Strange, it happened only in one xterm -- i've tested it in another one, and it works their. (Of course, neither did pkg_manage work.) > I'll come back to libforms sometime soon since it's actually very > close to being finished now that I look at it again but it'll > probably not be as part of the FreeBSD project. I still think it would be nice to have it in ports, just in case somebody else is also interested. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 17 12:45:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA23995 for current-outgoing; Sun, 17 Sep 1995 12:45:45 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA23990 for ; Sun, 17 Sep 1995 12:45:41 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA03409 for ; Sun, 17 Sep 1995 21:45:37 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA16017 for freebsd-current@FreeBSD.ORG; Sun, 17 Sep 1995 21:45:36 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA17303 for freebsd-current@FreeBSD.ORG; Sun, 17 Sep 1995 21:32:33 +0200 From: J Wunsch Message-Id: <199509171932.VAA17303@uriah.heep.sax.de> Subject: Re: COMPAT_43 To: freebsd-current@FreeBSD.ORG Date: Sun, 17 Sep 1995 21:32:32 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.ORG In-Reply-To: from "Ugen J.S.Antsilevich" at Sep 17, 95 01:43:19 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 278 Sender: owner-current@FreeBSD.ORG Precedence: bulk As Ugen J.S.Antsilevich wrote: > > I wonder if this is still happening and COMPAT_43 mandatory ? getty(8) does also require it. :-( -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 17 12:47:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA24055 for current-outgoing; Sun, 17 Sep 1995 12:47:40 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA24050 for ; Sun, 17 Sep 1995 12:47:38 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA10198; Sun, 17 Sep 1995 15:47:26 -0400 Date: Sun, 17 Sep 1995 15:47:26 -0400 From: "Garrett A. Wollman" Message-Id: <9509171947.AA10198@halloran-eldar.lcs.mit.edu> To: rkw@dataplex.net (Richard Wackerbarth) Cc: current@FreeBSD.org Subject: Re: Which SUP files are available and where ? In-Reply-To: References: Sender: owner-current@FreeBSD.org Precedence: bulk < Why bother with "stable" anything. Just call the tree 2.1, 2.2, 2.3, etc. > As for the long term support, I think we should consider CTM as the > distribution mechanism rather than sup. For those who have a high-speed net connection, CTM is a lose. It's too easy to get your source tree into a state where CTM decides that it can't do anything, and then you have to do manual repair, whereas with SUP you can just blow away the breakage and automatically get fresh copies with little or no human intervention. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Sun Sep 17 13:16:39 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA24661 for current-outgoing; Sun, 17 Sep 1995 13:16:39 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA24653 for ; Sun, 17 Sep 1995 13:16:34 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA06599; Sun, 17 Sep 1995 13:14:29 -0700 From: Terry Lambert Message-Id: <199509172014.NAA06599@phaeton.artisoft.com> Subject: Re: libforms - thumbs up or down? To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 17 Sep 1995 13:14:29 -0700 (MST) Cc: paul@FreeBSD.ORG, current@freefall.freebsd.org In-Reply-To: <199509171701.TAA15479@uriah.heep.sax.de> from "J Wunsch" at Sep 17, 95 07:01:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 607 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > Odd points: the frame is drawn as "qxl" characters on an xterm, and > > > > Doesn't on mine. Umm, what are "qxl" characters. This is probably something > > to do with your setup. libforms just uses ncurses and ncurses decides > > what a ACS_VLINE etc actually is for a particular terminal. > > Strange, it happened only in one xterm -- i've tested it in another > one, and it works their. (Of course, neither did pkg_manage work.) It's your font, of course. 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 Sep 17 13:19:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA24720 for current-outgoing; Sun, 17 Sep 1995 13:19:30 -0700 Received: from localhost.lightside.com (user44.lightside.com [198.81.209.44]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA24715 for ; Sun, 17 Sep 1995 13:19:25 -0700 Received: (from jehamby@localhost) by localhost.lightside.com (8.6.12/8.6.9) id NAA00185; Sun, 17 Sep 1995 13:19:58 -0700 Date: Sun, 17 Sep 1995 13:19:33 -0700 (PDT) From: Jake Hamby X-Sender: jehamby@localhost To: jdl@chromatic.com cc: "Jordan K. Hubbard" , current@FreeBSD.org Subject: Re: Release numbering In-Reply-To: <199509170528.AAA14969@chrome.onramp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Sun, 17 Sep 1995, Jon Loeliger wrote: > Apparently, "Jordan K. Hubbard" scribbled: > > The only serious question still to be resolved is just when the > > "rollover" happens? Does 2.1.x live forever, or does it get abandoned > > with 2.2.x is "stable?" > > Personally, I think trying to maintain a strict 2.1 derived base for > a very long time will become fairly problematic. You'll likely end > up with the nightmare of figuring out which variant of which patch > gets applied to which branches and the resulting rev interlock. > Been there done that. Wasn't too much fun then either. > I agree here. Release bug fixes for 2.1.x if something drastic comes up, but as soon as 2.2 becomes as stable as 2.1, push it out the door as a release and start thinking about 2.3. > > > Does 2.1 just become 2.3 at some point, > > leaving the odd numbered releases as the "stable" ones and the even > > numbered ones as "experimental?" > > Isn't that what the makers of the Star Trek movies decided to do? :-) > Oh wait, no. The odd ones sucked and the even ones were good, right? > > Yea, this is probably the basic approach to take. As soon as 2.1 goes > out the door, people are generally going to breath a huge sigh of > relief, take a break, and then be real gung-ho about 2.2. Why not > just let everyone work on 2.2 until it too gets to a reasonably > stable point and then call it "stable" at the same time introduce 2.3 > as the next development release. Just pipeline it, not leapfrog it? I completely agree. Leapfrogging releases a la Linux kernel, is too confusing. People are going to get 2.1, then see 2.2 on the FTP site, not realize it's 2.2-bleeding-edge-sig11, download it, and screw up their machines. I'd rather see a 2.2-current (even though I have ambivalent feelings about the name current to mean "bleeding edge"), that would slowly become 2.2-RELEASE, than a 2.2-current that became 2.3! > > In short, we may be digging ourselves a deep hole if we can't decide > > just how this is all going to work. > > Agreed. Other than the name "current" being a little confusing, the release schedule as it exists now is just fine. But trying to maintain three or four different simultaneous release trees is going to be hell. Having a -stable and a -current is a good idea now, but when 2.1.0 is finally released, we may be able to get away with just a -RELEASE and -current, which would sure save effore integrating changes from -current back into -stable. ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------ From owner-freebsd-current Sun Sep 17 13:37:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA25292 for current-outgoing; Sun, 17 Sep 1995 13:37:14 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA25287 ; Sun, 17 Sep 1995 13:37:08 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA06633; Sun, 17 Sep 1995 13:35:26 -0700 From: Terry Lambert Message-Id: <199509172035.NAA06633@phaeton.artisoft.com> Subject: Re: Which SUP files are available and where ? To: paul@FreeBSD.ORG Date: Sun, 17 Sep 1995 13:35:26 -0700 (MST) Cc: jkh@time.cdrom.com, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@root.com, current@FreeBSD.ORG In-Reply-To: <199509171844.TAA04538@server.netcraft.co.uk> from "Paul Richards" at Sep 17, 95 07:44:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5227 Sender: owner-current@FreeBSD.ORG Precedence: bulk After a release based on a "stable" branch, all patches should be applied to the next release, not to the stable branch post-release. The only exception to this should be a rerelease of the stable branch to correct a gross error in usability (install, etc.). That would bump the minor rev to 2.1.1 (for instance) and is only likely to be done in the first little while after the release (perhaps as a way of tracking release candidates?). The point being that once it is on CDROM, any subsequent changes should go into a different branch tag and the branch tag of the RELEASE frozen. Period. It's *got* to be possible to recover the CDROM image from the CVS tree. After a release there is no "ongoing maintenance" only "new release work". This has to be true because the work that went into making the "stable" branch "stable" in the first place can not be duplicated in the rolling in of a quick patch. By doing ongoing maintenance without equivalently long cycle times, you compromise the meaning of the "stable" tag. > > That sounds OK in theory, but it both assumes that 2.2 is going to be > > ready in a timeframe congruent with when people are expecting "their > > bugs to be fixed" and that those bugs *will* be fixed in 2.2. Well, you can either have a test release or you can have untested code that probably fixes your bugs. Depending on how long you take to complain about a bug after a release, then you may have to accept some destabilizing patches along with the path that fixes your bug, even though they are not logically related ares because of patch overlap (this is incidently why the original patchkit had to centralize patch ordering: to ensure ordered overlap in patches. The current CVS tree enforces this in a much more automatic way, but you are crazy if you think it isn't enforced somewhere). > > I see experimental changes > > going into there for awhile yet, and that doesn't translate to the > > kind of "incrementally debugged" release that 2.1.1 would represent. What's an "experimental change"? Either the experiment fails (and it is removed) or the experiment succeeds (and it becomes part of the main line code). You can't keep an experimental label on something in the main line source tree, only in your personal source tree. This isn't to say that you don't have the ability to use the code revision mechanisms, especially if you are hacing on a tree-accessable machine, by tagging the tree and then working on your own branch. Just that your branch will not be the main line code until you prove your changes. > Who's going to be maintaing 2.1? There may well be a long list of > bugs that have surfaced in 2.1 but you're going to have to sit down > and work out solutions for most of them independantly of current since > it's almost always the case that the bugs we find these days are > conceptual problems that are fixed by completely redesigning portions of > the system. It's certainly never been easy in the past to retrofit fixes > in current to older releases for this very reason. Definitely agree. > 2 releases a year is probably enough. People just don't want to upgrade > much more often than that. 6 months should be more than enough time > to get all but the most uncommon bugs out of a release. The problem has > always been in the past that no-one is willing to clamp down on current > and if people are stilling adding experimental code in 3-5 moths then > it'll never converge to a stable state. Definitely disagree. The quarterly schedule was much more ambitious, but results in a much better pay-off. This was preterbed by the large Net/2 to BSD 4.4-Lite transition problems, but those problems are in the past and there's no reason to not resume quarterly releases. > If we could stick to a 6 month release cycle then there'd be no need for > a 2.1.1 release, and if the 6 months is used to properly test the next > release then there wouldn't be the continual screw-ups that require > point release days after the cdrom ships. As long as the actual task of > cutting the cdrom doesn't introduce any bugs then I doubt that 2.1 will have > any serious bugs that *require* a point release, since this is the first > release in a long time that's had a decent period of testing. If there > are no serious bugs then people can wait 6 months until the next release. I agree that there is probably no need for a 2.1.1, but mostly because of the maintenance issues involve in moving the release base away from a release tag level. I believe that "fixed in the next release" is an adequate answer to any non-fatal bugs. For fatal bugs, the patch can be made, and tested on the problem system *prior* to its inclusion in the source tree. Then it becomes "fixed in the next release" in any case, and people who want it badly enough can do a CVS diff vs. tags before and after the integration to get the changes. > Would a 2.1.1 release go through the same vigourous testing as 2.1 did, > if not I wouldn't consider it an upgrade. Defintely the problem with doing this sort of post-release backpedalling. 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 Sep 17 13:40:26 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA25447 for current-outgoing; Sun, 17 Sep 1995 13:40:26 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA25440 for ; Sun, 17 Sep 1995 13:40:23 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA06645; Sun, 17 Sep 1995 13:38:26 -0700 From: Terry Lambert Message-Id: <199509172038.NAA06645@phaeton.artisoft.com> Subject: Re: Which SUP files are available and where ? To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Sun, 17 Sep 1995 13:38:26 -0700 (MST) Cc: rkw@dataplex.net, current@FreeBSD.ORG In-Reply-To: <9509171947.AA10198@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Sep 17, 95 03:47:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 825 Sender: owner-current@FreeBSD.ORG Precedence: bulk > For those who have a high-speed net connection, CTM is a lose. It's > too easy to get your source tree into a state where CTM decides that > it can't do anything, and then you have to do manual repair, whereas > with SUP you can just blow away the breakage and automatically get > fresh copies with little or no human intervention. I'd still like the ability to do a CVS diff. SUP doesn't pull down the history files. 8-(. Any chance of read-only exporting the CVS tree for anonymous NFS, with special permissions denial on the attic parts that are considered to be non-distributable? A "cvs update" over a high speed link will be a hell of a lot faster than either SUP or CTM. 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 Sep 17 13:54:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA26003 for current-outgoing; Sun, 17 Sep 1995 13:54:49 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA25992 for ; Sun, 17 Sep 1995 13:54:44 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA04683; Sun, 17 Sep 1995 22:54:40 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA16729; Sun, 17 Sep 1995 22:54:39 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA18150; Sun, 17 Sep 1995 22:53:21 +0200 From: J Wunsch Message-Id: <199509172053.WAA18150@uriah.heep.sax.de> Subject: Re: libforms - thumbs up or down? To: terry@lambert.org (Terry Lambert) Date: Sun, 17 Sep 1995 22:53:21 +0200 (MET DST) Cc: joerg_wunsch@uriah.heep.sax.de, paul@FreeBSD.ORG, current@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199509172014.NAA06599@phaeton.artisoft.com> from "Terry Lambert" at Sep 17, 95 01:14:29 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 565 Sender: owner-current@FreeBSD.ORG Precedence: bulk As Terry Lambert wrote: > > > Strange, it happened only in one xterm -- i've tested it in another > > one, and it works their. (Of course, neither did pkg_manage work.) > > It's your font, of course. No way. The very same xterm (it's still there) constantly displays the box characters as xql, while the other window displays them as lines. I've clicked through all fonts that are available in the menu, no change. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 17 16:09:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA02757 for current-outgoing; Sun, 17 Sep 1995 16:09:03 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA02746 ; Sun, 17 Sep 1995 16:08:59 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id QAA03205; Sun, 17 Sep 1995 16:08:42 -0700 From: "Rodney W. Grimes" Message-Id: <199509172308.QAA03205@GndRsh.aac.dev.com> Subject: Re: Which SUP files are available and where ? To: terry@lambert.org (Terry Lambert) Date: Sun, 17 Sep 1995 16:08:41 -0700 (PDT) Cc: paul@FreeBSD.ORG, jkh@time.cdrom.com, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@FreeBSD.ORG In-Reply-To: <199509172035.NAA06633@phaeton.artisoft.com> from "Terry Lambert" at Sep 17, 95 01:35:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3439 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > After a release based on a "stable" branch, all patches should be applied > to the next release, not to the stable branch post-release. > > The only exception to this should be a rerelease of the stable branch to > correct a gross error in usability (install, etc.). That would bump > the minor rev to 2.1.1 (for instance) and is only likely to be done in > the first little while after the release (perhaps as a way of tracking > release candidates?). > > The point being that once it is on CDROM, any subsequent changes should go > into a different branch tag and the branch tag of the RELEASE frozen. > > Period. It's *got* to be possible to recover the CDROM image from the > CVS tree. You should perhaps read more about cvs and go study the tags I have been placing in the tree. I can tag a branch at a state (and have for every single release we have ever rolled) that says this ``IS'' RELENG_2_1_0_RELEASE. I can commit onto the branch (RELENG_2_1_0) any time after that tag working towards RELENG_2_1_1_RELEASE and _still_ cvs co -rRELENG_2_1_0_RELEASE and get exactly what went onto CDROM. There are lots of good reasons to work on the RELENG_2_1_0 branch post release 2_1_0, say a CERT advisory comes out against 2.1.0, simply fix it in the branch, cvs rdiff -rRELENG_2_1_0_RELEASE -rRELENG_2_1_0 and send the patch out. RELENG_2_1_0 is a missnamed tag, it should just be RELENG_2_1 (this is a branch tag, not a state tag), but that is just a name, it has the correct function. > After a release there is no "ongoing maintenance" only "new release work". Wrong, that is one place FreeBSD has surely lacked in being of ``commercial'' quality. I still have support contracts with customers running 1.1.5.1 and I have rolled my own ``update'' kits that include things like the CERT fixes for sendmail, CERT fixes for libskey, CERT fixes for BIND, etc... My customers pay me dearly for this, but are quite glad to know they can come to me and get this type of stuff fixed. FreeBSD, can now, and should start to provide these on its own. I pushed a bit to get this branch stuff done, as it was pretty much what I have been doing in the commercial world of FreeBSD, I just moved it down to FreeFall so _every_ FreeBSD site could have the advantage that an AAC supported site does. My customers tend to land CERT advisories in my lap before I get them from other sources, they have people who keep an eye on that stuff, and these are _CRITICAL_ things to get fixed for many of them as there boxes are the outside internet visible flavor and holes must be plugged asap. > > This has to be true because the work that went into making the "stable" > branch "stable" in the first place can not be duplicated in the rolling > in of a quick patch. By doing ongoing maintenance without equivalently > long cycle times, you compromise the meaning of the "stable" tag. Not if you only fix _CRITICAL_ bugs, and do complete testing of the fix before you intergrate it. This is no different that what is being done to _create_ the 2.1 release as a stabalized release. IMHO, a little too much is coming over, but it is not my *ss on the line if it blows up so I will defer that judgement to those who are doing the work (and it is work, and it is a judgement call). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Sep 17 17:33:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA08385 for current-outgoing; Sun, 17 Sep 1995 17:33:12 -0700 Received: from wiley.csusb.edu (wiley.csusb.edu [139.182.2.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA08380 for ; Sun, 17 Sep 1995 17:33:10 -0700 Received: by wiley.csusb.edu (5.67a/1.34) id AA21675; Sun, 17 Sep 1995 17:38:12 -0700 From: rmallory@wiley.csusb.edu (Rob Mallory) Message-Id: <199509180038.AA21675@wiley.csusb.edu> Subject: Current status report To: freebsd-current@freebsd.org Date: Sun, 17 Sep 1995 17:38:12 -0700 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1190 Sender: owner-current@freebsd.org Precedence: bulk I'm not one to rag on anyone directly; but it's amazing how quiet everyone has been with the current ~sys brokeness in -current. Everyone should be *proud* that there has not been an uproar (at least not on the public mailing lists) about the 3-week lack of a stable kernel. Don't even think about screaming "Current is for those who ..." I have been on -hackers since 1.0. I am lucky [wise] enough to have a spare 1gig drive with a 'current/stable' OS and src tree. ...there are many less fortunate -current users who are "afraid" to speak up (for fear of being flamed, killfile'd, or blacklisted) who are having to re-install 2.1SNAP or sup -stable. I just want to acknowlege those [we] -current users, and possibly get a satisfyingly-complete status report on the current state of the ~sys tree. I really want to get back to testing the new stuff in -current! like the ncr825, userconfig, vm-performance, gus, ... Its hard waiting alone in the dark. issues: (you all know the questions wanted answered) John: I know you're working hard, and we're waiting patiently. PHK: + Crack kills! :) Jordan: Can i have a free tee-shirt? -Rob Mallory [rmallory@csusb.edu] From owner-freebsd-current Sun Sep 17 18:31:59 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA14334 for current-outgoing; Sun, 17 Sep 1995 18:31:59 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA14306 for ; Sun, 17 Sep 1995 18:31:45 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id CAA00443 ; Mon, 18 Sep 1995 02:30:43 +0100 X-Message: This is a dial-up site. Quick responses to e-mails should not be relied upon. Thanks! To: Rob Mallory cc: freebsd-current@freebsd.org Subject: Re: Current status report In-reply-to: Your message of "Sun, 17 Sep 1995 17:38:12 PDT." <199509180038.AA21675@wiley.csusb.edu> Date: Mon, 18 Sep 1995 02:30:41 +0100 Message-ID: <441.811387841@palmer.demon.co.uk> From: Gary Palmer Sender: owner-current@freebsd.org Precedence: bulk In message <199509180038.AA21675@wiley.csusb.edu>, Rob Mallory writes: >I'm not one to rag on anyone directly; but it's amazing how quiet >everyone has been with the current ~sys brokeness in -current. >Everyone should be *proud* that there has not been an uproar >(at least not on the public mailing lists) about the 3-week >lack of a stable kernel. I think there has been an uproar. Just not the out and out flame war that some people may expect. What I think is more important is that people recognise that John, David, et al DO know that there is a problem and are working hard to try and correct it. I'm glad, in a way, that people have not been shouting from the rooftops complaining about this - it'd just slow down any progress towards a working bugfix... >Don't even think about screaming "Current is for those who ..." >I have been on -hackers since 1.0. I am lucky [wise] enough to >have a spare 1gig drive with a 'current/stable' OS and src tree. >...there are many less fortunate -current users who are "afraid" >to speak up (for fear of being flamed, killfile'd, or blacklisted) >who are having to re-install 2.1SNAP or sup -stable. If anyone killfiles or blacklistes ANYONE for putting forward VALID complaints about our source, then they are not acting sensibly and are not representative of the majority of the readers on this list, and certainly not representative of the core team. We NEED feedback! We can't operate in the dark here. Sure, we don't need the kind of mass flaming that I've seen in some instances in the past, but we DO appreciate user feedback, and don't let anyone tell you different. >I just want to acknowlege those [we] -current users, and >possibly get a satisfyingly-complete status report on the current >state of the ~sys tree. I'm sure John or David will post something once they actually KNOW what is going on... Posting incomplete information, or guesswork, often lends to more anger amongst readers than saying nothing at all. >I really want to get back to testing the new stuff in -current! >like the ncr825, userconfig, vm-performance, gus, ... >Its hard waiting alone in the dark. So do we all, but we do put LARGE notices in docs: -current SHOULD NOT BE EXPECTED TO WORK! If you want something that works, use -stable. Freefall is now running from the stable branch, so is wcarchive. Whilst a 3 week outage (has it really been that long? Yipes) is perhaps not expected, and definately not wanted, it is the price of progress... I'd like to thank people for their patience in this matter, and ask them to hold on a while longer. The kernel is a VERY complex beast, and I'm sure that John/David will be able to tame it again soon! Gary From owner-freebsd-current Sun Sep 17 18:37:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA15238 for current-outgoing; Sun, 17 Sep 1995 18:37:53 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA15229 for ; Sun, 17 Sep 1995 18:37:47 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA13212; Sun, 17 Sep 1995 18:37:09 -0700 To: "Garrett A. Wollman" cc: rkw@dataplex.net (Richard Wackerbarth), current@FreeBSD.org Subject: Re: Which SUP files are available and where ? In-reply-to: Your message of "Sun, 17 Sep 1995 15:47:26 EDT." <9509171947.AA10198@halloran-eldar.lcs.mit.edu> Date: Sun, 17 Sep 1995 18:37:09 -0700 Message-ID: <13209.811388229@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > For those who have a high-speed net connection, CTM is a lose. It's > too easy to get your source tree into a state where CTM decides that > it can't do anything, and then you have to do manual repair, whereas Yes, CTM is a nice tool, but it's also not very useful to those of us who need to stay up-to-date on an on-demand basis. I ran with CTM for awhile and generally liked it but then had to back out and go to sup again while we were rolling 2.0.5 - I just wasn't getting the changes when *I* wanted them! sup and CTM were designed to do very *different* things and I don't think that one can replace the other. Jordan From owner-freebsd-current Sun Sep 17 19:19:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA20209 for current-outgoing; Sun, 17 Sep 1995 19:19:32 -0700 Received: from DATAPLEX.NET (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA20196 for ; Sun, 17 Sep 1995 19:19:26 -0700 Received: from [199.183.109.242] by DATAPLEX.NET with SMTP (MailShare 1.0fc5); Sun, 17 Sep 1995 21:18:37 -0600 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 17 Sep 1995 21:18:39 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Which SUP files are available and where ? Cc: "Garrett A. Wollman" , current@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk At 8:37 PM 9/17/95, Jordan K. Hubbard wrote: >sup and CTM were designed to do very *different* things and I don't >think that one can replace the other. I agree. However, I think that 1) There is a strong need to continue to fix bugs in a released version up to the time that the next version is released. (And if you are releasing unstable code, even longer) 2) Since there would not be many patches expected, an event driven system is preferable to a polled system of distribution. 3) We could also offer an "anouncement" service to notify those users who prefer to fetch the updates via ftp or sup. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Mon Sep 18 01:19:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA07753 for current-outgoing; Mon, 18 Sep 1995 01:19:55 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA07748 for ; Mon, 18 Sep 1995 01:19:45 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id SAA16742 for current@freebsd.org; Mon, 18 Sep 1995 18:04:54 +0930 From: Michael Smith Message-Id: <199509180834.SAA16742@genesis.atrad.adelaide.edu.au> Subject: "standard" supfiles as available for FTP To: current@freebsd.org Date: Mon, 18 Sep 1995 18:04:54 +0930 (CST) Content-Type: text Content-Length: 790 Sender: owner-current@freebsd.org Precedence: bulk Just a thought; it might be a good idea to comment out the lines in the various sample supfiles that reference the non-exportable code, so that those of us who just grab them and plug them in aren't suddenly shocked to discover that they're getting lots of things they shouldn't. Also, -STABLE as of friday evening (my time) failed make world inside tn3270. I'm resupping now to be sure before whining 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Mon Sep 18 02:47:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA10257 for current-outgoing; Mon, 18 Sep 1995 02:47:29 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA10238 for ; Mon, 18 Sep 1995 02:47:07 -0700 Received: by Sysiphos id AA29429 (5.67b/IDA-1.5 for current@freebsd.org); Mon, 18 Sep 1995 11:46:01 +0200 Message-Id: <199509180946.AA29429@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 18 Sep 1995 11:46:01 +0200 In-Reply-To: Jean-Marc Zucconi "SCSI bug (possibly in the ncr driver)" (Sep 16, 2:18) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Jean-Marc Zucconi Subject: Re: SCSI bug (possibly in the ncr driver) Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Sep 16, 2:18, Jean-Marc Zucconi wrote: } Subject: SCSI bug (possibly in the ncr driver) } I get the following message whenever I do a msf play command on my } cdroms: } } cd1(ncr0:5:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB } or } cd0(ncr0:3:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB } } Since the scsi code has not changed recently, and since I never had } such errors with an adaptec, I conclude that there is a problem with } my ncr driver... Curiously the other cdrom commands work correctly. } I also get this error with a -stable kernel. Well, the message is quite clear: The CDROMs don't support the command they receive, Don't know, whether the Adaptec implements special magic to better deal with that situation, but it is no driver problem. (Which Adaptec did you use successfully before ?) The driver sent the command, received the status and let the GENERIC SCSI code write that message ... Perhaps it is possible to find out, WHICH field has been the cause of the command failure. But I guess this will require some CDROM technical manuals, that I don't have access to. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Mon Sep 18 02:48:27 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA10312 for current-outgoing; Mon, 18 Sep 1995 02:48:27 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA10284 for ; Mon, 18 Sep 1995 02:47:41 -0700 Resent-Message-Id: <199509180947.CAA10284@freefall.freebsd.org> Received: by Sysiphos id AA29459 (5.67b/IDA-1.5 for current@freebsd.org); Mon, 18 Sep 1995 11:47:18 +0200 Resent-From: se@zpr.uni-koeln.de (Stefan Esser) Resent-Date: Mon, 18 Sep 1995 11:47:17 +0200 X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) Resent-To: current@freebsd.org Received: by Sysiphos id AA29164 (5.67b/IDA-1.5 for se); Mon, 18 Sep 1995 11:33:43 +0200 Message-Id: <199509180933.AA29164@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 18 Sep 1995 11:33:42 +0200 In-Reply-To: J Wunsch "Re: pci bus and current??" (Sep 17, 12:24) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: pci bus and current?? Cc: current@sysiphos.mi.uni-koeln.de Sender: owner-current@freebsd.org Precedence: bulk On Sep 17, 12:24, J Wunsch wrote: } Subject: Re: pci bus and current?? } As kmitch wrote: } > } > } > I just upgraded to the current (9-15), and now my kernel does not } > probe my pci bus anymore, and thus can't find my hard drives. } } Perhaps we could exchange something? My plain old 386sx/16 ISA } testbed now starts probing for PCI -- and it actually claims it has } FOUND something. :-) } } (This is with a GENERIC kernel from a self-compiled RELEASE as of one } week ago CVS sources.) Sorry ... There is the new Compaq Proliant, and I'm not quite sure how to deal with it's lack of PCI compliance. (I received mail from some Compaq employer who admitted that their Triflex chip set had this problem.) Now, I had commited some change, that worked with the Compaq but made some EISA system hang. I tried to avoid the port accesses that seemed to hang the EISA system, but now the tests are too weak, and succeed on some pure ISA systems, too ... :-( Ok. I'll commit a patch later today, which according to all the results I received from several -current users (thanks a lot !) ought to work on ALL systems again. I'll need feedback on that patch ! Sorry for the inconvenience! I'm doing my best to get this sorted out. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Mon Sep 18 03:39:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA11769 for current-outgoing; Mon, 18 Sep 1995 03:39:17 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA11764 for ; Mon, 18 Sep 1995 03:39:14 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id DAA21058; Mon, 18 Sep 1995 03:23:36 -0700 To: se@ZPR.Uni-Koeln.DE (Stefan Esser) cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), current@freefall.FreeBSD.org Subject: Re: pci bus and current?? In-reply-to: Your message of "Mon, 18 Sep 1995 11:33:42 +0200." <199509180933.AA29164@Sysiphos> Date: Mon, 18 Sep 1995 03:23:36 -0700 Message-ID: <21055.811419816@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > Sorry for the inconvenience! I'm doing my best to get this sorted out. And we appreciate that, believe me! Some folks who beat up on our volunteers should appreciate the amount of work involved and the fact that the volunteers are doing all of this *for free*. Stefan deserves praise for his efforts, not flames. I'm happy to say that most people on this list understand that, but there's always the occasional ingrate who behaves as if the world owes him a living.. :-) Also please note that I'm not directing this flame at anyone in particular, just making a general point. Jordan From owner-freebsd-current Mon Sep 18 04:16:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA12653 for current-outgoing; Mon, 18 Sep 1995 04:16:33 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA12646 for ; Mon, 18 Sep 1995 04:16:30 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id HAA14449; Mon, 18 Sep 1995 07:07:22 -0400 From: Peter Dufault Message-Id: <199509181107.HAA14449@hda.com> Subject: Re: SCSI bug (possibly in the ncr driver) To: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 18 Sep 1995 07:07:21 -0400 (EDT) Cc: jmz@cabri.obs-besancon.fr, current@freebsd.org In-Reply-To: <199509180946.AA29429@Sysiphos> from "Stefan Esser" at Sep 18, 95 11:46:01 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1683 Sender: owner-current@freebsd.org Precedence: bulk > > The CDROMs don't support the command they receive, > Don't know, whether the Adaptec implements special > magic to better deal with that situation, but it > is no driver problem. No, there is no magic in the Adaptec driver. > (Which Adaptec did you use successfully before ?) > > The driver sent the command, received the status and > let the GENERIC SCSI code write that message ... The message is from the kernel driver and not the user mode scsi library (I'm just clarifying; you may mean the generic part of the kernel driver but it isn't clear as we have two CDROM programs one using kernel ioctls and the other using the user library). If it worked fine with an Adaptec and now fails with the NCR then the command may be getting stepped on. As Stefan says, this is unlikely: there would probably be problems with commands to other devices. > Perhaps it is possible to find out, WHICH field has > been the cause of the command failure. But I guess > this will require some CDROM technical manuals, that > I don't have access to. You can tell which byte in the command is in error in a command independent way. The user mode library does this. It isn't likely to add that much information. You can turn on debugging in the kernel by compiling with SCSI_DEBUG defined and then use scsi(8) to set a debugging level on the CDROM. This will dump the commands via syslog and we can see if they are intact. Verify that the program does work with the Adaptec. If it does you have found a bug. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-current Mon Sep 18 04:43:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA13116 for current-outgoing; Mon, 18 Sep 1995 04:43:00 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA13109 for ; Mon, 18 Sep 1995 04:42:45 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA21483; Mon, 18 Sep 1995 21:28:53 +1000 Date: Mon, 18 Sep 1995 21:28:53 +1000 From: Bruce Evans Message-Id: <199509181128.VAA21483@godzilla.zeta.org.au> To: hsu@cs.hut.fi, joerg_wunsch@uriah.heep.sax.de Subject: Re: pci bus and current?? Cc: freebsd-current@freefall.freebsd.org Sender: owner-current@FreeBSD.org Precedence: bulk >(How to make buffers larger to catch more of the messages in dmesg?) >Sep 17 02:30:12 router /kernel: 32(ffffff80) >Sep 17 02:30:12 router /kernel: map(24): mem32(ffffff80) >Sep 17 02:30:13 router /kernel: pci0:14: vendor=0xff80, device=0xffff [no driver > assigned] >... You would need an 8MB buffer :-). >Sep 17 02:30:23 router /kernel: bpf: ds0 attached >Sep 17 02:30:23 router /kernel: bpf: lo0 attached >Sep 17 02:30:23 router /kernel: bpf: ppp0 attached >... >Sep 17 02:30:29 router /kernel: bpf: ppp31 attached >Sep 17 02:30:29 router /kernel: bpf: sl0 attached >... >Sep 17 02:30:30 router /kernel: bpf: sl15 attached >Sep 17 02:30:30 router /kernel: bpf: tun0 attached >... >Sep 17 02:30:33 router /kernel: bpf: tun31 attached There are too man bpf messages and not enough messages for the individual pseudo-devices. Bruce From owner-freebsd-current Mon Sep 18 05:23:20 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA13902 for current-outgoing; Mon, 18 Sep 1995 05:23:20 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA13896 for ; Mon, 18 Sep 1995 05:23:14 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA23402; Mon, 18 Sep 1995 22:22:13 +1000 Date: Mon, 18 Sep 1995 22:22:13 +1000 From: Bruce Evans Message-Id: <199509181222.WAA23402@godzilla.zeta.org.au> To: rkw@dataplex.net, wollman@lcs.mit.edu Subject: Re: Which SUP files are available and where ? Cc: current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG Precedence: bulk >> As for the long term support, I think we should consider CTM as the >> distribution mechanism rather than sup. >For those who have a high-speed net connection, CTM is a lose. It's This assumes an infinitely high-speed server or a small number of clients. >too easy to get your source tree into a state where CTM decides that >it can't do anything, and then you have to do manual repair, whereas >with SUP you can just blow away the breakage and automatically get >fresh copies with little or no human intervention. Use restore(8) to recover a consistent state. Bruce From owner-freebsd-current Mon Sep 18 05:25:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA13963 for current-outgoing; Mon, 18 Sep 1995 05:25:24 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA13958 for ; Mon, 18 Sep 1995 05:25:18 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id FAA03970; Mon, 18 Sep 1995 05:23:47 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id FAA03560; Mon, 18 Sep 1995 05:26:06 -0700 Message-Id: <199509181226.FAA03560@corbin.Root.COM> To: Bruce Evans cc: hsu@cs.hut.fi, joerg_wunsch@uriah.heep.sax.de, freebsd-current@freefall.freebsd.org Subject: Re: pci bus and current?? In-reply-to: Your message of "Mon, 18 Sep 95 21:28:53 +1000." <199509181128.VAA21483@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 18 Sep 1995 05:25:43 -0700 Sender: owner-current@FreeBSD.org Precedence: bulk >>(How to make buffers larger to catch more of the messages in dmesg?) > >>Sep 17 02:30:12 router /kernel: 32(ffffff80) >>Sep 17 02:30:12 router /kernel: map(24): mem32(ffffff80) >>Sep 17 02:30:13 router /kernel: pci0:14: vendor=0xff80, device=0xffff [no driver >> assigned] >>... > >You would need an 8MB buffer :-). > >>Sep 17 02:30:23 router /kernel: bpf: ds0 attached >>Sep 17 02:30:23 router /kernel: bpf: lo0 attached >>Sep 17 02:30:23 router /kernel: bpf: ppp0 attached >>... >>Sep 17 02:30:29 router /kernel: bpf: ppp31 attached >>Sep 17 02:30:29 router /kernel: bpf: sl0 attached >>... >>Sep 17 02:30:30 router /kernel: bpf: sl15 attached >>Sep 17 02:30:30 router /kernel: bpf: tun0 attached >>... >>Sep 17 02:30:33 router /kernel: bpf: tun31 attached > >There are too man bpf messages and not enough messages for the individual >pseudo-devices. I think we should kill the "bpf: xxn attached" messages completely. I know I'm not alone in this thinking... -DG From owner-freebsd-current Mon Sep 18 06:28:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA15781 for current-outgoing; Mon, 18 Sep 1995 06:28:01 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA15776 for ; Mon, 18 Sep 1995 06:27:59 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id JAA26101; for ; Mon, 18 Sep 1995 09:27:58 -0400 Date: Mon, 18 Sep 95 09:26:43 PDT From: "Ugen J.S.Antsilevich" Subject: IDE CDROM.. To: freebsd-current@FreeBSD.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk Hi..anyboud out there has IDE CDROM working? --Ugen From owner-freebsd-current Mon Sep 18 07:05:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA16767 for current-outgoing; Mon, 18 Sep 1995 07:05:25 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA16758 ; Mon, 18 Sep 1995 07:05:18 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id PAA14538; Mon, 18 Sep 1995 15:03:40 +0100 From: Paul Richards Message-Id: <199509181403.PAA14538@server.netcraft.co.uk> Subject: Re: Which SUP files are available and where ? To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 18 Sep 1995 15:03:39 +0100 (BST) Cc: terry@lambert.org, paul@FreeBSD.ORG, jkh@time.cdrom.com, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@FreeBSD.ORG In-Reply-To: <199509172308.QAA03205@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Sep 17, 95 04:08:41 pm Reply-to: paul@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3435 Sender: owner-current@FreeBSD.ORG Precedence: bulk In reply to Rodney W. Grimes who said > > > After a release there is no "ongoing maintenance" only "new release work". > > Wrong, that is one place FreeBSD has surely lacked in being of ``commercial'' > quality. I still have support contracts with customers running 1.1.5.1 and > I have rolled my own ``update'' kits that include things like the CERT > fixes for sendmail, CERT fixes for libskey, CERT fixes for BIND, etc... > My customers pay me dearly for this, but are quite glad to know they can > come to me and get this type of stuff fixed. FreeBSD, can now, and should > start to provide these on its own. Well I agree in one sense but not another. I don't think the "FreeBSD team" is in the business of providing support. I think it should concentrate on getting the development work done so I don't want to see that effort diverted to maintaing previous releases except in exceptional cases where serious bugs slipped through. I agree with Terry that for your average FreeBSD user, saying it's fixed in the next release is good enough. Now, where I agree is that there are oppurtunities to offer FreeBSD on a more serious level, where companies pay decent bucks for ongoing support contracts. Providing the mechanism to make this possible is a good thing although it raises more complex issues relating to who has access to the repository and so forth. I should perhaps clarify that the two roles overlap, I'd expect that individual from the "FreeBSD team" would be the one's dealing with support but the abstract entity "FreeBSD team" should be in the business of getting the next release done and not worry about retrofitting various bug fixes into releases that are long gone. There simply aren't the resources to do so. A point release takes the same amount of effort to push out the door as a completely new release, if it's treated with the same level of seriousness. > > This has to be true because the work that went into making the "stable" > > branch "stable" in the first place can not be duplicated in the rolling > > in of a quick patch. By doing ongoing maintenance without equivalently > > long cycle times, you compromise the meaning of the "stable" tag. > > Not if you only fix _CRITICAL_ bugs, and do complete testing of the fix > before you intergrate it. This is no different that what is being done > to _create_ the 2.1 release as a stabalized release. IMHO, a little too > much is coming over, but it is not my *ss on the line if it blows up so > I will defer that judgement to those who are doing the work (and it is > work, and it is a judgement call). I agree with these points, if only critical fixes are done then this is basically what I'm in favour of but I know from experience that not enough restraint is exercised during the release process and that too many things get unecessarily upgraded or enhanced because they seem safe enough or individuals just decide that bits aren't presentable enough and start re-writing them and a 2.1.1 on that basis would be unreliable and would detract from development on -current, which is where such things should take place anyway. 2.1 is likely to be our most stable release for a while because controls have been placed on it and it has been in that "controlled" state for quite a while. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Mon Sep 18 07:17:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA17108 for current-outgoing; Mon, 18 Sep 1995 07:17:32 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA17103 ; Mon, 18 Sep 1995 07:17:24 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA11095; Mon, 18 Sep 1995 10:17:18 -0400 Date: Mon, 18 Sep 1995 10:17:18 -0400 From: "Garrett A. Wollman" Message-Id: <9509181417.AA11095@halloran-eldar.lcs.mit.edu> To: paul@freebsd.org Cc: current@freebsd.org Subject: Public Domain In-Reply-To: <199509181341.OAA14087@server.netcraft.co.uk> References: <199509180558.HAA04433@grumble.grondar.za> <199509181341.OAA14087@server.netcraft.co.uk> Sender: owner-current@freebsd.org Precedence: bulk < said: > I've never been sure how to determine whether something actually > is in the public domain though. According to someone at NCSA, who > I've been discussing licensing with for Apache, you just need a > notice that says "This code is placed in the public domain". The legal situation is rather weird, I am given to understand. In some countries (including some Berne signatories), there simply is no such thing as ``public domain'' within the period where copyright is held to exist. In general, from an international legal perspective, it's almost always a better idea to claim copyright on something and then disclaim all of the attendant rights, rather than to use the public domain tradition which does not legally exist everywhere. (By contrast, in some non-Berne countries, any work which is published without a copyright notice is presumptively in the public domain.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Mon Sep 18 09:20:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA21408 for current-outgoing; Mon, 18 Sep 1995 09:20:01 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA21385 for ; Mon, 18 Sep 1995 09:19:21 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA22099; Mon, 18 Sep 95 18:21:18 +0100 Date: Mon, 18 Sep 95 18:21:18 +0100 Message-Id: <9509181721.AA22099@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: dufault@hda.com Cc: se@zpr.uni-koeln.de, current@freebsd.org In-Reply-To: <199509181107.HAA14449@hda.com> (message from Peter Dufault on Mon, 18 Sep 1995 07:07:21 -0400 (EDT)) Subject: Re: SCSI bug (possibly in the ncr driver) X-Mailer: Emacs Sender: owner-current@freebsd.org Precedence: bulk >>>>> Peter Dufault writes: >> >> The CDROMs don't support the command they receive, >> Don't know, whether the Adaptec implements special >> magic to better deal with that situation, but it >> is no driver problem. > No, there is no magic in the Adaptec driver. >> (Which Adaptec did you use successfully before ?) This was a 1542B >> >> The driver sent the command, received the status and >> let the GENERIC SCSI code write that message ... > The message is from the kernel driver and not the user mode scsi > library (I'm just clarifying; you may mean the generic part of the > kernel driver but it isn't clear as we have two CDROM programs one > using kernel ioctls and the other using the user library). > If it worked fine with an Adaptec and now fails with the NCR then > the command may be getting stepped on. As Stefan says, this is > unlikely: there would probably be problems with commands > to other devices. I have used the same program (cdplay) since FreeBSD 1.1 with the adaptec without any problems, it only fails since I installed the ncr controller! >> Perhaps it is possible to find out, WHICH field has >> been the cause of the command failure. But I guess >> this will require some CDROM technical manuals, that >> I don't have access to. > You can tell which byte in the command is in error in a command > independent way. The user mode library does this. It isn't likely > to add that much information. You can turn on debugging in > the kernel by compiling with SCSI_DEBUG defined and then use scsi(8) > to set a debugging level on the CDROM. This will dump the commands > via syslog and we can see if they are intact. > Verify that the program does work with the Adaptec. If it does > you have found a bug. I no more have the adaptec. However, I have found the problem :-) $ cdplay cd1 CD>tocentry track minute second frame 1 0 2 0 2 22 39 3 255 43 44 3 CD>msfplay 0 2 0 43 44 3 cdplay: Invalid argument #ILLEGAL REQUEST asc:24,0 Invalid field in CDB CD>msfplay 0 2 0 43 44 2 CD>stop I always used the last minute-second-frame with the msf play command. Apparently, one must not play the last frame of the disk. But this does not explain why the adaptec driver does not report the error: the bug is now in the aha1542 driver :-) Jean-Marc > -- > Peter Dufault Real Time Machine Control and Simulation > HD Associates, Inc. Voice: 508 433 6936 > dufault@hda.com Fax: 508 433 5267 _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-current Mon Sep 18 11:58:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA26551 for current-outgoing; Mon, 18 Sep 1995 11:58:15 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA26546 for ; Mon, 18 Sep 1995 11:58:12 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id LAA04341; Mon, 18 Sep 1995 11:57:33 -0700 From: "Rodney W. Grimes" Message-Id: <199509181857.LAA04341@GndRsh.aac.dev.com> Subject: Re: Which SUP files are available and where ? To: bde@zeta.org.au (Bruce Evans) Date: Mon, 18 Sep 1995 11:57:32 -0700 (PDT) Cc: rkw@dataplex.net, wollman@lcs.mit.edu, current@freebsd.org In-Reply-To: <199509181222.WAA23402@godzilla.zeta.org.au> from "Bruce Evans" at Sep 18, 95 10:22:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1318 Sender: owner-current@freebsd.org Precedence: bulk > > >> As for the long term support, I think we should consider CTM as the > >> distribution mechanism rather than sup. > > >For those who have a high-speed net connection, CTM is a lose. It's > > This assumes an infinitely high-speed server or a small number of > clients. You run out of ethernet before you run out of CPU power on anything faster than a DX4/100 with 32MB of memory doing sup services. A Pentium 100 can keep a 100Mb/s pipe clear full of sup with 64Mb of memory. I would call that very very far from ``infinitely high-speed'' and actually falls into the mid-range systems for me. > > >too easy to get your source tree into a state where CTM decides that > >it can't do anything, and then you have to do manual repair, whereas > >with SUP you can just blow away the breakage and automatically get > >fresh copies with little or no human intervention. > > Use restore(8) to recover a consistent state. And now folks know why /usr/src is always a seperate partition on my systems, and on almost everything I sell :-). I do use restore a lot around here, infact installs are actuall ``restores'' of my last known good stable build :-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Sep 18 12:14:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA26945 for current-outgoing; Mon, 18 Sep 1995 12:14:42 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA26933 ; Mon, 18 Sep 1995 12:14:36 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA04387; Mon, 18 Sep 1995 12:14:17 -0700 From: "Rodney W. Grimes" Message-Id: <199509181914.MAA04387@GndRsh.aac.dev.com> Subject: Re: Which SUP files are available and where ? To: paul@freebsd.org Date: Mon, 18 Sep 1995 12:14:16 -0700 (PDT) Cc: terry@lambert.org, jkh@time.cdrom.com, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@freebsd.org In-Reply-To: <199509181403.PAA14538@server.netcraft.co.uk> from "Paul Richards" at Sep 18, 95 03:03:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6464 Sender: owner-current@freebsd.org Precedence: bulk > > In reply to Rodney W. Grimes who said > > > > > After a release there is no "ongoing maintenance" only "new release work". > > > > Wrong, that is one place FreeBSD has surely lacked in being of ``commercial'' > > quality. I still have support contracts with customers running 1.1.5.1 and > > I have rolled my own ``update'' kits that include things like the CERT > > fixes for sendmail, CERT fixes for libskey, CERT fixes for BIND, etc... > > My customers pay me dearly for this, but are quite glad to know they can > > come to me and get this type of stuff fixed. FreeBSD, can now, and should > > start to provide these on its own. > > Well I agree in one sense but not another. I don't think the "FreeBSD team" > is in the business of providing support. I think it should concentrate > on getting the development work done so I don't want to see that > effort diverted to maintaing previous releases except in exceptional > cases where serious bugs slipped through. How about some definitions.... FreeBSD Project: a large mass of folks working on FreeBSD, usually as groups of people called ``teams''. FreeBSD release team: The small group of folks working on producing releases. FreeBSD maintainance team: A non existent group of folks working on fixing critical bugs in the last release, things that create CERT advisories should be fixed by these folks, and releases as a .x point release(s) to all proir production releases created by the ``release team''. This team must have conservative views as to what is a ``fix'' to a realease, and what is a ``new feature''. Major rewrites of code to fix a bug should not be considered by them. Fixing off_t in src/sbin/dump should for all releases lower than 2.1, as should fixing security holes in sendmail on all prior releases to 2.1. My estimate for man power needed here is <8 hours per week, which is about what I spend on doing similiar things for existing customers. FreeBSD developement team: The largest group of folks working on FreeBSD, these are the people who lay down major new functionality and rework code so that it works the ``right way'' for future releases. > I agree with Terry that for > your average FreeBSD user, saying it's fixed in the next release is > good enough. > Well, maybe you should step back and take a closer look as to what some of our ``average FreeBSD users'' are doing with FreeBSD. Believe it or not FreeBSD is becomeing very large in the ISP market segment, these people _must_ have security related bugs fixes in a rapid manner, and infact many of them have there own full time staff to make _sure_ they have these fixes in place. That is a lot of resource that could be pulled into a cooperative effort to create this ``maintaninance team'', and these people tend to be very conservative about doing anything that could degrade there systems. > Now, where I agree is that there are oppurtunities to offer FreeBSD on > a more serious level, where companies pay decent bucks for ongoing > support contracts. Providing the mechanism to make this possible is a good > thing although it raises more complex issues relating to who has access > to the repository and so forth. Simple for me, I shadow off a repository after the release tag and do all my customer support work in there. I am willing to think about provoding this work back to the project for free, but that may be cutting my own throat with respect to why should we pay Accurate Automation for this work when it just turns around and gives it away. Well, I have a simple answer for that, if no one pays me to do it I ain't going to do it at all. Simple business folks, yes, I am now fully in the Commercial FreeBSD business, work won't come from me on this project unless someone is footing the bill to have me do it, I simply no longer have the time to give away massive numbers of my hours :-(. > I should perhaps clarify that the two roles overlap, I'd expect that > individual from the "FreeBSD team" would be the one's dealing with > support but the abstract entity "FreeBSD team" should be in the business > of getting the next release done and not worry about retrofitting various > bug fixes into releases that are long gone. There simply aren't the resources > to do so. A point release takes the same amount of effort to push out the > door as a completely new release, if it's treated with the same level of > seriousness. > > > > > This has to be true because the work that went into making the "stable" > > > branch "stable" in the first place can not be duplicated in the rolling > > > in of a quick patch. By doing ongoing maintenance without equivalently > > > long cycle times, you compromise the meaning of the "stable" tag. > > > > Not if you only fix _CRITICAL_ bugs, and do complete testing of the fix > > before you intergrate it. This is no different that what is being done > > to _create_ the 2.1 release as a stabalized release. IMHO, a little too > > much is coming over, but it is not my *ss on the line if it blows up so > > I will defer that judgement to those who are doing the work (and it is > > work, and it is a judgement call). > > I agree with these points, if only critical fixes are done then this is > basically what I'm in favour of but I know from experience that not > enough restraint is exercised during the release process and that too many > things get unecessarily upgraded or enhanced because they seem safe enough > or individuals just decide that bits aren't presentable enough and start > re-writing them and a 2.1.1 on that basis would be unreliable and would > detract from development on -current, which is where such things should > take place anyway. 2.1 is likely to be our most stable release for a while > because controls have been placed on it and it has been in that "controlled" > state for quite a while. Point well made, but I think being in a ``maintainance mode'' after a release fully knowing that 2.2 is coming will help curtail a lot of the ``pull the latest wizzy wig into the branch'' problem that has pleagued the release person or team over the years. People won't be pusing to get stuff into the maintainance branch, they will be pusing to get things into the next release branch, thus eliminating a lot of the problem. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Sep 18 12:18:38 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27120 for current-outgoing; Mon, 18 Sep 1995 12:18:38 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27115 for ; Mon, 18 Sep 1995 12:18:33 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA04397; Mon, 18 Sep 1995 12:16:43 -0700 From: "Rodney W. Grimes" Message-Id: <199509181916.MAA04397@GndRsh.aac.dev.com> Subject: Re: pci bus and current?? To: davidg@Root.COM Date: Mon, 18 Sep 1995 12:16:42 -0700 (PDT) Cc: bde@zeta.org.au, hsu@cs.hut.fi, joerg_wunsch@uriah.heep.sax.de, freebsd-current@freefall.freebsd.org In-Reply-To: <199509181226.FAA03560@corbin.Root.COM> from "David Greenman" at Sep 18, 95 05:25:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1363 Sender: owner-current@FreeBSD.org Precedence: bulk > > >>(How to make buffers larger to catch more of the messages in dmesg?) > > > >>Sep 17 02:30:12 router /kernel: 32(ffffff80) > >>Sep 17 02:30:12 router /kernel: map(24): mem32(ffffff80) > >>Sep 17 02:30:13 router /kernel: pci0:14: vendor=0xff80, device=0xffff [no driver > >> assigned] > >>... > > > >You would need an 8MB buffer :-). > > > >>Sep 17 02:30:23 router /kernel: bpf: ds0 attached > >>Sep 17 02:30:23 router /kernel: bpf: lo0 attached > >>Sep 17 02:30:23 router /kernel: bpf: ppp0 attached > >>... > >>Sep 17 02:30:29 router /kernel: bpf: ppp31 attached > >>Sep 17 02:30:29 router /kernel: bpf: sl0 attached > >>... > >>Sep 17 02:30:30 router /kernel: bpf: sl15 attached > >>Sep 17 02:30:30 router /kernel: bpf: tun0 attached > >>... > >>Sep 17 02:30:33 router /kernel: bpf: tun31 attached > > > >There are too man bpf messages and not enough messages for the individual > >pseudo-devices. > > I think we should kill the "bpf: xxn attached" messages completely. I know > I'm not alone in this thinking... Or perhaps reduce the noise level and simply output it during the if_attach as a ``bpf capable'': de0: DC21140 [10-100Mb/s] pass 1.1 Ethernet address 00:00:c0:c5:f5:9d bpf -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Sep 18 12:22:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27198 for current-outgoing; Mon, 18 Sep 1995 12:22:11 -0700 Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27193 for ; Mon, 18 Sep 1995 12:22:02 -0700 Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.8/8.6.6) with SMTP id NAA25432 for ; Mon, 18 Sep 1995 13:20:59 -0600 Message-Id: <199509181920.NAA25432@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol From: Steve Passe To: current@freebsd.org Subject: Re: Which SUP files are available and where ? In-reply-to: Your message of "Mon, 18 Sep 1995 11:57:32 PDT." <199509181857.LAA04341@GndRsh.aac.dev.com> Date: Mon, 18 Sep 1995 13:20:59 -0600 Sender: owner-current@freebsd.org Precedence: bulk Hi, > And now folks know why /usr/src is always a seperate partition on my s what is a healthy size for a /usr/src partition in which you plan to 'make World'? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-current Mon Sep 18 12:43:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28013 for current-outgoing; Mon, 18 Sep 1995 12:43:23 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27998 ; Mon, 18 Sep 1995 12:43:18 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id UAA20900; Mon, 18 Sep 1995 20:42:32 +0100 From: Paul Richards Message-Id: <199509181942.UAA20900@server.netcraft.co.uk> Subject: Re: Which SUP files are available and where ? To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 18 Sep 1995 20:42:31 +0100 (BST) Cc: paul@freebsd.org, terry@lambert.org, jkh@time.cdrom.com, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@freebsd.org In-Reply-To: <199509181914.MAA04387@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Sep 18, 95 12:14:16 pm Reply-to: paul@freebsd.org X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4992 Sender: owner-current@freebsd.org Precedence: bulk In reply to Rodney W. Grimes who said > > > I agree with Terry that for > > your average FreeBSD user, saying it's fixed in the next release is > > good enough. > > > > Well, maybe you should step back and take a closer look as to what some > of our ``average FreeBSD users'' are doing with FreeBSD. Believe it or > not FreeBSD is becomeing very large in the ISP market segment, these > people _must_ have security related bugs fixes in a rapid manner, and > infact many of them have there own full time staff to make _sure_ they > have these fixes in place. That is a lot of resource that could be pulled > into a cooperative effort to create this ``maintaninance team'', and these > people tend to be very conservative about doing anything that could degrade > there systems. Well, I'd disagree about numbers but I appreciate their importance. I agree 100% that there needs to be a group to deal with this side of things but I think the current FreeBSD project is not capable of dealing with such issues. There need to be an bodies that deal with support but not the current setup. > > > Now, where I agree is that there are oppurtunities to offer FreeBSD on > > a more serious level, where companies pay decent bucks for ongoing > > support contracts. Providing the mechanism to make this possible is a good > > thing although it raises more complex issues relating to who has access > > to the repository and so forth. > > Simple for me, I shadow off a repository after the release tag and do > all my customer support work in there. I am willing to think about Yeah well, that's what I meant. You and I have access to the repository but your average company that might want to offer support doesn't. That's probably good since the core team would then have to decide whether a particular group or company should be given access to "internal" project information. I think various things external to the "core" of the project, like support companies popping up, will mean these issues will have to be looked at soon. > > I should perhaps clarify that the two roles overlap, I'd expect that > > individual from the "FreeBSD team" would be the one's dealing with > > support but the abstract entity "FreeBSD team" should be in the business > > of getting the next release done and not worry about retrofitting various > > bug fixes into releases that are long gone. There simply aren't the resources > > to do so. A point release takes the same amount of effort to push out the > > door as a completely new release, if it's treated with the same level of > > seriousness. > > > > > > > > This has to be true because the work that went into making the "stable" > > > > branch "stable" in the first place can not be duplicated in the rolling > > > > in of a quick patch. By doing ongoing maintenance without equivalently > > > > long cycle times, you compromise the meaning of the "stable" tag. > > > > > > Not if you only fix _CRITICAL_ bugs, and do complete testing of the fix > > > before you intergrate it. This is no different that what is being done > > > to _create_ the 2.1 release as a stabalized release. IMHO, a little too > > > much is coming over, but it is not my *ss on the line if it blows up so > > > I will defer that judgement to those who are doing the work (and it is > > > work, and it is a judgement call). > > > > I agree with these points, if only critical fixes are done then this is > > basically what I'm in favour of but I know from experience that not > > enough restraint is exercised during the release process and that too many > > things get unecessarily upgraded or enhanced because they seem safe enough > > or individuals just decide that bits aren't presentable enough and start > > re-writing them and a 2.1.1 on that basis would be unreliable and would > > detract from development on -current, which is where such things should > > take place anyway. 2.1 is likely to be our most stable release for a while > > because controls have been placed on it and it has been in that "controlled" > > state for quite a while. > > Point well made, but I think being in a ``maintainance mode'' after a release > fully knowing that 2.2 is coming will help curtail a lot of the ``pull the > latest wizzy wig into the branch'' problem that has pleagued the release > person or team over the years. People won't be pusing to get stuff into > the maintainance branch, they will be pusing to get things into the next > release branch, thus eliminating a lot of the problem. I honestly doubt it. We'll just have another 2.0.5 scenario, where decisions are made to make a "bug fix only" interim release because current isn't stable enough yet and instead of a bug-fix release it turns into a full featured re-write, delaying 2.1 probably by 6 months. This is exactly what I fear 2.1.1 would be. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Mon Sep 18 12:54:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28625 for current-outgoing; Mon, 18 Sep 1995 12:54:28 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA28619 for ; Mon, 18 Sep 1995 12:54:23 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA04491; Mon, 18 Sep 1995 12:53:58 -0700 From: "Rodney W. Grimes" Message-Id: <199509181953.MAA04491@GndRsh.aac.dev.com> Subject: Re: Which SUP files are available and where ? To: smp@csn.net (Steve Passe) Date: Mon, 18 Sep 1995 12:53:58 -0700 (PDT) Cc: current@freebsd.org In-Reply-To: <199509181920.NAA25432@clem.systemsix.com> from "Steve Passe" at Sep 18, 95 01:20:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 569 Sender: owner-current@freebsd.org Precedence: bulk > > Hi, > > > And now folks know why /usr/src is always a seperate partition on my > s > > what is a healthy size for a /usr/src partition in which you plan to > 'make World'? I use 160MB, but /usr/obj is _not_ on there, that is room for full source and a few kernel compiles: /dev/sd0g 158863 128545 17608 88% /usr/src SkyRsh# ls /sys/compile .keep_me CVS SKYRSH SkyRsh# -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Sep 18 12:56:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28779 for current-outgoing; Mon, 18 Sep 1995 12:56:24 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA28764 for ; Mon, 18 Sep 1995 12:56:14 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA23855 for ; Mon, 18 Sep 1995 21:52:36 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA02919 for freebsd-current@FreeBSD.org; Mon, 18 Sep 1995 21:52:32 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA01964 for freebsd-current@FreeBSD.org; Mon, 18 Sep 1995 21:37:11 +0200 From: J Wunsch Message-Id: <199509181937.VAA01964@uriah.heep.sax.de> Subject: Re: pci bus and current?? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 18 Sep 1995 21:37:11 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) In-Reply-To: <21055.811419816@time.cdrom.com> from "Jordan K. Hubbard" at Sep 18, 95 03:23:36 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 996 Sender: owner-current@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > > Sorry for the inconvenience! I'm doing my best to get this sorted out. > > And we appreciate that, believe me! Of course! > Some folks who beat up on our volunteers should appreciate the amount > of work involved and the fact that the volunteers are doing all of > this *for free*. Hehe, i haven't been flaming here... ;), i've put a smiley behind my observation, i've _really_ been smiling when i've first seen my 386/16 detecting the PCI devices. 8^) No offense intented, this is the kind of breakage that could always happen during a development cycle (and this one was actually benign, just a bit funny). In particular, i know that Stefan has always been one of those guys with very short response times in case of trouble, either on the lists as well as in Usenet. (His apologies are almost unnecessary.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Sep 18 13:14:50 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA29684 for current-outgoing; Mon, 18 Sep 1995 13:14:50 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA29673 for ; Mon, 18 Sep 1995 13:14:37 -0700 Received: by Sysiphos id AA05523 (5.67b/IDA-1.5 for freebsd-current@FreeBSD.org); Mon, 18 Sep 1995 22:14:16 +0200 Message-Id: <199509182014.AA05523@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 18 Sep 1995 22:14:15 +0200 In-Reply-To: J Wunsch "Re: pci bus and current??" (Sep 18, 21:37) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: freebsd-current@freebsd.org (FreeBSD-current users) Subject: Re: pci bus and current?? Sender: owner-current@freebsd.org Precedence: bulk On Sep 18, 21:37, J Wunsch wrote: } Subject: Re: pci bus and current?? } Hehe, i haven't been flaming here... ;), i've put a smiley behind my } observation, i've _really_ been smiling when i've first seen my 386/16 } detecting the PCI devices. 8^) Hallo Joerg! Ich hab das auch ueberhaupt nicht negativ aufgefasst (und dafuer waere noch nicht mal der Smiley noetig gewesen :) Eigentlich sollte ich das als Software-Upgrade verkaufen, der auch alte Systeme mit PCI-Eigenschaften ausstattet, wenn der Besitzer es nur schafft die Karten hineinzustecken :) BTW: Ich hoffe, dass es mit Deinem neuen Job gut laeuft ... Viele Gruesse, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Mon Sep 18 13:37:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA01158 for current-outgoing; Mon, 18 Sep 1995 13:37:35 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA01144 for ; Mon, 18 Sep 1995 13:37:27 -0700 Received: from puffin.pelican.com by pelican.com with smtp (Smail3.1.28.1 #5) id m0sumwK-000K2mC; Mon, 18 Sep 95 13:37 WET DST Received: by puffin.pelican.com (Smail3.1.29.1 #9) id m0sumwK-0000ReC; Mon, 18 Sep 95 13:37 PDT Message-Id: From: pete@puffin.pelican.com (Pete Carah) Subject: stable ebones, sup last Sat... To: current@freebsd.org Date: Mon, 18 Sep 1995 13:37:20 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1765 Sender: owner-current@freebsd.org Precedence: bulk did this: --------------------------------------------------------------------- cc -O -DDES_ENCRYPT -DKRBDES_ENCRYPT -I/u3/home/pete/src-2.0/eBones/des/include -I/u3/home/pete/src-2.0/eBones/des/../include -DAUTHENTICATE -I/u3/home/pete/src-2.0/eBones/des/../../include -Wall -I/u3/home/pete/src-2.0/eBones/des/../../include -Wall -c /u3/home/pete/src-2.0/eBones/des/ecb_enc.c -o ecb_enc.o In file included from /u3/home/pete/src-2.0/eBones/des/ecb_enc.c:9: /u3/home/pete/src-2.0/eBones/des/include/spr.h:10: warning: missing braces around initializer for `des_SPtrans[0]' cc -O -DDES_ENCRYPT -DKRBDES_ENCRYPT -I/u3/home/pete/src-2.0/eBones/des/include -I/u3/home/pete/src-2.0/eBones/des/../include -DAUTHENTICATE -I/u3/home/pete/src-2.0/eBones/des/../../include -Wall -I/u3/home/pete/src-2.0/eBones/des/../../include -Wall -c /u3/home/pete/src-2.0/eBones/des/enc_read.c -o enc_read.o In file included from /u3/home/pete/src-2.0/eBones/des/include/des_locl.h:9, from /u3/home/pete/src-2.0/eBones/des/enc_read.c:12: /u3/home/pete/src-2.0/eBones/des/include/des.h:102: conflicting types for `crypt' /u3/home/pete/src-2.0/eBones/des/../../include/unistd.h:108: previous declaration of `crypt' *** Error code 1 Stop. *** Error code 1 Stop. --------------------------------------------------------------------- US ebones: The warning in spr.h may not be a problem but the other is. This was part of a proper make world with -DMAKE_EBONES and -DNOLKM I don't see any other mail. This was overlaying a -current of about 3 weeks before. Make world may be missing a critical 'beforeinstall' or have the lib changes to ebones made it into 'stable' and caused this? (or the reverse - is stable's ebones a reversion from current of 3 wks ago?) -- Pete From owner-freebsd-current Mon Sep 18 13:58:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA02241 for current-outgoing; Mon, 18 Sep 1995 13:58:05 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA02234 for ; Mon, 18 Sep 1995 13:58:02 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id NAA13810; Mon, 18 Sep 1995 13:57:45 -0700 Message-Id: <199509182057.NAA13810@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: pete@puffin.pelican.com (Pete Carah) cc: current@freebsd.org Subject: Re: stable ebones, sup last Sat... In-reply-to: Your message of "Mon, 18 Sep 1995 13:37:20 PDT." Date: Mon, 18 Sep 1995 13:57:44 -0700 From: "Justin T. Gibbs" Sender: owner-current@freebsd.org Precedence: bulk >did this: >In file included from /u3/home/pete/src-2.0/eBones/des/include/des_locl.h:9, > from /u3/home/pete/src-2.0/eBones/des/enc_read.c:12: >/u3/home/pete/src-2.0/eBones/des/include/des.h:102: conflicting types for `cry >pt' >/u3/home/pete/src-2.0/eBones/des/../../include/unistd.h:108: previous declarat >ion of `crypt' eBones/des/include/des.h is no longer in the repository for either current or stable. Something is not synced in your tree. >-- Pete -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 18 14:37:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA03576 for current-outgoing; Mon, 18 Sep 1995 14:37:22 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA03569 for ; Mon, 18 Sep 1995 14:37:18 -0700 Received: by Sysiphos id AA05605 (5.67b/IDA-1.5 for freebsd-current@FreeBSD.org); Mon, 18 Sep 1995 23:37:13 +0200 Message-Id: <199509182137.AA05605@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 18 Sep 1995 23:37:13 +0200 In-Reply-To: J Wunsch "Re: pci bus and current??" (Sep 18, 21:37) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: freebsd-current@freebsd.org (FreeBSD-current users) Subject: Re: pci bus and current?? Sender: owner-current@freebsd.org Precedence: bulk On Sep 18, 21:37, J Wunsch wrote: } Subject: Re: pci bus and current?? Sorry, my reply to Joerg was not meant to be sent to the list ... (I missed the fact, that his message had a "Return-To: current" header line.) STefan From owner-freebsd-current Mon Sep 18 14:50:06 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA04141 for current-outgoing; Mon, 18 Sep 1995 14:50:06 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA04130 for ; Mon, 18 Sep 1995 14:49:20 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id XAA05484; Mon, 18 Sep 1995 23:48:33 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id XAA15561; Mon, 18 Sep 1995 23:48:32 +0200 Message-Id: <199509182148.XAA15561@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: pete@puffin.pelican.com (Pete Carah) cc: current@FreeBSD.ORG Subject: Re: stable ebones, sup last Sat... Date: Mon, 18 Sep 1995 23:48:32 +0200 From: Mark Murray Sender: owner-current@FreeBSD.ORG Precedence: bulk Hi A lot of stuff got moved around. You may not be totally up to date, particularly your include/des.h. > did this: > --------------------------------------------------------------------- > cc -O -DDES_ENCRYPT -DKRBDES_ENCRYPT -I/u3/home/pete/src-2.0/eBones/des/inclu de -I/u3/home/pete/src-2.0/eBones/des/../include -DAUTHENTICATE -I/u3/home/pete /src-2.0/eBones/des/../../include -Wall -I/u3/home/pete/src-2.0/eBones/des/../. ./include -Wall -c /u3/home/pete/src-2.0/eBones/des/ecb_enc.c -o ecb_enc.o > In file included from /u3/home/pete/src-2.0/eBones/des/ecb_enc.c:9: > /u3/home/pete/src-2.0/eBones/des/include/spr.h:10: warning: missing braces ar ound initializer for `des_SPtrans[0]' > cc -O -DDES_ENCRYPT -DKRBDES_ENCRYPT -I/u3/home/pete/src-2.0/eBones/des/inclu de -I/u3/home/pete/src-2.0/eBones/des/../include -DAUTHENTICATE -I/u3/home/pete /src-2.0/eBones/des/../../include -Wall -I/u3/home/pete/src-2.0/eBones/des/../. ./include -Wall -c /u3/home/pete/src-2.0/eBones/des/enc_read.c -o enc_read.o > In file included from /u3/home/pete/src-2.0/eBones/des/include/des_locl.h:9, > from /u3/home/pete/src-2.0/eBones/des/enc_read.c:12: > /u3/home/pete/src-2.0/eBones/des/include/des.h:102: conflicting types for `cr ypt' > /u3/home/pete/src-2.0/eBones/des/../../include/unistd.h:108: previous declara tion of `crypt' > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > --------------------------------------------------------------------- > US ebones: > > The warning in spr.h may not be a problem but the other is. > This was part of a proper make world with -DMAKE_EBONES and -DNOLKM > > I don't see any other mail. This was overlaying a -current of about > 3 weeks before. Make world may be missing a critical 'beforeinstall' > or have the lib changes to ebones made it into 'stable' and caused > this? (or the reverse - is stable's ebones a reversion from current > of 3 wks ago?) > > -- Pete -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Mon Sep 18 21:31:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA01582 for current-outgoing; Mon, 18 Sep 1995 21:31:14 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA01563 ; Mon, 18 Sep 1995 21:31:09 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id VAA00892; Mon, 18 Sep 1995 21:30:57 -0700 To: "Rodney W. Grimes" cc: paul@freebsd.org, terry@lambert.org, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@freebsd.org Subject: Re: Which SUP files are available and where ? In-reply-to: Your message of "Mon, 18 Sep 1995 12:14:16 PDT." <199509181914.MAA04387@GndRsh.aac.dev.com> Date: Mon, 18 Sep 1995 21:30:57 -0700 Message-ID: <890.811485057@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Well, maybe you should step back and take a closer look as to what some > of our ``average FreeBSD users'' are doing with FreeBSD. Believe it or > not FreeBSD is becomeing very large in the ISP market segment, these > people _must_ have security related bugs fixes in a rapid manner, and > infact many of them have there own full time staff to make _sure_ they > have these fixes in place. That is a lot of resource that could be pulled > into a cooperative effort to create this ``maintaninance team'', and these > people tend to be very conservative about doing anything that could degrade > there systems. I think we (the project) are perhaps getting back into the grey zone we were in for awhile when Karl Denninger was having all those problems with FreeBSD and had our guys running in circles trying to fix them. When you're small, you can afford to blur the lines of distinction a little and treat all users alike. As we become more successful, I think that a commercial enterprise will become inevitable. Why? Several reasons: 1. You can't expect volunteers to hop for you, and hopping is sometimes required (the CERT advisories are a good example). 2. The FreeBSD project has a duty to the free software world first and the commercial world second. Since it's not being supported by the commercial world, that simply stands to reason and a lot of people are only in it for the joy of it anyway. This means that if a lot of our time is subverted into doing support, we're doing a disservice to all the other users - 10% of the users end up taking 90% of the resources. 3. The commercial interests *want* someone to be accountable for the software. Your own success at building and supporting systems is prima facie evidence of this. I'm not sure when or if that'll happen, mind you, but like I said - I think it's an inevitable consequence of our increasing success. Jordan From owner-freebsd-current Tue Sep 19 00:11:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA14252 for current-outgoing; Tue, 19 Sep 1995 00:11:53 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA14246 for ; Tue, 19 Sep 1995 00:11:44 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id QAA19284 for current@freebsd.org; Tue, 19 Sep 1995 16:57:23 +0930 From: Michael Smith Message-Id: <199509190727.QAA19284@genesis.atrad.adelaide.edu.au> Subject: Problems building -STABLE 8(* To: current@freebsd.org Date: Tue, 19 Sep 1995 16:57:22 +0930 (CST) Content-Type: text Content-Length: 966 Sender: owner-current@freebsd.org Precedence: bulk For want of stable@freebsd.org ... I've got an interesting one here. Building -stable supped as of ~24 hours ago, make world stops while building tn3270 (yuk 8). The problem is that the 'mkastosc' tool is being built in its source directory, not in an obj/ subdirectory, so later when it is invoked out of the obj/ subdirectory, the build fails. Given the lack of unhappy wailing from other quarters, I'm curious as to what the deal is here - do I have a broken obj tree? (/usr/src is a symlink to an NFS mountpount, /usr/obj is a symlink to a directory off the /usr filesystem) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Tue Sep 19 00:26:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA15004 for current-outgoing; Tue, 19 Sep 1995 00:26:18 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA14997 for ; Tue, 19 Sep 1995 00:26:09 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA30253; Tue, 19 Sep 1995 17:18:10 +1000 Date: Tue, 19 Sep 1995 17:18:10 +1000 From: Bruce Evans Message-Id: <199509190718.RAA30253@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@GndRsh.aac.dev.com Subject: Re: Which SUP files are available and where ? Cc: current@freebsd.org, rkw@dataplex.net, wollman@lcs.mit.edu Sender: owner-current@freebsd.org Precedence: bulk >> >For those who have a high-speed net connection, CTM is a lose. It's >> >> This assumes an infinitely high-speed server or a small number of >> clients. >You run out of ethernet before you run out of CPU power on anything >faster than a DX4/100 with 32MB of memory doing sup services. A >Pentium 100 can keep a 100Mb/s pipe clear full of sup with 64Mb of >memory. I would call that very very far from ``infinitely high-speed'' >and actually falls into the mid-range systems for me. I thought that the CPU ran out of power before the pipe was half full, even doing raw data movement for nfs. For sup it will have to traverse file systems so it will be hard to get more than 1MB of throughput per file system. How much throughput can you get through sup? Is it as fast as cvs co ;-). When did FreeFall get a 100 Mb/s pipe? Bruce From owner-freebsd-current Tue Sep 19 02:59:38 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA23114 for current-outgoing; Tue, 19 Sep 1995 02:59:38 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA23106 for ; Tue, 19 Sep 1995 02:59:32 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id CAA05609; Tue, 19 Sep 1995 02:58:40 -0700 From: "Rodney W. Grimes" Message-Id: <199509190958.CAA05609@GndRsh.aac.dev.com> Subject: Re: Which SUP files are available and where ? To: bde@zeta.org.au (Bruce Evans) Date: Tue, 19 Sep 1995 02:58:40 -0700 (PDT) Cc: bde@zeta.org.au, current@freebsd.org, rkw@dataplex.net, wollman@lcs.mit.edu In-Reply-To: <199509190718.RAA30253@godzilla.zeta.org.au> from "Bruce Evans" at Sep 19, 95 05:18:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2110 Sender: owner-current@freebsd.org Precedence: bulk > > >> >For those who have a high-speed net connection, CTM is a lose. It's > >> > >> This assumes an infinitely high-speed server or a small number of > >> clients. > > >You run out of ethernet before you run out of CPU power on anything > >faster than a DX4/100 with 32MB of memory doing sup services. A > >Pentium 100 can keep a 100Mb/s pipe clear full of sup with 64Mb of > >memory. I would call that very very far from ``infinitely high-speed'' > >and actually falls into the mid-range systems for me. > > I thought that the CPU ran out of power before the pipe was half full, > even doing raw data movement for nfs. I have done iozones over NFS on 100BaseTx networking and seen numbers well in excess of 3MBytes/s reading (forget about writting, we all know sync nfs is dog slow at that). > For sup it will have to traverse > file systems so it will be hard to get more than 1MB of throughput per > file system. File system bandwidth is not a problem. Again, I can produce iozone results in excess of 6MB/sec quite easily on local fast disks. >How much throughput can you get through sup? That is one I have not measures. > Is it as fast as cvs co ;-). A _LOT_ faster when you are talking about the two running over local ethernet. NFS gets in the way a bit. Sup is slow over long RTT links due to the 2 RTT needed for many of the things it does, it is blazing fast on local networks (and smokes on 100Mb/s networks :-)). I can probably sup a src tree via localhost faster than I could cvs co the same one if you wanted to test this out on a local machine. cvs co is slow due to all the . lock files that go on, sup is fast as it reads an index file and starts pumping data. > When did FreeFall get a 100 Mb/s pipe? It didn't, I have 100BaseTX here, hub and all.... NFS diskless is about to become real for me again :-) And the server is on a UPS with very realiable hardware so my writes are going to be async and fast :-). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Sep 19 03:40:48 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA25500 for current-outgoing; Tue, 19 Sep 1995 03:40:48 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA25495 for ; Tue, 19 Sep 1995 03:40:40 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA04813; Tue, 19 Sep 1995 20:35:03 +1000 Date: Tue, 19 Sep 1995 20:35:03 +1000 From: Bruce Evans Message-Id: <199509191035.UAA04813@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@gndrsh.aac.dev.com Subject: Re: Which SUP files are available and where ? Cc: current@freebsd.org, rkw@dataplex.net, wollman@lcs.mit.edu Sender: owner-current@freebsd.org Precedence: bulk >> I thought that the CPU ran out of power before the pipe was half full, >> even doing raw data movement for nfs. >I have done iozones over NFS on 100BaseTx networking and seen numbers >well in excess of 3MBytes/s reading (forget about writting, we all >know sync nfs is dog slow at that). 3MB/s is less than half full. >> For sup it will have to traverse >> file systems so it will be hard to get more than 1MB of throughput per >> file system. >File system bandwidth is not a problem. Again, I can produce iozone >results in excess of 6MB/sec quite easily on local fast disks. iozone is not representative of anything except huge sequential accesses to huge sequential files. On a disk that has an iozone speed of 4-5MB/s here, the throughput of `cvs -Q co bin' is 30K/sec (2562K, 85.05 real, 12.69 user, 20.96 sys) (the cvs repository is on a separate disk). The throughput of `cp -pR bin bin~' is 79K/sec (2562K, 33.41 real, 0.10 user, 3.04 sys). The throughput of `cp -pR bin separate_slower_disk/bin' is 56K (2562K, 46.50 real, 0.10 user, 3.50 sys). Abysmal results like this are typical for accessing small files. >> Is it as fast as cvs co ;-). >A _LOT_ faster when you are talking about the two running over local >ethernet. NFS gets in the way a bit. Sup is slow over long RTT links >due to the 2 RTT needed for many of the things it does, it is blazing >fast on local networks (and smokes on 100Mb/s networks :-)). Cancel the previous `;-)'. sup should be faster than cvs co but it can hardly be faster than cp -pR, and cp -pR is _slow_. Bruce From owner-freebsd-current Tue Sep 19 06:49:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA03197 for current-outgoing; Tue, 19 Sep 1995 06:49:49 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA03191 for ; Tue, 19 Sep 1995 06:49:46 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id OAA29596; Tue, 19 Sep 1995 14:40:50 +0100 From: Paul Richards Message-Id: <199509191340.OAA29596@server.netcraft.co.uk> Subject: Re: pci bus and current?? To: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 19 Sep 1995 14:40:48 +0100 (BST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199509182137.AA05605@Sysiphos> from "Stefan Esser" at Sep 18, 95 11:37:13 pm Reply-to: paul@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 479 Sender: owner-current@FreeBSD.ORG Precedence: bulk In reply to Stefan Esser who said > > On Sep 18, 21:37, J Wunsch wrote: > } Subject: Re: pci bus and current?? > > Sorry, my reply to Joerg was not meant to be sent to the list ... > > (I missed the fact, that his message had a "Return-To: current" > header line.) > I think this is a conspiracy to make me learn German :-) -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Tue Sep 19 12:23:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA25592 for current-outgoing; Tue, 19 Sep 1995 12:23:58 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA25586 for ; Tue, 19 Sep 1995 12:23:54 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA06086; Tue, 19 Sep 1995 12:23:13 -0700 From: "Rodney W. Grimes" Message-Id: <199509191923.MAA06086@GndRsh.aac.dev.com> Subject: Re: Which SUP files are available and where ? To: bde@zeta.org.au (Bruce Evans) Date: Tue, 19 Sep 1995 12:23:12 -0700 (PDT) Cc: bde@zeta.org.au, current@freebsd.org, rkw@dataplex.net, wollman@lcs.mit.edu In-Reply-To: <199509191035.UAA04813@godzilla.zeta.org.au> from "Bruce Evans" at Sep 19, 95 08:35:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2705 Sender: owner-current@freebsd.org Precedence: bulk > > >> I thought that the CPU ran out of power before the pipe was half full, > >> even doing raw data movement for nfs. > > >I have done iozones over NFS on 100BaseTx networking and seen numbers > >well in excess of 3MBytes/s reading (forget about writting, we all > >know sync nfs is dog slow at that). > > 3MB/s is less than half full. That was all the disk could do that I was using for the source :-(, the bottlneck was not the network, it was being 3/4 of the way out on a DSP3053L disk where the transfer rate of the disk is slighly over 3MB/s. > >> For sup it will have to traverse > >> file systems so it will be hard to get more than 1MB of throughput per > >> file system. > > >File system bandwidth is not a problem. Again, I can produce iozone > >results in excess of 6MB/sec quite easily on local fast disks. > > iozone is not representative of anything except huge sequential accesses > to huge sequential files. Which represents my install mode for cloning systems pretty well, cd /mnt; restore rf /SkyRsh/a/root.dmp;... and since that is a lot of what I do with my systems iozone is representative of what I do. > On a disk that has an iozone speed of 4-5MB/s > here, the throughput of `cvs -Q co bin' is 30K/sec (2562K, 85.05 real, > 12.69 user, 20.96 sys) (the cvs repository is on a separate disk). The > throughput of `cp -pR bin bin~' is 79K/sec (2562K, 33.41 real, 0.10 user, > 3.04 sys). The throughput of `cp -pR bin separate_slower_disk/bin' is > 56K (2562K, 46.50 real, 0.10 user, 3.50 sys). Abysmal results like this > are typical for accessing small files. Why is this? And what can be done to speed it up? Is this all Meta Data overhead? I think you are lossing on the write side here, not the read side. How fast does cp -pR go when the destination is a MFS? I don't use cp -pR, I use cpio -pdamu --block-size=16 and that cruzzes along pretty well, but I have never measured the speed, but I do know it is signifacantly faster than cp -pR. > > >> Is it as fast as cvs co ;-). > > >A _LOT_ faster when you are talking about the two running over local > >ethernet. NFS gets in the way a bit. Sup is slow over long RTT links > >due to the 2 RTT needed for many of the things it does, it is blazing > >fast on local networks (and smokes on 100Mb/s networks :-)). > > Cancel the previous `;-)'. sup should be faster than cvs co but it can > hardly be faster than cp -pR, and cp -pR is _slow_. Then some work should go into speeding cp -pR up, or atleast finding exactly what makes that so slow. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Sep 19 14:01:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA29323 for current-outgoing; Tue, 19 Sep 1995 14:01:16 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA29318 for ; Tue, 19 Sep 1995 14:01:12 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id RAA20670; for ; Tue, 19 Sep 1995 17:01:10 -0400 Date: Tue, 19 Sep 95 16:58:46 PDT From: "Ugen J.S.Antsilevich" Subject: Why FreeBSD could not be better then Linux..:) To: freebsd-current@FreeBSD.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk Hmm..now when i got your attention.. Well..FreeBSD *IS* my system of choice so subject is not really what i wanted to say. But sort of point is that -current is dead for more then two weeks and the main discussion between core team members on maling list is the ages-long and endless discusssion of should we or should we not use "goto's"... Guys, i am not the one to point you to what is black and what is white and which way to go , but... Just observation..No offence...:) --Ugen From owner-freebsd-current Tue Sep 19 14:48:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01635 for current-outgoing; Tue, 19 Sep 1995 14:48:18 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA01618 for ; Tue, 19 Sep 1995 14:48:08 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA10801; Tue, 19 Sep 1995 14:45:30 -0700 From: Terry Lambert Message-Id: <199509192145.OAA10801@phaeton.artisoft.com> Subject: Re: Why FreeBSD could not be better then Linux..:) To: ugen@latte.worldbank.org (Ugen J.S.Antsilevich) Date: Tue, 19 Sep 1995 14:45:29 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: from "Ugen J.S.Antsilevich" at Sep 19, 95 04:58:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1666 Sender: owner-current@FreeBSD.ORG Precedence: bulk > Well..FreeBSD *IS* my system of choice so subject is not > really what i wanted to say. But sort of point is that > -current is dead for more then two weeks and the main discussion > between core team members on maling list is the ages-long > and endless discusssion of should we or should we not use "goto's"... 1) I am not a core team member. I divorced myself when Novell bought USL. I was at the time a Novell employee and my continued participation at that time would have endangered the legal standing of the code. This is no longer the case (I no longer work for Novell), but I'm still not a core team member. 2) The problems are in the VM in the paging changes, and are being worked on by the people who handle that code. And it's not any of us discussing goto's on the hacker's list, unless maybe David is working on it too. 3) The discussing of "goto's" was an Ad Hominim attack on my coding style designed to distract from the main issue, which was support for kernel string process encoding of other than 8 bit strings. This has nothing whatsoever to do with helping or hindering the problems in the -current code. 4) The -current code is *permitted* to be unstable by it's very nature. This is generally not the case, but since it has been recently, it's probably time to remind people that -current is a CVS tree snapshot. Depending on what was going on when the snapshot was made, current is not even guaranteed to contain buildable code, let alone code that runs without errors. 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 Sep 20 05:15:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA00764 for current-outgoing; Wed, 20 Sep 1995 05:15:18 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA00759 for ; Wed, 20 Sep 1995 05:15:12 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA25816; Wed, 20 Sep 1995 22:09:54 +1000 Date: Wed, 20 Sep 1995 22:09:54 +1000 From: Bruce Evans Message-Id: <199509201209.WAA25816@godzilla.zeta.org.au> To: current@freebsd.org Subject: pathconf under nfsv3 Cc: dfr@render.com Sender: owner-current@freebsd.org Precedence: bulk How is pathconf() supposed to work under nfsv3? The server seems to support it, but the client just returns EINVAL without asking the server. Bruce From owner-freebsd-current Wed Sep 20 07:21:38 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA03829 for current-outgoing; Wed, 20 Sep 1995 07:21:38 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA03813 ; Wed, 20 Sep 1995 07:21:29 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id KAA15348; Wed, 20 Sep 1995 10:26:53 -0400 Date: Wed, 20 Sep 1995 10:26:53 -0400 (EDT) From: Nathan Stratton To: current@freebsd.org cc: questions@freebsd.org Subject: secondary ip address on interfaces In-Reply-To: <199509201209.WAA25816@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Hi, I am using a cisco 4000 as a router and I want to move to a FreeBSD box. (I tried Linux :-( no way, the routing is screwed) My problem is that I am working on renumbering my networks and need to for a short time (ok well 4 months or so) have both address working on the ethernets. On my cisco I can have a ip address 204.117.64.0 and a ip address secondary 205.215.8.0 and they will both route. Then I can slowly move my servers from one to the other address. Can this be done in FreeBSD? Can I configure a interface to have two addresses and have it route ip from one to the other? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Wed Sep 20 07:25:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA03947 for current-outgoing; Wed, 20 Sep 1995 07:25:49 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA03940 for ; Wed, 20 Sep 1995 07:25:10 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA31890; Thu, 21 Sep 1995 00:13:46 +1000 Date: Thu, 21 Sep 1995 00:13:46 +1000 From: Bruce Evans Message-Id: <199509201413.AAA31890@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@GndRsh.aac.dev.com Subject: Re: Which SUP files are available and where ? Cc: current@FreeBSD.ORG, rkw@dataplex.net, wollman@lcs.mit.edu Sender: owner-current@FreeBSD.ORG Precedence: bulk >> On a disk that has an iozone speed of 4-5MB/s >> here, the throughput of `cvs -Q co bin' is 30K/sec (2562K, 85.05 real, >> 12.69 user, 20.96 sys) (the cvs repository is on a separate disk). The >> throughput of `cp -pR bin bin~' is 79K/sec (2562K, 33.41 real, 0.10 user, >> 3.04 sys). The throughput of `cp -pR bin separate_slower_disk/bin' is >> 56K (2562K, 46.50 real, 0.10 user, 3.50 sys). Abysmal results like this >> are typical for accessing small files. >Why is this? And what can be done to speed it up? Is this all Meta >Data overhead? I think you are lossing on the write side here, not >the read side. How fast does cp -pR go when the destination is a MFS? I think it's mostly from synchronous writes, but there are apparently still performance bugs in the caches. Some other benchmarks on the same file system (all this is on a 16MB DX2/66 system): du -a bin | wc: 1.36 real 0.05 user 0.34 sys du -a bin | wc: 1.36 real 0.05 user 0.34 sys # (598 files) The drive LED is on for most of the time during the second test. This shows that the results of the first test are not being cached. I have run similar tests under Minix and Linux on the old Minix file system that show up to 20000 files being cached in only 1MB of buffer cache (the [iv]node cache gets wiped out but the buffer cache doesn't). The old Minix file system has only 48 bytes of metadata per file so 1MB can cache about 3 times as many files as for ufs. FreeBSD seems to be limited to caching the metadata for only about 326 files :-(. The cache performance bugs used to be that `numvnodes' was too small (it was 0x459 for the above test), and that only a limited number of vnodes can be kept in memory (because the blocks containing the vnodes aren't kept in memory), and that thrashing of the vnode cache thrashed the buffer cache (because buffers are attached to vnodes), and that only a limited number of directories can be kept in memory (because the buffers for the directories are attached to vnodes). Minix and Linux didn't have these problems because they cache blocks as blocks and don't attach them to vnodes. It may be that caching all the metadata found by an operation such as `du -a /' is a poor use of memory. However, with raw i/o speeds of 5MB/sec and metadata access speeds of perhaps 100K/sec as is typical for modern SCSI drive/controllers, the caching of metadata should have a much higher priority than caching of data. The correct balance between caching of metadata and using memory to run programs in is less clear. Now another benchmark: diff -r bin bin~: 21.10 real 0.84 user 1.98 sys diff -r bin bin~: 22.08 real 0.87 user 2.19 sys du -a bin | wc: 0.30 real 0.07 user 0.21 sys This shows that reading of scattered files is almost as slow as writing. The du time has now improved! Somehow the caches' effectiveness have been improved so that no i/o is done for the du. tar cf /dev/null bin: 5.73 real 0.17 user 1.03 sys tar cf /dev/null bin: 2.02 real 0.14 user 0.81 sys The time for the first tar probably represents the file system's speed when there is no data in the cache. It is only 447K/sec. The drive LED was on for part of the time for the second tar, so it's not clear what is being measured. The speed is now 1268K/sec, almost 25% of the raw disk speed. I think most of the data was in the cache but most of the metadata wasn't, so the speed is limited to that of du -a, so it is much too slow. >I don't use cp -pR, I use cpio -pdamu --block-size=16 and that cruzzes >along pretty well, but I have never measured the speed, but I do know >it is signifacantly faster than cp -pR. If it is faster, then cpio must be doing a better job of buffering than the file system. cp probably loses compared with a tar or cpio pipeline with a large block size by doing only one file at a time. However: find bin | time \ cpio -pdamu --block-size=16 bin~: 31.47 real 0.23 user 3.43 sys has much the same speed as cp -pR. Here are the above benchmarks packaged in a script: --- #!/bin/sh time cvs -Q co bin time cvs -Q co bin time cp -pR bin bin~ time cp -pR bin/* bin~ time du -a bin >/dev/null time du -a bin >/dev/null time diff -r bin bin~ time diff -r bin bin~ time du -a bin >/dev/null time du -a bin >/dev/null time tar cf /dev/null bin time tar cf /dev/null bin time rm -rf bin~ find bin | time cpio -pdamu --block-size=16 bin~ find bin | time cpio -pdamu --block-size=16 bin~ time rm -rf bin bin~ --- and the results of the script run in /tmp/bde on freefall: --- 77.31 real 6.33 user 14.95 sys 19.36 real 0.57 user 1.16 sys 46.90 real 0.06 user 2.03 sys 36.63 real 0.07 user 1.61 sys 3.25 real 0.04 user 0.17 sys 0.20 real 0.04 user 0.13 sys 9.18 real 0.28 user 1.11 sys 27.99 real 0.45 user 1.19 sys 1.17 real 0.04 user 0.14 sys 0.22 real 0.05 user 0.13 sys 3.85 real 0.09 user 0.58 sys 1.70 real 0.11 user 0.49 sys 20.08 real 0.02 user 0.55 sys 264 blocks 65.07 real 0.14 user 2.40 sys 264 blocks 86.87 real 0.17 user 2.70 sys 40.94 real 0.06 user 1.03 sys --- and the results on my system again: --- 84.35 real 12.61 user 20.56 sys 19.85 real 1.08 user 1.69 sys 34.23 real 0.17 user 3.02 sys 21.58 real 0.10 user 2.59 sys 1.64 real 0.13 user 0.22 sys 0.29 real 0.09 user 0.19 sys 14.09 real 0.95 user 1.65 sys 21.99 real 0.81 user 2.07 sys 1.45 real 0.07 user 0.26 sys 0.30 real 0.09 user 0.18 sys 8.62 real 0.13 user 0.98 sys 2.31 real 0.15 user 0.87 sys 14.69 real 0.06 user 0.69 sys 264 blocks 28.87 real 0.19 user 3.31 sys 264 blocks 37.45 real 0.26 user 4.02 sys 26.93 real 0.09 user 1.56 sys --- There are similar anamolies for the cp, diff and cpio pairs, and my system at least is otherwise unloaded so these must be due to caching strategies: 1) the second cp is significantly faster than the first. 2) the second diff is significantly slower than the first. 2) the second cpio is significantly slower than the first. 4) freefall seems to be relatively slower at cpio. Perhaps it was using the file system that /tmp is on for something else when it was doing the cpio. Bruce From owner-freebsd-current Wed Sep 20 07:27:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA03985 for current-outgoing; Wed, 20 Sep 1995 07:27:35 -0700 Received: from id.slip.bcm.tmc.edu (root@hou20.onramp.net [199.1.137.148]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA03980 for ; Wed, 20 Sep 1995 07:27:18 -0700 Received: (from rich@localhost) by id.slip.bcm.tmc.edu (8.6.12/8.6.9) id JAA08552; Wed, 20 Sep 1995 09:27:00 -0500 Date: Wed, 20 Sep 1995 09:27:00 -0500 From: Rich Murphey Message-Id: <199509201427.JAA08552@id.slip.bcm.tmc.edu> To: FreeBSD-current@freefall.FreeBSD.org Subject: linux compatibility man page Reply-to: rich@lamprey.utmb.edu Sender: owner-current@FreeBSD.org Precedence: bulk I took netbsd's man page for linux compatibility and added a brief installation guide. I've sent Jordan the nroff source for review. Any suggestions are welcome! Many thanks to Soren Schmidt for the emulator itself! Rich COMPAT LINUX(8) UNIX System Manager's Manual COMPAT LINUX(8) - - NAME COMPAT LINUX - setup procedure for running Linux binaries - INSTALL In order to run static and dynamicly linked Linux binaries, you need a kernel configured with options COMPAT LINUX. Include options SYSVSHM as - well if you plan to run the linux version of doom. cd /sys/i386/conf echo options '"COMPAT LINUX"' >> GENERIC - echo options SYSVSHM >> GENERIC config GENERIC cd /sys/compile/GENERIC make depend; make make install If you don't already have it, build the loadable kernel module /lkm/linux mod.o. - cd /usr/src/lkm/linux make all install clean Once you have both the kernel and lkm installed, invoke linux as root to load the emulator into the kernel. TESTING To test the emulator using the linux version of the game doom, first get the linux shared libraries. mkdir /compat/linux cd /compat/linux ncftp ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/linux-emu.tar.gz tar xzf linux-emu.tar.gz rm -rf usr lkm linux-emu.tar.gz The lkm and usr portion of this tar file are redundant since you already have the lkm and /usr/bin/linux. Next install doom itself. ncftp ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/linux-doom-1.8.tar.gz tar xzf linux-doom-1.8.tar.gz cd doom-1.8 xdoom DESCRIPTION Most Linux binaries should work, except programs that use Linux-specific features. These include the Linux /proc filesystem (which is different from the optional FreeBSD /proc filesystem), and i386-specific calls, such as enabling virtual 8086 mode. Many linux programs are dynamically linked. So you will also need the Linux shared libraries that the program depends on, and the runtime link- er. Also, you will need to create a "shadow root" directory for Linux binaries on your FreeBSD system. This directory is named /compat/linux. Any file operations done by Linux programs run under FreeBSD will look in this directory first. So, if a Linux program opens, for example, /etc/passwd, FreeBSD will first try to open /compat/linux/etc/passwd, and if that does not exist open the packages that include configuration files, etc under /compat/linux, to avoid naming conflicts with possible FreeBSD counterparts. Shared libraries should also be installed in the shadow tree. Generally, you will need to look for the shared libraries that Linux bi- naries depend on only the first few times that you install a Linux pro- gram on your FreeBSD system. After a while, you will have a sufficient set of Linux shared libraries on your system to be able to run newly im- ported Linux binaries without any extra work. Setting up shared libraries How to get to know which shared libraries Linux binaries need, and where to get them? Basically, there are 2 possibilities (when following these instructions: you will need to be root on your FreeBSD system to do the necessary installation steps). 1. If you have access to a Linux system, see what shared libraries it needs, and copy them to your FreeBSD system. Example: you have just ftp-ed the Linux binary of Doom. Put it on the Linux system you have access to, and check which shared libraries it needs by running `ldd linuxxdoom': (me@linux) ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 You would need go get all the files from the last column, and put them under /compat/linux, with the names in the first column as sym- bolic links pointing to them. This means you eventually have these files on your FreeBSD system: /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 (symbolic link to the above) /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 (symbolic link to the above) /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 (symbolic link to the above) Note that if you already have a Linux shared library with a matching major revision number to the first column of the 'ldd' output, you won't need to copy the file named in the last column to your system, the one you already have should work. It is advisable to copy the shared library anyway if it is a newer version, though. You can re- move the old one, as long as you make the symbolic link point to the new one. So, if you have these libraries on your system: /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> /compat/linux/lib/libc.so.4.6.27 and you find that the ldd output for a new binary you want to in- stall is: libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 you won't need to worry about copying /lib/libc.so.4.6.29 too, be- cause the program should work fine with the slightly older version. You can decide to replace the libc.so anyway, and that should leave you with: /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> /compat/linux/lib/libc.so.4.6.29 Please note that the symbolic link mechanism is only needed for Lin- ux binaries, the FreeBSD runtime linker takes care of looking for matching major revision numbers itself, you don't need to worry about that. Finally, you must make sure that you have the Linux runtime linker and its config files on your system. You should copy these files from the Linux system to their appropriate place on your FreeBSD system (to the /compat/linux tree): /lib/ld.so /etc/ld.so.cache /etc/ld.so.config 2. You don't have access to a Linux system. In that case, you should get the extra files you need from various ftp sites. Information on where to look for the various files is appended below. For now, let's assume you know where to get the files. Retrieve the following files (all from the same ftp site to avoid any version mismatches), and install them under /compat/linux (i.e. /foo/bar is installed as /compat/linux/foo/bar): /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so ldconfig and ldd don't necessarily need to be under /compat/linux, you can install them elsewhere in the system too. Just make sure they don't conflict with their FreeBSD counterparts. A good idea would be to install them in /usr/local/bin as ldconfig-linux and ldd-linux. Create the file /compat/linux/etc/ld.so.conf, containing the direc- tories in which the Linux runtime linker should look for shared libs. It is a plain text file, containing a directory name on each line. /lib and /usr/lib are standard, you could add the following: /usr/X11/lib /usr/local/lib Note that these are mapped to /compat/linux/XXXX by FreeBSD's compat code, and should exist as such on your system. Run the Linux ldconfig program. It should be statically linked, so it doesn't need any shared libraries by itself. It will create the file /compat/linux/etc/ld.so.cache You should rerun the Linux ver- sion of the ldconfig program each time you add a new shared library. You should now be set up for Linux binaries which only need a shared libc. You can test this by running the Linux ldd on itself. Suppose that you have it installed as ldd-linux, it should produce something like: (me@FreeBSD) ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 This being done, you are ready to install new Linux binaries. When- ever you install a new Linux program, you should check if it needs shared libraries, and if so, whether you have them installed in the /compat/linux tree. To do this, you run the Linux version ldd on the new program, and watch its output. ldd (see also the manual page for ldd(1)) will print a list of shared libraries that the program depends on, in the form () => . If it prints "not found" in stead of it means that you need an extra library. Which library this is, is shown in , which will be of the form libXXXX.so. You will need to find a libXXXX.so.. on a Linux ftp site, and install it on your system. The XXXX (name) and (major revision number) should match; the minor number(s) are less important, though it is ad- vised to take the most recent version. Finding the necessary files. Note: the information below is valid as of the ime this document was written (March, 1995), but certain details such as names of ftp sites, directories and distribution names may have changed by the time you read this. Linux is distributed by several groups that make their own set of bina- ries that they distribute. Each distribution has its own name, like "Slackware" or "Yggdrasil". The distributions are available on a lot of ftp sites. Sometimes the files are unpacked, and you can get the individ- ual files you need, but mostly they are stored in distribution sets, usu- ally consisting of subdirectories with gzipped tar files in them. The primary ftp sites for the distributions are: sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions Some European mirrors: ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/linux/distributions src.doc.ic.ac.uk:/packages/linux/distributions For simplicity, let's concentrate on Slackware here. This distribution consists of a number of subdirectories, containing separate packages. Normally, they're controlled by an install program, but you can retrieve files "by hand" too. First of all, you will need to look in the "con- tents" subdir of the distribution. You will find a lot of small textfiles here describing the contents of the seperate packages. The fastest way to look something up is to retrieve all the files in the contents subdirec- tory, and grep through them for the file you need. Here is an example of a list of files that you might need, and in which contents-file you will find it by grepping through them: Needed Package ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf lib - libXt.so.6.0 xf lib - libX11.so.3 oldlibs libXt.so.3 oldlibs So, in this case, you will need the packages ldso, shlibs, xf lib and - oldlibs. In each of the contents-files for these packages, look for a line saying "PACKAGE LOCATION", it will tell you on which 'disk' the package is, in our case it will tell us in which subdirectory we need to look. For our example, we would find the following locations: Package Location ldso diska2 shlibs diska2 oldlibs diskx6 xf lib diskx9 - The locations called "diskXX" refer to the "slakware/XX" subdirectories of the distribution, others may be found in the "contrib" subdirectory. In this case, we could now retrieve the packages we need by retrieving the following files (relative to the root of the Slackware distribution tree): slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs/tgz slakware/x9/xf lib.tgz - Extract the files from these gzipped tarfiles in your /compat/linux di- rectory (possibly omitting or afterwards removing files you don't need), and you are done. BUGS The information about Linux distributions may become outdated. SEE ALSO ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README /usr/src/sys/i386/ibcs2/README.iBCS2 4th Berkeley Distribution March 2, 1995 5 From owner-freebsd-current Wed Sep 20 10:54:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA21823 for current-outgoing; Wed, 20 Sep 1995 10:54:46 -0700 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA21812 for ; Wed, 20 Sep 1995 10:54:25 -0700 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.144.4]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id TAA24448 for ; Wed, 20 Sep 1995 19:37:14 +0200 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id TAA03936; Wed, 20 Sep 1995 19:37:08 +0200 Date: Wed, 20 Sep 1995 19:37:08 +0200 Message-Id: <199509201737.TAA03936@caramba.cs.tu-berlin.de> To: current@freebsd.org Subject: from(1) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org Precedence: bulk Changes: - add missing includes files - minimal support for content-length - allow reading input from stdin (-f -) - Option '-c' print a count of matching lines - Option '-F' use 'From:' instead 'From' line - Option '-t' don't change access time - Option '-v' Invert the sense of matching, to select nonmatching lines. Examples: count mails in archive: $ zcat hack.gz | from -c -f - 47 count non-freebsd mails in your mailbox: $ from -cvs freebsd.org 3 mails from Berlin: $ from -F -s berlin -f mbox From: Thomas Graichen From: Thomas Graichen From: Wolfram Schneider From: Wolfram Schneider From: Wolfram Schneider From: Wolfram Schneider --- /usr/src/usr.bin/from/from.c Fri May 27 14:31:22 1994 +++ from.c Wed Sep 20 17:03:44 1995 @@ -42,41 +42,90 @@ #endif /* not lint */ #include +#include +#include #include #include #include #include +#include +#include -main(argc, argv) +#define CLEN "content-length:" +#define FROM "From:" + +int f_from = 0; /* use `From:' field instead 'From' */ +int f_count = 0; /* don't print from lines, print count only */ +int f_invert = 0; /* invert searching */ +int f_atime = 0; /* modify access time */ +int counter = 0; + +int match __P((char *line, char *sender)); +int match2 __P((char *line, char *sender)); +void print_from __P((char *buf)); + + +void main(argc, argv) int argc; char **argv; { extern char *optarg; extern int optind; + struct passwd *pwd; - int ch, newline; + struct stat sb; + struct timeval tv[2]; + + int ch, newline, header, body; char *file, *sender, *p; #if MAXPATHLEN > BUFSIZ char buf[MAXPATHLEN]; + char buf2[MAXPATHLEN]; #else char buf[BUFSIZ]; + char buf2[BUFSIZ]; #endif file = sender = NULL; - while ((ch = getopt(argc, argv, "f:s:")) != EOF) + + while ((ch = getopt(argc, argv, "?Fcf:s:tv")) != EOF) switch((char)ch) { + + /* use `From:' field instead 'From' */ + case 'F': + f_from = 1; + break; + + /* don't print from lines, print count only */ + case 'c': + f_count = 1; + break; + + /* use file as mailbox */ case 'f': file = optarg; break; + + /* use only mails from sender */ case 's': sender = optarg; for (p = sender; *p; ++p) if (isupper(*p)) *p = tolower(*p); break; + + /* don't modify access time */ + case 't': + f_atime = 1; + break; + + case 'v': + f_invert = 1; + break; + case '?': default: - fprintf(stderr, "usage: from [-f file] [-s sender] [user]\n"); + fprintf(stderr, "usage: from [-Fctv] [-f file] [-s sender] [user]\n"); exit(1); } argv += optind; @@ -90,34 +139,104 @@ } file = pwd->pw_name; } - (void)sprintf(buf, "%s/%s", _PATH_MAILDIR, file); - file = buf; + (void)sprintf(buf2, "%s/%s", _PATH_MAILDIR, file); + file = buf2; } - if (!freopen(file, "r", stdin)) { + + /* stdin */ + if (!strcmp(file, "-")) { + f_atime = 0; /* don't stat stdin */ + } + + /* redirect file to stdin */ + else if (!freopen(file, "r", stdin)) { fprintf(stderr, "from: can't read %s.\n", file); exit(1); + } + + /* save atime */ + else if (f_atime) { + if (stat(file, &sb) < 0) { + perror("stat"); + exit(1); + } + tv[0].tv_sec = sb.st_atime; + tv[0].tv_usec = sb.st_atime * 1000; + tv[1].tv_sec = sb.st_mtime; + tv[1].tv_usec = sb.st_mtime * 1000; } + + header = body = 0; for (newline = 1; fgets(buf, sizeof(buf), stdin);) { + + /* + * newline + * begin (next line) or end of header + */ if (*buf == '\n') { newline = 1; - continue; + + /* skip bytes in body (content-length) */ + if (header && body > 0) { + while(body--) + getc(stdin); + } + header = 0; + body = 0; + } + + /* begin of header */ + else if (newline && !strncmp(buf, "From ", 5)) { + if (!f_from) + if (!sender || match(buf + 5, sender)) + print_from(buf); + + header = 1; + newline = 0; + } + + /* found "^content-length: " in header */ + else if (header && + !strncasecmp(buf, CLEN, sizeof(CLEN) - 1) && + isblank(*(buf + sizeof(CLEN) - 1))) { + + body = atoi(buf + sizeof(CLEN)); + } + + /* From: */ + else if (header && f_from && + !strncasecmp(buf, FROM, sizeof(FROM) - 1) && + isblank(*(buf + sizeof(FROM) - 1))) { + + if (!sender || match2(buf + sizeof(FROM), sender)) + print_from(buf); + } + + + } + + /* print number (of matching or non-matching) mails */ + if (f_count) + fprintf(stdout, "%d\n", counter); + + /* reset access time */ + if (f_atime) { + if (utimes(file, tv) < 0) { + perror("utimes"); + exit(1); } - if (newline && !strncmp(buf, "From ", 5) && - (!sender || match(buf + 5, sender))) - printf("%s", buf); - newline = 0; } exit(0); } -match(line, sender) +int match(line, sender) register char *line, *sender; { register char ch, pch, first, *p, *t; for (first = *sender++;;) { if (isspace(ch = *line)) - return(0); + return(f_invert); ++line; if (isupper(ch)) ch = tolower(ch); @@ -125,7 +244,7 @@ continue; for (p = sender, t = line;;) { if (!(pch = *p++)) - return(1); + return(!f_invert); if (isupper(ch = *t++)) ch = tolower(ch); if (ch != pch) @@ -133,4 +252,27 @@ } } /* NOTREACHED */ +} + +int match2(line, sender) + register char *line, *sender; +{ + register char *p, *s; + + for (; *line; line++) { + for (p = line, s = sender; tolower(*p) == *s; p++, s++); + + if (*s == NULL) + return(!f_invert); + } + return(f_invert); +} + +void print_from(buf) + char *buf; +{ + if (f_count) + counter++; + else + printf("%s", buf); } --- /usr/src/usr.bin/from/from.1 Fri May 27 14:31:22 1994 +++ from.1 Wed Sep 20 16:52:01 1995 @@ -39,6 +39,7 @@ .Nd print names of those who have sent mail .Sh SYNOPSIS .Nm from +.Op Fl Fctv .Op Fl s Ar sender .Op Fl f Ar file .Op Ar user @@ -49,6 +50,14 @@ .Pp Options: .Bl -tag -width Fl + +.It Fl F +Use 'From:' field instead 'From'. + +.It Fl c +Suppress normal output; instead print a count of +matching lines. + .It Fl f Ar file The supplied file is examined instead of the invoker's mailbox. @@ -61,6 +70,13 @@ Only mail from addresses containing the supplied string are printed. + +.It Fl t +Don't change access time of mailbox. + +.It Fl v +Invert the sense of matching, to select nonmatching lines. + .El .Pp If From owner-freebsd-current Wed Sep 20 10:58:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA21951 for current-outgoing; Wed, 20 Sep 1995 10:58:24 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA21946 for ; Wed, 20 Sep 1995 10:58:22 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.11/8.6.9) id OAA11033 for current@freebsd.org; Wed, 20 Sep 1995 14:02:18 -0400 From: Mark Hittinger Message-Id: <199509201802.OAA11033@ns1.win.net> Subject: 2.2 looking up To: current@freebsd.org Date: Wed, 20 Sep 1995 14:02:18 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 447 Sender: owner-current@freebsd.org Precedence: bulk What a breath of fresh air. Today's sup and rebuild went fine. Last week there were three problems that I was fooling with that I can't seem to make happen anymore: 1. Sig 11 gone? 2. PCI bus probe hang gone? 3. I/O system lockup with disk light on full time gone? This is just an FYI report from the field. Its a nice warm day on -current street. Regards, Mark Hittinger Internet Manager WinNET Communications, Inc. bugs@win.net From owner-freebsd-current Wed Sep 20 11:15:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA22299 for current-outgoing; Wed, 20 Sep 1995 11:15:33 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA22294 for ; Wed, 20 Sep 1995 11:15:30 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA04895; Wed, 20 Sep 1995 14:14:13 -0400 Date: Wed, 20 Sep 1995 14:14:13 -0400 From: "Garrett A. Wollman" Message-Id: <9509201814.AA04895@halloran-eldar.lcs.mit.edu> To: Wolfram Schneider Cc: current@freebsd.org Subject: from(1) In-Reply-To: <199509201737.TAA03936@caramba.cs.tu-berlin.de> References: <199509201737.TAA03936@caramba.cs.tu-berlin.de> Sender: owner-current@freebsd.org Precedence: bulk < said: > - Option '-c' print a count of matching lines Use wc(1). > - Option '-t' don't change access time Or, alternatively: - Option '-t' change modification time > count mails in archive: > $ zcat hack.gz | from -c -f - > 47 $ zcat hack.gz | from -f - | wc -l 47 Or, for that matter: $ zcat hack.gz | egrep '^From ' | wc -l And `Content-Length' is a really idiotic AT&T-ism designed by people who didn't understand mail; I would not bloat our programs by attempting to support it. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Sep 20 11:30:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA22649 for current-outgoing; Wed, 20 Sep 1995 11:30:53 -0700 Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA22644 for ; Wed, 20 Sep 1995 11:30:50 -0700 Received: by haven.uniserve.com id <30747>; Wed, 20 Sep 1995 11:32:35 +0100 Date: Wed, 20 Sep 1995 11:32:35 -0700 (PDT) From: Tom Samplonius To: "Garrett A. Wollman" cc: Wolfram Schneider , current@freebsd.org Subject: Re: from(1) In-Reply-To: <9509201814.AA04895@halloran-eldar.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Wed, 20 Sep 1995, Garrett A. Wollman wrote: > And `Content-Length' is a really idiotic AT&T-ism designed by people > who didn't understand mail; I would not bloat our programs by > attempting to support it. "Content-Length" is the best way we have for efficiently parsing e-mail boxes into individual messages. Tom From owner-freebsd-current Wed Sep 20 11:31:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA22698 for current-outgoing; Wed, 20 Sep 1995 11:31:13 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA22693 for ; Wed, 20 Sep 1995 11:31:11 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id OAA23044; for ; Wed, 20 Sep 1995 14:31:09 -0400 Date: Wed, 20 Sep 95 14:31:37 PDT From: "Ugen J.S.Antsilevich" Subject: RE: 2.2 looking up To: current@FreeBSD.org, Mark Hittinger X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk > >What a breath of fresh air. Today's sup and rebuild went fine. Last week >there were three problems that I was fooling with that I can't seem to >make happen anymore: > >1. Sig 11 gone? WAW..i am going to SUP and try today... --Ugen From owner-freebsd-current Wed Sep 20 12:05:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA23651 for current-outgoing; Wed, 20 Sep 1995 12:05:07 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA23646 for ; Wed, 20 Sep 1995 12:05:04 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.11/8.6.9) id PAA27804 for current@freebsd.org; Wed, 20 Sep 1995 15:08:55 -0400 From: Mark Hittinger Message-Id: <199509201908.PAA27804@ns1.win.net> Subject: re: 2.2 lookup up....uh... To: current@freebsd.org Date: Wed, 20 Sep 1995 15:08:54 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 327 Sender: owner-current@freebsd.org Precedence: bulk > > 1. Sig 11 gone? > Hmmm well not gone entirely. Spoke too soon. I noticed that the named-xfer was bombing with sig11. A couple of other TCP/IP programs like rlogin are bombing too. Will do more double checks. Sed is working ok. :-) Regards, Mark Hittinger Internet Manager WinNET Communications, Inc. bugs@win.net From owner-freebsd-current Wed Sep 20 14:44:47 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA29841 for current-outgoing; Wed, 20 Sep 1995 14:44:47 -0700 Received: from ns.dknet.dk (root@ns.dknet.dk [193.88.44.42]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA29817 for ; Wed, 20 Sep 1995 14:44:29 -0700 Received: from pingnet by ns.dknet.dk with UUCP id AA25196 (5.65c8/IDA-1.4.4j for current@FreeBSD.org); Wed, 20 Sep 1995 23:39:39 +0200 Received: from kyklopen by ic1.ic.dk with UUCP id AA05812 (5.65c8/IDA-1.4.4j); Wed, 20 Sep 1995 23:20:51 +0200 Received: (from staff@localhost) by kyklopen (8.6.12/8.6.12) id XAA02560; Wed, 20 Sep 1995 23:18:20 GMT Date: Wed, 20 Sep 1995 23:18:14 +0000 (GMT) From: Thomas Sparrevohn To: "Ugen J.S.Antsilevich" Cc: current@FreeBSD.org, Mark Hittinger Subject: RE: 2.2 looking up In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Charset: ASCII X-Char-Esc: 29 Sender: owner-current@FreeBSD.org Precedence: bulk On Wed, 20 Sep 1995, Ugen J.S.Antsilevich wrote: > > > > >What a breath of fresh air. Today's sup and rebuild went fine. Last week > >there were three problems that I was fooling with that I can't seem to > >make happen anymore: > > > >1. Sig 11 gone? > WAW..i am going to SUP and try today... > --Ugen > No. It is even worse than before. After a while the entire system begins to core dump. None of the staticly linked files seems to generate sig 11. -- Thomas From owner-freebsd-current Wed Sep 20 15:02:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01756 for current-outgoing; Wed, 20 Sep 1995 15:02:30 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01744 ; Wed, 20 Sep 1995 15:02:26 -0700 Date: Wed, 20 Sep 1995 15:02:26 -0700 From: John Dyson Message-Id: <199509202202.PAA01744@freefall.freebsd.org> To: staff@kyklopen.ping.dk, ugen@latte.worldbank.org Subject: RE: 2.2 looking up Cc: bugs@ns1.win.net, current@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk The Sig-11 problem is NOT fixed, and we are *slowly* making progress. New tidbits are being learned every day. Note that even Sep 1 has problems (and the VM "enhancements" went in on Sep 3 and after.) I am spending over 30-40 Hrs/week on this problem alone. DG or I will *proudly* announce the fix/fixes as they appear. Note also that I might send out some prospective fixes as time goes on. This is a really tough one. John dyson@freebsd.org From owner-freebsd-current Wed Sep 20 15:05:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA02054 for current-outgoing; Wed, 20 Sep 1995 15:05:32 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA02041 for ; Wed, 20 Sep 1995 15:05:22 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id SAA21834; for ; Wed, 20 Sep 1995 18:05:13 -0400 Date: Wed, 20 Sep 95 18:04:14 PDT From: "Ugen J.S.Antsilevich" Subject: RE: 2.2 looking up To: Thomas Sparrevohn Cc: current@FreeBSD.org, Mark Hittinger X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk >No. It is even worse than before. After a while the entire system >begins to core dump. None of the staticly linked files seems to >generate sig 11. I noticed that myself... Guys, seems to me that kernel is not the reason for the sig-11. It's out there in libc in some commonly used function. Somebody probably screwed something basic like strcmp. I'll try to build libc with debug and go through it but if someone can do it faster - try. --Ugen From owner-freebsd-current Wed Sep 20 15:21:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03269 for current-outgoing; Wed, 20 Sep 1995 15:21:46 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA03251 for ; Wed, 20 Sep 1995 15:21:41 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id AAA07676 for ; Thu, 21 Sep 1995 00:20:57 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id AAA10792 for freebsd-current@FreeBSD.ORG; Thu, 21 Sep 1995 00:20:56 +0200 Received: (from roberto@localhost) by keltia.Freenix.FR (8.7/keltia-uucp-2.5.1) id AAA22072 for freebsd-current@FreeBSD.ORG; Thu, 21 Sep 1995 00:20:39 +0200 (MET DST) From: Ollivier Robert Message-Id: <199509202220.AAA22072@keltia.Freenix.FR> Subject: XFree86 and the new malloc To: freebsd-current@FreeBSD.ORG (FreeBSD Current Users' list) Date: Thu, 21 Sep 1995 00:20:39 +0200 (MET DST) X-Operating-System: FreeBSD 2.2-CURRENT ctm#1085 X-Mailer: ELM [version 2.4 PL24 ME7a+] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk Has anyone tried to link the X server with the new libc's malloc from Poul-Henning ? -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.Freenix.FR 2.2-CURRENT #1: Sun Sep 10 18:50:19 MET DST 1995 From owner-freebsd-current Wed Sep 20 15:26:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03746 for current-outgoing; Wed, 20 Sep 1995 15:26:24 -0700 Received: (from dima@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03738 ; Wed, 20 Sep 1995 15:26:21 -0700 Message-Id: <199509202226.PAA03738@freefall.freebsd.org> Subject: Re: IDE CDROM.. To: ugen@latte.worldbank.org (Ugen J.S.Antsilevich) Date: Wed, 20 Sep 1995 15:26:21 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Ugen J.S.Antsilevich" at Sep 18, 95 09:26:43 am From: dima@FreeBSD.org (Dima Ruban) X-Class: Fast Organization: HackerDome X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 135 Sender: owner-current@FreeBSD.org Precedence: bulk Ugen J.S.Antsilevich writes: > > Hi..anyboud out there has IDE CDROM working? Yes, I have Mitsumi IDE CDROM > --Ugen > > -- dima From owner-freebsd-current Wed Sep 20 16:43:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13999 for current-outgoing; Wed, 20 Sep 1995 16:43:00 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA13969 ; Wed, 20 Sep 1995 16:42:54 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id TAA32590; Wed, 20 Sep 1995 19:48:32 -0400 Date: Wed, 20 Sep 1995 19:48:28 -0400 (EDT) From: Nathan Stratton To: freebsd-current@FreeBSD.org cc: freebsd-questions@FreeBSD.org Subject: network setup In-Reply-To: <199509202226.PAA03738@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk In netstart it says "Set up all the network interfaces, calling startup scripts if needed" Well I do need start info that will not go in sysconfig. How do I format the script what do I call the script? This is what I need to do to get the network to run. /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/hdlc0.cfg /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/hdlc1.cfg ifconfig ed0 205.215.0.1 netmask 255.255.255.0 ifconfig ed1 205.215.6.1 netmask 255.255.255.0 ifconfig ed1 alias 204.117.64.1 netmask 255.255.255.0 ifconfig eth0 144.228.27.38 144.228.27.37 netmask 255.255.255.252 ifconfig eth1 204.183.22.13 204.183.22.14 netmask 255.255.255.252 /usr/hdlc/utils/ifhdlc And then everything works, I know how to make it work if I type all that in by hand, but I need it in the script but don't know where to put it. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Wed Sep 20 17:00:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA16545 for current-outgoing; Wed, 20 Sep 1995 17:00:51 -0700 Received: from everest (dtr.rain.com [204.119.8.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA16517 ; Wed, 20 Sep 1995 17:00:43 -0700 From: bmk@dtr.com Received: (from bmk@localhost) by everest (8.6.11/8.6.9) id QAA00400; Wed, 20 Sep 1995 16:49:49 -0700 Message-Id: <199509202349.QAA00400@everest> Subject: Re: network setup To: nathan@netrail.net (Nathan Stratton) Date: Wed, 20 Sep 1995 16:49:49 -0700 (PDT) Cc: freebsd-current@FreeBSD.org, freebsd-questions@FreeBSD.org In-Reply-To: from "Nathan Stratton" at Sep 20, 95 07:48:28 pm Reply-To: bmk@dtr.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1041 Sender: owner-current@FreeBSD.org Precedence: bulk > In netstart it says "Set up all the network interfaces, calling startup > scripts if needed" Well I do need start info that will not go in > sysconfig. How do I format the script what do I call the script? > This is what I need to do to get the network to run. > /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/hdlc0.cfg > /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/hdlc1.cfg > ifconfig ed0 205.215.0.1 netmask 255.255.255.0 > ifconfig ed1 205.215.6.1 netmask 255.255.255.0 > ifconfig ed1 alias 204.117.64.1 netmask 255.255.255.0 > ifconfig eth0 144.228.27.38 144.228.27.37 netmask 255.255.255.252 > ifconfig eth1 204.183.22.13 204.183.22.14 netmask 255.255.255.252 > /usr/hdlc/utils/ifhdlc > And then everything works, I know how to make it work if I type all that > in by hand, but I need it in the script but don't know where to put it. Create a script named /etc/netstart.{interface_name} - I'd guess that you'd use /etc/netstart.hdlc?. You might have to hardcode it into netstart since you don't appear to be using ifconfig on hdlc?. From owner-freebsd-current Wed Sep 20 17:02:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA16762 for current-outgoing; Wed, 20 Sep 1995 17:02:04 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA16749 for ; Wed, 20 Sep 1995 17:02:01 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA01884; Wed, 20 Sep 1995 17:00:41 -0700 From: Terry Lambert Message-Id: <199509210000.RAA01884@phaeton.artisoft.com> Subject: Re: 2.2 looking up To: staff@kyklopen.ping.dk (Thomas Sparrevohn) Date: Wed, 20 Sep 1995 17:00:40 -0700 (MST) Cc: ugen@latte.worldbank.org, current@FreeBSD.org, bugs@ns1.win.net In-Reply-To: from "Thomas Sparrevohn" at Sep 20, 95 11:18:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 335 Sender: owner-current@FreeBSD.org Precedence: bulk > No. It is even worse than before. After a while the entire system > begins to core dump. None of the staticly linked files seems to > generate sig 11. Copy on write on mmap()'ed files broken? 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 Sep 20 18:36:19 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA29693 for current-outgoing; Wed, 20 Sep 1995 18:36:19 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA29682 for ; Wed, 20 Sep 1995 18:36:15 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id SAA17073; Wed, 20 Sep 1995 18:34:45 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id SAA04874; Wed, 20 Sep 1995 18:37:05 -0700 Message-Id: <199509210137.SAA04874@corbin.Root.COM> To: Terry Lambert cc: staff@kyklopen.ping.dk (Thomas Sparrevohn), ugen@latte.worldbank.org, current@freebsd.org, bugs@ns1.win.net Subject: Re: 2.2 looking up In-reply-to: Your message of "Wed, 20 Sep 95 17:00:40 PDT." <199509210000.RAA01884@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 20 Sep 1995 18:37:04 -0700 Sender: owner-current@freebsd.org Precedence: bulk >> No. It is even worse than before. After a while the entire system >> begins to core dump. None of the staticly linked files seems to >> generate sig 11. > >Copy on write on mmap()'ed files broken? No, it has nothing to do with that. There isn't any difference between shared (dynamic) programs and non-shared (static) programs in terms of how they are mapped or how copy-on-write works. The problem is that something is wrong with paging - wrong pages are ending up in the VM object. Please try to be patient; the problem will be fixed shortly. -DG From owner-freebsd-current Wed Sep 20 19:30:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA06708 for current-outgoing; Wed, 20 Sep 1995 19:30:53 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA06675 for ; Wed, 20 Sep 1995 19:30:44 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA07859; Wed, 20 Sep 1995 19:28:07 -0700 From: Terry Lambert Message-Id: <199509210228.TAA07859@phaeton.artisoft.com> Subject: Re: 2.2 looking up To: davidg@root.com Date: Wed, 20 Sep 1995 19:28:07 -0700 (MST) Cc: terry@lambert.org, staff@kyklopen.ping.dk, ugen@latte.worldbank.org, current@FreeBSD.org, bugs@ns1.win.net In-Reply-To: <199509210137.SAA04874@corbin.Root.COM> from "David Greenman" at Sep 20, 95 06:37:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1242 Sender: owner-current@FreeBSD.org Precedence: bulk > >> No. It is even worse than before. After a while the entire system > >> begins to core dump. None of the staticly linked files seems to > >> generate sig 11. > > > >Copy on write on mmap()'ed files broken? > > No, it has nothing to do with that. There isn't any difference between > shared (dynamic) programs and non-shared (static) programs in terms of how > they are mapped or how copy-on-write works. crt0.o on my box mmap's the shared libraries into the program address space as the first operation, whereas the unshared crt0.o doesn't have that or the extra code for implementing dlopen(). Definite difference between shared and unshared programs. Perhaps ctr0.o has changed for apps linked shared? Or perhaps it hasn't? > The problem is that something is wrong with paging - wrong pages are ending > up in the VM object. > Please try to be patient; the problem will be fixed shortly. No problem for me, anyway. Just airing a theory. It still sounds like a change in mmap() behaviour. Perhaps auto-placement of the region has failed, or some similar problem is showing up. 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 Sep 20 21:05:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA18227 for current-outgoing; Wed, 20 Sep 1995 21:05:13 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA18219 for ; Wed, 20 Sep 1995 21:05:10 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id VAA22376; Wed, 20 Sep 1995 21:03:50 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id VAA00133; Wed, 20 Sep 1995 21:06:14 -0700 Message-Id: <199509210406.VAA00133@corbin.Root.COM> To: Terry Lambert cc: staff@kyklopen.ping.dk, ugen@latte.worldbank.org, current@freebsd.org, bugs@ns1.win.net Subject: Re: 2.2 looking up In-reply-to: Your message of "Wed, 20 Sep 95 19:28:07 PDT." <199509210228.TAA07859@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 20 Sep 1995 21:06:13 -0700 Sender: owner-current@freebsd.org Precedence: bulk >> >> No. It is even worse than before. After a while the entire system >> >> begins to core dump. None of the staticly linked files seems to >> >> generate sig 11. >> > >> >Copy on write on mmap()'ed files broken? >> >> No, it has nothing to do with that. There isn't any difference between >> shared (dynamic) programs and non-shared (static) programs in terms of how >> they are mapped or how copy-on-write works. > >crt0.o on my box mmap's the shared libraries into the program address >space as the first operation, whereas the unshared crt0.o doesn't have >that or the extra code for implementing dlopen(). > >Definite difference between shared and unshared programs. Not really. The kernel does an identical mmap for the program binary itself. -DG From owner-freebsd-current Wed Sep 20 22:00:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA22859 for current-outgoing; Wed, 20 Sep 1995 22:00:28 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA22657 ; Wed, 20 Sep 1995 21:58:58 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id VAA01036; Wed, 20 Sep 1995 21:19:07 -0700 From: "Rodney W. Grimes" Message-Id: <199509210419.VAA01036@GndRsh.aac.dev.com> Subject: Re: network setup To: bmk@dtr.com Date: Wed, 20 Sep 1995 21:19:07 -0700 (PDT) Cc: nathan@netrail.net, freebsd-current@FreeBSD.org, freebsd-questions@FreeBSD.org In-Reply-To: <199509202349.QAA00400@everest> from "bmk@dtr.com" at Sep 20, 95 04:49:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2042 Sender: owner-current@FreeBSD.org Precedence: bulk > > > > In netstart it says "Set up all the network interfaces, calling startup > > scripts if needed" Well I do need start info that will not go in > > sysconfig. How do I format the script what do I call the script? > > > This is what I need to do to get the network to run. > > > /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/hdlc0.cfg > > /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/hdlc1.cfg > > ifconfig ed0 205.215.0.1 netmask 255.255.255.0 > > ifconfig ed1 205.215.6.1 netmask 255.255.255.0 > > ifconfig ed1 alias 204.117.64.1 netmask 255.255.255.0 > > ifconfig eth0 144.228.27.38 144.228.27.37 netmask 255.255.255.252 > > ifconfig eth1 204.183.22.13 204.183.22.14 netmask 255.255.255.252 > > /usr/hdlc/utils/ifhdlc > > > And then everything works, I know how to make it work if I type all that > > in by hand, but I need it in the script but don't know where to put it. > > Create a script named /etc/netstart.{interface_name} - I'd guess that > you'd use /etc/netstart.hdlc?. > > You might have to hardcode it into netstart since you don't appear to be > using ifconfig on hdlc?. cat >/etc/start_if.eth0 #!/bin/sh /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/hdlc0.cfg ^D cat >/etc/start_if.eth1 #!/bin/sh /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/hdlc1.cfg In /etc/sysconfig change: network_interfaces="lo0" to: network_interfaces="ed0 ed1 eth0 eth1 lo0" and add: ifconfig_ed0="inet 205.215.0.1 netmask 255.255.255.0" ifconfig_ed1="inet 205.215.6.1 netmask 255.255.255.0" ifconfig_eth0="inet 144.228.27.38 144.228.27.37 netmask 255.255.255.252" ifconfig_eth1="inet 204.183.22.13 204.183.22.14 netmask 255.255.255.252" This still leaves the ed1 alias unhandled and the ifhdlc command not done. I don't recognize the hdlc stuff so I am not sure where that should really go, but this is the proper way to do most of what you want without modifying anything but /etc/sysconfig. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Sep 20 22:23:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA24416 for current-outgoing; Wed, 20 Sep 1995 22:23:42 -0700 Received: from linux.csie.nctu.edu.tw (jdli@linux.csie.nctu.edu.tw [140.113.235.252]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA24400 for ; Wed, 20 Sep 1995 22:23:27 -0700 Received: (from jdli@localhost) by linux.csie.nctu.edu.tw (8.6.9/8.6.9) id NAA03730 for freebsd-current@FreeBSD.ORG; Thu, 21 Sep 1995 13:19:11 +0800 From: Chien-Ta Lee Message-Id: <199509210519.NAA03730@linux.csie.nctu.edu.tw> Subject: old kernel + new binaries To: freebsd-current@FreeBSD.ORG Date: Thu, 21 Sep 1995 13:19:07 +0800 (CST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 421 Sender: owner-current@FreeBSD.ORG Precedence: bulk Hi : Is it safe to use a Sep 1 (or earier) kernel with a new make world binaries ? I want to try the new stuffs in the latest current (mainly for new malloc() in libc), but currently the kernel is still WIP. Of course, I will link lkm static. Thanks. -- §õ «Ø ¹F (Adonis) ¥æ¤j¸ê¤u Mail: jdli@csie.nctu.edu.tw From owner-freebsd-current Wed Sep 20 22:33:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA24799 for current-outgoing; Wed, 20 Sep 1995 22:33:41 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA24786 for ; Wed, 20 Sep 1995 22:33:33 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA29710; Thu, 21 Sep 1995 15:28:36 +1000 Date: Thu, 21 Sep 1995 15:28:36 +1000 From: Bruce Evans Message-Id: <199509210528.PAA29710@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, roberto@keltia.Freenix.FR Subject: Re: XFree86 and the new malloc Sender: owner-current@FreeBSD.org Precedence: bulk >Has anyone tried to link the X server with the new libc's malloc from >Poul-Henning ? It's already linked to libc's malloc unless you have a version that is linked to a nonstandard libmalloc. This is one of the main advantages (?) of not putting phkmalloc in a special library that almost no one will use. It also shows why third party programs should not use nonstandard libraries to avoid problems in standard libaries. Bruce From owner-freebsd-current Wed Sep 20 23:21:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA26786 for current-outgoing; Wed, 20 Sep 1995 23:21:24 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA26777 for ; Wed, 20 Sep 1995 23:21:20 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id AAA01482; Thu, 21 Sep 1995 00:23:00 -0600 Date: Thu, 21 Sep 1995 00:23:00 -0600 From: Nate Williams Message-Id: <199509210623.AAA01482@rocky.sri.MT.net> To: Bruce Evans Cc: freebsd-current@FreeBSD.org, roberto@keltia.Freenix.FR Subject: Re: XFree86 and the new malloc In-Reply-To: <199509210528.PAA29710@godzilla.zeta.org.au> References: <199509210528.PAA29710@godzilla.zeta.org.au> Sender: owner-current@FreeBSD.org Precedence: bulk > >Has anyone tried to link the X server with the new libc's malloc from > >Poul-Henning ? > > It's already linked to libc's malloc unless you have a version that is > linked to a nonstandard libmalloc. Actually, version XFree 3.1.2 links against GNU malloc on BSD systems to minimize real memory use as far as I know. > This is one of the main advantages (?) of not putting phkmalloc in a > special library that almost no one will use. It also shows why third > party programs should not use nonstandard libraries to avoid problems > in standard libaries. Except when the 'standard' library has so many problems that the program is much more useful with these non-standard libraries. :( Nate From owner-freebsd-current Thu Sep 21 00:08:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA27771 for current-outgoing; Thu, 21 Sep 1995 00:08:11 -0700 Received: from irz401.inf.tu-dresden.de (irz401.inf.tu-dresden.de [141.76.1.12]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA27766 for ; Thu, 21 Sep 1995 00:08:06 -0700 Received: from sax.sax.de by irz401.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA25588; Thu, 21 Sep 1995 09:07:55 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA28014; Thu, 21 Sep 1995 09:07:55 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA14947; Thu, 21 Sep 1995 09:05:06 +0200 From: J Wunsch Message-Id: <199509210705.JAA14947@uriah.heep.sax.de> Subject: Re: old kernel + new binaries To: jdli@linux.csie.nctu.edu.tw (Chien-Ta Lee) Date: Thu, 21 Sep 1995 09:05:05 +0200 (MET DST) Cc: freebsd-current@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199509210519.NAA03730@linux.csie.nctu.edu.tw> from "Chien-Ta Lee" at Sep 21, 95 01:19:07 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 432 Sender: owner-current@FreeBSD.ORG Precedence: bulk As Chien-Ta Lee wrote: > > Is it safe to use a Sep 1 (or earier) kernel with a new make world > binaries ? I think so. My kernel is usually younger than the binaries. Watch the -current list for the annoucement of incompatibilities that require a partial rebuild of some utilities. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Sep 21 01:01:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA28874 for current-outgoing; Thu, 21 Sep 1995 01:01:14 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA28863 for ; Thu, 21 Sep 1995 01:00:49 -0700 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQzicu00501; Thu, 21 Sep 1995 04:00:32 -0400 Received: from uanet.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Thu, 21 Sep 1995 04:00:53 -0400 Received: by crocodil.monolit.kiev.ua; Thu, 21 Sep 95 03:13:25 +0300 Received: from dog.farm.org (farm-cs.farm.org [193.124.48.230]) by clipper.cs.kiev.ua (8.6.4) with ESMTP; Thu, 21 Sep 1995 03:06:34 +0300 Received: (from dk@localhost) by dog.farm.org (MK54/dk1) id DAA04844; Thu, 21 Sep 1995 03:07:25 +0300 Date: Thu, 21 Sep 1995 03:07:25 +0300 From: Dmitry Kohmanyuk Message-Id: <199509210007.DAA04844@dog.farm.org> To: pst@shockwave.com (Paul Traina), freebsd-current@freebsd.org Subject: Re: rmail and brain-dead mail systems .. patch enclosed Newsgroups: cs-monolit.gated.lists.freebsd.current Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-current@freebsd.org Precedence: bulk In article you wrote: > Ahh, I looked more carefully at the source code. You're absolutely right. > The way I read it from you was going the "other" way, that mail was coming > in via a remote SMTP site and you wanted the delivery agent to mung the > headers. I was completely full of shit, sorry...I'm used to the bad old > days when /bin/mail and /bin/rmail were the same piece of code. me too... I remember Xenix. I also think sendmail can do the rmail's job, but possibly worser. > What does make me curious is how does rmail enter into the picture at all? > Who is invoking it? uuxqt (after receiving mail by uucp, sent by `uux - system!rmail'). btw, why our rmail ignores the `UU_MACHINE' envariable is should get from uucp to stuff into the From_ line? why it invokes sendmail with `-oee' option (Berknet-style error handling)? -- UNIX: Any of a collection of similar operating systems that you can run the programming language 'perl' on. -- wayne@backbone.uucp (Wayne Schlitt) From owner-freebsd-current Thu Sep 21 03:32:36 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA02699 for current-outgoing; Thu, 21 Sep 1995 03:32:36 -0700 Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA02692 for ; Thu, 21 Sep 1995 03:32:27 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id LAA22070; Thu, 21 Sep 1995 11:34:27 +0100 Date: Thu, 21 Sep 1995 11:34:25 +0100 (BST) From: Doug Rabson To: Bruce Evans cc: current@freebsd.org Subject: Re: pathconf under nfsv3 In-Reply-To: <199509201209.WAA25816@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Wed, 20 Sep 1995, Bruce Evans wrote: > How is pathconf() supposed to work under nfsv3? The server seems to > support it, but the client just returns EINVAL without asking the > server. It looks like Rick wrote the server side without filling in the client side. Someone needs to fill in the client side with suitable code to make the rpc. Is it worth faking the information for NFSv2? -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Thu Sep 21 03:51:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA02975 for current-outgoing; Thu, 21 Sep 1995 03:51:12 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA02970 for ; Thu, 21 Sep 1995 03:51:10 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id DAA16682 for ; Thu, 21 Sep 1995 03:49:51 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id DAA00153 for ; Thu, 21 Sep 1995 03:52:16 -0700 Message-Id: <199509211052.DAA00153@corbin.Root.COM> To: current@freebsd.org Subject: I need a tester or two From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 21 Sep 1995 03:52:15 -0700 Sender: owner-current@freebsd.org Precedence: bulk If you happen to be awake right now (3:50AM PDT) and are having the sig-10/11/? problem with -current, please send me an email and I'll send you some changes to try out. I think I've narrowed the problem down, but need some testers to be sure... Thanks. -DG From owner-freebsd-current Thu Sep 21 05:47:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04931 for current-outgoing; Thu, 21 Sep 1995 05:47:32 -0700 Received: from irbs.irbs.com (irbs.com [199.182.75.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA04926 for ; Thu, 21 Sep 1995 05:47:28 -0700 Received: (from jc@localhost) by irbs.irbs.com (8.6.12/8.6.6) id IAA01161; Thu, 21 Sep 1995 08:46:46 -0400 From: John Capo Message-Id: <199509211246.IAA01161@irbs.irbs.com> Subject: Re: old kernel + new binaries To: jdli@linux.csie.nctu.edu.tw (Chien-Ta Lee) Date: Thu, 21 Sep 1995 08:46:45 -0400 (EDT) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199509210519.NAA03730@linux.csie.nctu.edu.tw> from "Chien-Ta Lee" at Sep 21, 95 01:19:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 520 Sender: owner-current@FreeBSD.ORG Precedence: bulk Chien-Ta Lee writes: > > > Hi : > > Is it safe to use a Sep 1 (or earier) kernel with a new make world > binaries ? > I want to try the new stuffs in the latest current (mainly for new > malloc() in libc), but currently the kernel is still WIP. > Of course, I will link lkm static. > Today that will work. There are times when the interface to some part of the kernel changes and some binaries have to track that change. I am running an August 21 kernel with -current binaries. John Capo IRBS Engineering From owner-freebsd-current Thu Sep 21 05:50:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04995 for current-outgoing; Thu, 21 Sep 1995 05:50:28 -0700 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA04974 for ; Thu, 21 Sep 1995 05:49:32 -0700 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.144.4]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id OAA21829 for ; Thu, 21 Sep 1995 14:46:51 +0200 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id OAA03990; Thu, 21 Sep 1995 14:46:47 +0200 Date: Thu, 21 Sep 1995 14:46:47 +0200 Message-Id: <199509211246.OAA03990@caramba.cs.tu-berlin.de> To: current@FreeBSD.org Subject: from(1) In-Reply-To: <199509201737.TAA03936@caramba.cs.tu-berlin.de> References: <199509201737.TAA03936@caramba.cs.tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.org Precedence: bulk Wolfram Schneider writes: >+ /* skip bytes in body (content-length) */ >+ if (header && body > 0) { >+ while(body--) >+ getc(stdin); >+ } Should be: while(body--) if (getc(stdin) == EOF) break; or more elegant: while(body-- && getc(stdin) != EOF); Wolfram -- Wolfram Schneider wosch From owner-freebsd-current Thu Sep 21 06:25:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA05895 for current-outgoing; Thu, 21 Sep 1995 06:25:01 -0700 Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA05845 for ; Thu, 21 Sep 1995 06:24:41 -0700 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.144.4]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id PAA22932; Thu, 21 Sep 1995 15:14:55 +0200 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id PAA05392; Thu, 21 Sep 1995 15:14:51 +0200 Date: Thu, 21 Sep 1995 15:14:51 +0200 Message-Id: <199509211314.PAA05392@caramba.cs.tu-berlin.de> To: "Garrett A. Wollman" Cc: current@freebsd.org Subject: from(1) In-Reply-To: <9509201814.AA04895@halloran-eldar.lcs.mit.edu> References: <199509201737.TAA03936@caramba.cs.tu-berlin.de> <9509201814.AA04895@halloran-eldar.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org Precedence: bulk Garrett A. Wollman writes: >< said: > >> - Option '-c' print a count of matching lines > >Use wc(1). An option is better than a pipe a) in a perl script, a pipe force system to use sh -c instead exec/fork b) for aliases alias fb='from -tcs owner-freebsd-security' is simpler than [for bash] fb () { from -tcs owner-freebsd-security "$@" | wc -l } most people forget the "$@" >> - Option '-t' don't change access time > >Or, alternatively: > - Option '-t' change modification time Change modification time for *reading* a file??? >Or, for that matter: > > $ zcat hack.gz | egrep '^From ' | wc -l This is only true for the *first* mail. >And `Content-Length' is a really idiotic AT&T-ism designed by people >who didn't understand mail; I would not bloat our programs by >attempting to support it. Look at your mailbox. All freebsd mailinglists have content-length. $ egrep '^From ' *|wc -l 200 $ egrep '^content-length' *|wc -l 200 Wolfram -- Wolfram Schneider wosch From owner-freebsd-current Thu Sep 21 09:57:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA20411 for current-outgoing; Thu, 21 Sep 1995 09:57:14 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA20398 for ; Thu, 21 Sep 1995 09:57:10 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id KAA02299; Thu, 21 Sep 1995 10:59:18 -0600 Date: Thu, 21 Sep 1995 10:59:18 -0600 From: Nate Williams Message-Id: <199509211659.KAA02299@rocky.sri.MT.net> To: Ollivier Robert Cc: nate@rocky.sri.MT.net (Nate Williams), freebsd-current@FreeBSD.org Subject: Re: XFree86 and the new malloc In-Reply-To: <199509210650.IAA23127@keltia.Freenix.FR> References: <199509210623.AAA01482@rocky.sri.MT.net> <199509210650.IAA23127@keltia.Freenix.FR> Sender: owner-current@FreeBSD.org Precedence: bulk Ollivier Robert writes: > It seems that Nate Williams said: > > Except when the 'standard' library has so many problems that the program > > is much more useful with these non-standard libraries. :( > > What problems did you find with the new malloc (apart from extra messages > about memory-handling error in the program) ? I've not tried the new malloc > yet and that's why I ask the question. I was talking about the reasons people used the GNU malloc library with some of their programs rather than using the stock BSD malloc. Basically, the stock BSD malloc caused a number of programs to be less useful than they were if compiled against GNU malloc. I was following up to Bruce's assertion that programs should always use the standard libraries instead of special purpose (non-standard) libraries. Nate From owner-freebsd-current Thu Sep 21 11:35:08 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA23928 for current-outgoing; Thu, 21 Sep 1995 11:35:08 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA23911 for ; Thu, 21 Sep 1995 11:35:03 -0700 Received: by crox.net.kiae.su id WAA00880; (8.6.9/vak/1.8a) Thu, 21 Sep 1995 22:31:23 +0400 Date: Thu, 21 Sep 1995 22:31:16 +0400 (MSD) From: "Serge V.Vakulenko" To: current@freebsd.org Subject: [patch] more stable version of wdreset() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk This patch is intended to solve the problem of broken IDE disks probing in the FreeBSD-current. For IDE disks it works the same the 2.0.5 did. For detecting ATAPI drives it tests for the ATAPI signature in cyl_hi/cyl_lo registers. Serge --- wd-c.c Thu Sep 21 21:55:31 1995 +++ wd.c Thu Sep 21 21:56:28 1995 @@ -1907,13 +1907,18 @@ outb(wdc + wd_ctlr, WDCTL_IDS | WDCTL_RST); DELAY(10 * 1000); outb(wdc + wd_ctlr, WDCTL_IDS); - if (wdwait(du, 0, TIMEOUT) != 0) - return (1); - du->dk_status = inb(wdc + wd_status); - du->dk_error = inb(wdc + wd_error); - if ((du->dk_status & ~(WDCS_READY | WDCS_SEEKCMPLT)) != 0 || - du->dk_error != 0x01) - return (1); + if (wdwait(du, WDCS_READY | WDCS_SEEKCMPLT, TIMEOUT) == 0) { + /* IDE drive found */ + du->dk_error = inb(wdc + wd_error); + if (du->dk_error != 0x01) + return (1); + } else { + /* no IDE drive, test for ATAPI signature */ + int lo = inb(wdc + wd_cyl_lo); + int hi = inb(wdc + wd_cyl_hi); + if (lo != 0x14 || hi != 0xeb) + return (1); + } outb(wdc + wd_ctlr, WDCTL_4BIT); return (0); } --- Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development From owner-freebsd-current Thu Sep 21 12:10:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA24555 for current-outgoing; Thu, 21 Sep 1995 12:10:24 -0700 Received: from alpha.netcraft.co.uk ([194.72.238.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA24550 for ; Thu, 21 Sep 1995 12:10:17 -0700 Received: (from paul@localhost) by alpha.netcraft.co.uk (8.6.11/8.6.9) id UAA05332 for FreeBSD-current@FreeBSD.org; Thu, 21 Sep 1995 20:09:02 +0100 From: Paul Richards Message-Id: <199509211909.UAA05332@alpha.netcraft.co.uk> Subject: sup files To: FreeBSD-current@FreeBSD.org (FreeBSD current mailing list) Date: Thu, 21 Sep 1995 20:09:02 +0100 (BST) Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 448 Sender: owner-current@FreeBSD.org Precedence: bulk Having just installed a new machine I've run into that same problem I do everytime, "Where the hell are the current sup files kept?" So, did we ever resolve this. Can we stick the sup files somewhere that gets picked up by sup itself so that when they get changed you end up with the updated copy? -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Thu Sep 21 12:23:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA25043 for current-outgoing; Thu, 21 Sep 1995 12:23:05 -0700 Received: from devnull (devnull.mpd.tandem.com [131.124.4.29]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA25037 for ; Thu, 21 Sep 1995 12:23:03 -0700 Received: from olympus by devnull (8.6.8/8.6.6) id OAA26336; Thu, 21 Sep 1995 14:22:35 -0500 Received: by olympus (4.1/TSS2.1) id AA21896; Thu, 21 Sep 95 14:22:45 CDT From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9509211922.AA21896@olympus> Subject: Re: XFree86 and the new malloc To: bde@zeta.org.au (Bruce Evans) Date: Thu, 21 Sep 1995 14:22:44 -0500 (CDT) Cc: freebsd-current@FreeBSD.org, roberto@keltia.Freenix.FR In-Reply-To: <199509210528.PAA29710@godzilla.zeta.org.au> from "Bruce Evans" at Sep 21, 95 03:28:36 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 905 Sender: owner-current@FreeBSD.org Precedence: bulk > > >Has anyone tried to link the X server with the new libc's malloc from > >Poul-Henning ? > > It's already linked to libc's malloc unless you have a version that is > linked to a nonstandard libmalloc. This is one of the main advantages > (?) of not putting phkmalloc in a special library that almost no one > will use. It also shows why third party programs should not use > nonstandard libraries to avoid problems in standard libaries. > > Bruce > But I am glad XFree did. Andrew's ez would not work with XFree86 3.1 which was linked with libc's malloc while it did with R5 and R6 3.1.2 linked with gnumalloc. Of course, had it worked, I wouldn't have cared. Boyd -- _______________________________________________________________________ Boyd Faulkner - faulkner@isd.tandem.com - http://cactus.org/~faulkner _______________________________________________________________________ From owner-freebsd-current Thu Sep 21 12:24:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA25144 for current-outgoing; Thu, 21 Sep 1995 12:24:56 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA25136 for ; Thu, 21 Sep 1995 12:24:52 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id PAA12830; Thu, 21 Sep 1995 15:14:14 -0400 Date: Thu, 21 Sep 1995 15:14:11 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: sup files To: paul@netcraft.co.uk cc: FreeBSD current mailing list In-Reply-To: <199509211909.UAA05332@alpha.netcraft.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Thu, 21 Sep 1995, Paul Richards wrote: > Having just installed a new machine I've run into that > same problem I do everytime, "Where the hell are the current > sup files kept?" on freefall.cdrom.com /usr/src/share/FAQ/extras/*-supfile when you sup share, you should get the latest supfiles. > So, did we ever resolve this. Can we stick the sup files somewhere > that gets picked up by sup itself so that when they get changed you > end up with the updated copy? Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-current Thu Sep 21 12:29:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA25358 for current-outgoing; Thu, 21 Sep 1995 12:29:45 -0700 Received: from alpha.netcraft.co.uk ([194.72.238.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA25353 for ; Thu, 21 Sep 1995 12:29:42 -0700 Received: (from paul@localhost) by alpha.netcraft.co.uk (8.6.11/8.6.9) id UAA05411; Thu, 21 Sep 1995 20:27:44 +0100 From: Paul Richards Message-Id: <199509211927.UAA05411@alpha.netcraft.co.uk> Subject: Re: sup files To: jmb@kryten.Atinc.COM (Jonathan M. Bresler) Date: Thu, 21 Sep 1995 20:27:44 +0100 (BST) Cc: paul@netcraft.co.uk, FreeBSD-current@FreeBSD.org In-Reply-To: from "Jonathan M. Bresler" at Sep 21, 95 03:14:11 pm Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 727 Sender: owner-current@FreeBSD.org Precedence: bulk In reply to Jonathan M. Bresler who said > > On Thu, 21 Sep 1995, Paul Richards wrote: > > > Having just installed a new machine I've run into that > > same problem I do everytime, "Where the hell are the current > > sup files kept?" > > on freefall.cdrom.com /usr/src/share/FAQ/extras/*-supfile > > when you sup share, you should get the latest supfiles. Ahh, should have been more specific, the cvs supfiles. I don't think we decided what to do last time. Maybe we can stick them in the same place or perhaps we want to put them in the cvs tree somewhere, like CVSROOT. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Thu Sep 21 12:52:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA25955 for current-outgoing; Thu, 21 Sep 1995 12:52:34 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA25950 for ; Thu, 21 Sep 1995 12:52:32 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA09277; Thu, 21 Sep 1995 12:49:47 -0700 From: Terry Lambert Message-Id: <199509211949.MAA09277@phaeton.artisoft.com> Subject: Re: 2.2 looking up To: davidg@root.com Date: Thu, 21 Sep 1995 12:49:46 -0700 (MST) Cc: terry@lambert.org, staff@kyklopen.ping.dk, ugen@latte.worldbank.org, current@FreeBSD.org, bugs@ns1.win.net In-Reply-To: <199509210406.VAA00133@corbin.Root.COM> from "David Greenman" at Sep 20, 95 09:06:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 320 Sender: owner-current@FreeBSD.org Precedence: bulk > >Definite difference between shared and unshared programs. > > Not really. The kernel does an identical mmap for the program binary > itself. Not identical. That one works. 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 Sep 21 12:58:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA26119 for current-outgoing; Thu, 21 Sep 1995 12:58:22 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA26114 for ; Thu, 21 Sep 1995 12:58:20 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA09323; Thu, 21 Sep 1995 12:53:37 -0700 From: Terry Lambert Message-Id: <199509211953.MAA09323@phaeton.artisoft.com> Subject: Re: pathconf under nfsv3 To: dfr@render.com (Doug Rabson) Date: Thu, 21 Sep 1995 12:53:37 -0700 (MST) Cc: bde@zeta.org.au, current@FreeBSD.org In-Reply-To: from "Doug Rabson" at Sep 21, 95 11:34:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 414 Sender: owner-current@FreeBSD.org Precedence: bulk > It looks like Rick wrote the server side without filling in the client > side. Someone needs to fill in the client side with suitable code to > make the rpc. Is it worth faking the information for NFSv2? After looking at what it does, I'd say yes, it is worth faking. 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 Sep 21 13:10:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA26814 for current-outgoing; Thu, 21 Sep 1995 13:10:14 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAB26807 for ; Thu, 21 Sep 1995 13:10:07 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA08071; Thu, 21 Sep 1995 22:09:09 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA05013; Thu, 21 Sep 1995 22:09:08 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id TAA16378; Thu, 21 Sep 1995 19:38:24 +0200 From: J Wunsch Message-Id: <199509211738.TAA16378@uriah.heep.sax.de> Subject: Re: rmail and brain-dead mail systems .. patch enclosed To: dk+@ua.net Date: Thu, 21 Sep 1995 19:38:23 +0200 (MET DST) Cc: pst@shockwave.com, freebsd-current@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199509210007.DAA04844@dog.farm.org> from "Dmitry Kohmanyuk" at Sep 21, 95 03:07:25 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 437 Sender: owner-current@FreeBSD.ORG Precedence: bulk As Dmitry Kohmanyuk wrote: > > I also think sendmail can do the rmail's job, but possibly worser. Not worse. It does it as well, i've once been using it since it had to work in an environment where some mails didn't have the From_ line above, but rmail insists on it (for no good reason). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Sep 21 13:23:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA27388 for current-outgoing; Thu, 21 Sep 1995 13:23:25 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA27368 for ; Thu, 21 Sep 1995 13:23:17 -0700 Received: by crox.net.kiae.su id AAA00190; (8.6.9/vak/1.8a) Fri, 22 Sep 1995 00:19:12 +0400 To: current@freebsd.org, josh@American.COM References: Message-ID: Organization: Cronyx Ltd. Date: Fri, 22 Sep 95 00:19:12 +0400 X-Mailer: BML [UNIX Beauty Mail v.1.39] From: vak@cronyx.ru Subject: Re: more ATAPI CD issues Sender: owner-current@freebsd.org Precedence: bulk > First, the current layering of wd.c is obviously not well suited to this > configuration. Your ATAPI controller has to react a certain way to particular > ATA commands to get to the point of being probed at all as an ATAPI CD. The 3 > trials of ATA you must pass are 1) writable byte count / cyl. address > registers, 2) successful wdreset(), and 3) successful WDCC_DIAGNOSE behavior. > > The first test is reasonable, for what its worth. This test could fail for single-drive configurations. The driver does not set the drive unit number to 0 before testing the cylinder register. If the BIOS leaves it set to 1, then the test will fail... > My ATAPI CD fails the > current implementation of wdreset(), although the ATAPI spec is pretty > specific about how this should be handled and the code looks potentially > correct. I need to trace this down more. The current version of wdreset() is incorrect with respect to ATA specs. I made another version, which works correctly for IDE disks, and uses an ATAPI signature to identify an ATAPI drive. I posted it to freebsd-current list. > The next issue is with the MODE_SENSE issued by the wcd code. It asks for the > CDROM Capabilites page (0x2A). It expects this in a 24 byte struct and asks > for 24 bytes. However, my ATAPI spec indicates that this page is 28 bytes > long, and that's also what my device tries to send. The atapi.c code > considers this an overrun (although the device indicates no errors) and leaves > the data on the table. By defining the last 4 bytes in the capabilities > struct, giving me a 28 byte struct, I succeed with the MODE_SENSE and get > valid information. Really, it's a problem. Not a bug though, just an incompatibility. A lot of drives, such as Toshiba XM5302, Mitsumi FX400, NEC 260, Dolphin 8001, etc. have 16-byte Capabilities page length, not 20 bytes as it should be according to ATAPI specs. > I have a couple of issues/questions with this. First, wcd.c seems to be using > too small a struct for this MODE_SENSE command. Perhaps this is version skew > on the ATAPI spec? Second, the spec indicates that since a host doesn't know > how much data will be returned with a MODE_SENSE, it should rely on the byte > count registers from the device. This is probably referring to a request for > ALL pages, which returns an unpredictable amount of data. However the spec > says that, in general, the host should divert to the bit bucket any excess > data offered by the device (and send pad bytes when the device asks for more > than is required). Seems like atapi_io() should be less sensitive to > overrun/underrun. Finally, even if we consider the byte count in error, it > does no good to leave the data there. It would think it better to transfer > the data to the bit bucket to finish the command, returning an error. I tried to fix this in version 1.5 of the driver. I'll send the patches to freebsd-current today. Serge --- Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development From owner-freebsd-current Thu Sep 21 13:30:39 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA27649 for current-outgoing; Thu, 21 Sep 1995 13:30:39 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA27641 for ; Thu, 21 Sep 1995 13:30:36 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA26779 for current@freebsd.org; Thu, 21 Sep 1995 13:29:21 -0700 From: Terry Lambert Message-Id: <199509212029.NAA26779@phaeton.artisoft.com> Subject: chroot wierdness in namei() To: current@freebsd.org Date: Thu, 21 Sep 1995 13:29:21 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2166 Sender: owner-current@freebsd.org Precedence: bulk In the lookup() function callwd by namei() in vfs_lookup.c, the following loop is present for processing "..": if (cnp->cn_flags & ISDOTDOT) { for (;;) { *** if (dp == ndp->ni_rootdir || dp == rootvnode) { ndp->ni_dvp = dp; ndp->ni_vp = dp; VREF(dp); goto nextname; } if ((dp->v_flag & VROOT) == 0 || (cnp->cn_flags & NOCROSSMOUNT)) break; tdp = dp; dp = dp->v_mount->mnt_vnodecovered; vput(tdp); VREF(dp); VOP_LOCK(dp); } } In the line marked "***", does anyone else think the "dp == rootvnode" check is bogus? In the namei() that calls it, the following code is used: /* * Get starting point for the translation. */ if ((ndp->ni_rootdir = fdp->fd_rdir) == NULL) ndp->ni_rootdir = rootvnode; dp = fdp->fd_cdir; VREF(dp); The only failure case I see is: I) A security hole is exercised: 1) open 'dir' 2) chroot to subtree not containing 'dir' 3) fchdir() to 'dir' (making the current directory outside the chrooted heirarchy). 4) use a relative path containing ".." from there causing an attempt at a ".." traversal of the real "/". II) A directory hard link transits out of the chroot'ed subgraph. It seems this would be a security hole in any case, right? I could write a program to open an fd for a dir and turn off close on exec and then run an suid program that chroot'ed me and then sneak out. Right? I mean one could use the "play" chroot() suggested in the hack sources or an SUID perl script (using "secure" perl) or any of a number of tools for doing things like administering your personal area of a public FTP server. Perhaps fd's open to VDIR vnodes should be closed on chroot(2)? It's not like chroot()'ing is a reversable process (well, unless you have an fd to a dir out of the chrooted'ed hierarchy and use it to call chroot again to chroot to "/". 8-)), so perhaps this hole should be plugged? And then the check for rootvnode removed from lookup()? Directory hard links should be an error in any case (needs fixed). 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 Sep 21 14:03:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28869 for current-outgoing; Thu, 21 Sep 1995 14:03:45 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28861 for ; Thu, 21 Sep 1995 14:03:29 -0700 Received: by crox.net.kiae.su id AAA00296; (8.6.9/vak/1.8a) Fri, 22 Sep 1995 00:59:11 +0400 Date: Fri, 22 Sep 1995 00:59:11 +0400 (MSD) From: "Serge V.Vakulenko" To: current@freebsd.org Subject: [patch] version 1.5 of ATAPI CD-ROM driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk This version fixes the following bugs: -- drq type was incorrectly printed -- support for drives which identify itself as direct-type (instead of type CDROM) added -- model string for NEC and Mitsumi drives was printed with incorrect byte order -- data underrun/overrun bug fixed -- NEC 260 i/o phase incompatibility fixed New features added: -- The drive revision number is printed during attach. Serge --- atapi-c.c Fri Sep 22 00:45:18 1995 +++ atapi.c Fri Sep 22 00:45:18 1995 @@ -11,7 +11,7 @@ * or modify this software as long as this message is kept with the software, * all derivative works or modified versions. * - * Version 1.3, Mon Aug 28 21:44:01 MSD 1995 + * Version 1.5, Thu Sep 21 23:08:11 MSD 1995 */ /* @@ -129,6 +129,7 @@ #define PHASE_DATAIN (ARS_DRQ | ARI_IN) #define PHASE_DATAOUT ARS_DRQ #define PHASE_COMPLETED (ARI_IN | ARI_CMD) +#define PHASE_ABORTED 0 /* nonstandard - for NEC 260 */ struct atapicmd { /* ATAPI command block */ struct atapicmd *next; /* next command in queue */ @@ -172,6 +173,7 @@ struct atapi *ata = atapitab + ctlr; struct atapi_params *ap; char buf [sizeof(ap->model) + 1]; + char revbuf [sizeof(ap->revision) + 1]; struct atapicmd *ac; print (("atapi%d.%d at 0x%x: attach called\n", ctlr, unit, port)); @@ -181,7 +183,11 @@ bcopy (ap->model, buf, sizeof(buf)-1); buf[sizeof(buf)-1] = 0; - printf ("wdc%d: unit %d (atapi): <%s>", ctlr, unit, buf); + + bcopy (ap->revision, revbuf, sizeof(revbuf)-1); + revbuf[sizeof(revbuf)-1] = 0; + + printf ("wdc%d: unit %d (atapi): <%s/%s>", ctlr, unit, buf, revbuf); /* device is removable */ if (ap->removable) @@ -199,7 +205,7 @@ case AT_DRQT_MPROC: ata->slow = 1; break; case AT_DRQT_INTR: printf (", intr"); ata->intrcmd = 1; break; case AT_DRQT_ACCEL: printf (", accel"); break; - default: printf (", drq%d", ap->cmdsz); + default: printf (", drq%d", ap->drqtype); } /* overlap operation supported */ @@ -242,22 +248,16 @@ return; } switch (ap->devtype) { - default: /* unknown ATAPI device */ - printf ("wdc%d: unit %d: unknown ATAPI device type=%d\n", + default: + /* unknown ATAPI device */ + printf ("wdc%d: unit %d: unknown ATAPI type=%d\n", ctlr, unit, ap->devtype); break; - case AT_TYPE_DIRECT: /* direct-access (magnetic disk) */ -#if NWHD > 0 - /* Add your driver here */ -#else - printf ("wdc%d: ATAPI hard disks not supported\n", ctlr); - printf ("wdc%d: Could be old ATAPI CDROM, trying...\n", ctlr); - break; -#endif - + case AT_TYPE_DIRECT: /* direct-access */ case AT_TYPE_CDROM: /* CD-ROM device */ #if NWCD > 0 + /* ATAPI CD-ROM */ { int wcdattach (struct atapi*, int, struct atapi_params*, int, struct kern_devconf*); @@ -275,7 +275,7 @@ #if NWMT > 0 /* Add your driver here */ #else - printf ("wdc%d: ATAPI streaming tapes not supported\n", ctlr); + printf ("wdc%d: ATAPI streaming tapes not supported yet\n", ctlr); break; #endif @@ -283,7 +283,7 @@ #if NWMD > 0 /* Add your driver here */ #else - printf ("wdc%d: ATAPI optical disks not supported\n", ctlr); + printf ("wdc%d: ATAPI optical disks not supported yet\n", ctlr); break; #endif } @@ -291,6 +291,25 @@ free (ap, M_TEMP); } +static void bswap (char *buf, int len) +{ + u_short *p = (u_short*) (buf + len); + while (--p >= (u_short*) buf) + *p = ntohs (*p); +} + +static void btrim (char *buf, int len) +{ + char *p; + + /* Remove the trailing spaces. */ + for (p=buf; p=buf && *p==' '; --p) + *p = 0; +} + /* * Issue IDENTIFY command to ATAPI drive to ask it what it is. */ @@ -298,11 +317,10 @@ { struct atapi_params *ap; char tb [DEV_BSIZE]; - int i; /* Wait for controller not busy. */ if (atapi_wait (port, 0) < 0) { - print (("atapi.%d at 0x%x: controller busy, status=%b\n", + print (("atapiX.%d at 0x%x: controller busy, status=%b\n", unit, port, inb (port + AR_STATUS), ARS_BITS)); return (0); } @@ -313,7 +331,7 @@ /* Check that device is present. */ if (inb (port + AR_STATUS) == 0xff) { - print (("atapi.%d at 0x%x: no device\n", unit, port)); + print (("atapiX.%d at 0x%x: no device\n", unit, port)); if (unit == 1) /* Select unit 0. */ outb (port + AR_DRIVE, ARD_DRIVE0); @@ -322,7 +340,7 @@ /* Wait for data ready. */ if (atapi_wait (port, ARS_DRQ) != 0) { - print (("atapi.%d at 0x%x: identify not ready, status=%b\n", + print (("atapiX.%d at 0x%x: identify not ready, status=%b\n", unit, port, inb (port + AR_STATUS), ARS_BITS)); if (unit == 1) /* Select unit 0. */ @@ -344,18 +362,15 @@ */ if (! ((ap->model[0] == 'N' && ap->model[1] == 'E') || (ap->model[0] == 'F' && ap->model[1] == 'X'))) { - u_short *p = (u_short*) (ap->model + sizeof(ap->model)); - while (--p >= (u_short*) ap->model) - *p = ntohs (*p); + bswap (ap->model, sizeof(ap->model)); + bswap (ap->serial, sizeof(ap->serial)); + bswap (ap->revision, sizeof(ap->revision)); } - /* Clean up the model by converting nulls to spaces, and - * then removing the trailing spaces. */ - for (i=0; i < sizeof(ap->model); i++) - if (! ap->model[i]) - ap->model[i] = ' '; - for (i=sizeof(ap->model)-1; i>=0 && ap->model[i]==' '; i--) - ap->model[i] = 0; + /* Clean up the model name, serial and revision numbers. */ + btrim (ap->model, sizeof(ap->model)); + btrim (ap->serial, sizeof(ap->serial)); + btrim (ap->revision, sizeof(ap->revision)); return (ap); } @@ -585,7 +600,7 @@ int atapi_io (struct atapi *ata, struct atapicmd *ac) { u_char ireason; - u_short len; + u_short len, i; if (atapi_wait (ata->port, 0) < 0) { ac->result.status = inb (ata->port + AR_STATUS); @@ -635,12 +650,16 @@ break; } if (-ac->count < len) { - printf ("atapi%d.%d: send data underrun, %d bytes left\n", - ata->ctrlr, ac->unit, -ac->count); + print (("atapi%d.%d: send data underrun, %d bytes left\n", + ata->ctrlr, ac->unit, -ac->count)); ac->result.code = RES_UNDERRUN; - break; - } - outsw (ata->port + AR_DATA, ac->addr, len / sizeof(short)); + outsw (ata->port + AR_DATA, ac->addr, + -ac->count / sizeof(short)); + for (i= -ac->count; iport + AR_DATA, 0); + } else + outsw (ata->port + AR_DATA, ac->addr, + len / sizeof(short)); ac->addr += len; ac->count += len; return (1); @@ -654,34 +673,35 @@ break; } if (ac->count < len) { - printf ("atapi%d.%d: recv data overrun, %d bytes left\n", - ata->ctrlr, ac->unit, ac->count); + print (("atapi%d.%d: recv data overrun, %d bytes left\n", + ata->ctrlr, ac->unit, ac->count)); ac->result.code = RES_OVERRUN; - break; - } - insw (ata->port + AR_DATA, ac->addr, len / sizeof(short)); + insw (ata->port + AR_DATA, ac->addr, + ac->count / sizeof(short)); + for (i=ac->count; iport + AR_DATA); + } else + insw (ata->port + AR_DATA, ac->addr, + len / sizeof(short)); ac->addr += len; ac->count -= len; return (1); + case PHASE_ABORTED: case PHASE_COMPLETED: - if (ac->result.status & (ARS_CHECK | ARS_DF)) { + if (ac->result.status & (ARS_CHECK | ARS_DF)) ac->result.code = RES_ERR; - break; - } - if (ac->count < 0) { - printf ("atapi%d.%d: send data overrun, %d bytes left\n", - ata->ctrlr, ac->unit, -ac->count); + else if (ac->count < 0) { + print (("atapi%d.%d: send data overrun, %d bytes left\n", + ata->ctrlr, ac->unit, -ac->count)); ac->result.code = RES_OVERRUN; - break; - } - if (ac->count > 0) { - printf ("atapi%d.%d: recv data underrun, %d bytes left\n", - ata->ctrlr, ac->unit, ac->count); + } else if (ac->count > 0) { + print (("atapi%d.%d: recv data underrun, %d bytes left\n", + ata->ctrlr, ac->unit, ac->count)); ac->result.code = RES_UNDERRUN; - break; - } - ac->result.code = RES_OK; + bzero (ac->addr, ac->count); + } else + ac->result.code = RES_OK; break; } return (0); @@ -817,6 +837,12 @@ if (atapi_start_cmd (ata, ac) >= 0 && atapi_wait_cmd (ata, ac) >= 0) { /* Send packet command. */ atapi_send_cmd (ata, ac); + + /* Wait for data i/o phase. */ + for (cnt=20000; cnt>0; --cnt) + if (((inb (ata->port + AR_IREASON) & (ARI_CMD | ARI_IN)) | + (inb (ata->port + AR_STATUS) & ARS_DRQ)) != PHASE_CMDOUT) + break; /* Do all needed i/o. */ while (atapi_io (ata, ac)) --- atapi-c.h Fri Sep 22 00:45:18 1995 +++ atapi.h Fri Sep 22 00:45:18 1995 @@ -11,7 +11,7 @@ * or modify this software as long as this message is kept with the software, * all derivative works or modified versions. * - * Version 1.1, Mon Jul 10 21:55:11 MSD 1995 + * Version 1.4, Tue Sep 5 20:59:48 MSD 1995 */ /* @@ -112,21 +112,21 @@ */ struct atapi_params { unsigned cmdsz : 2; /* packet command size */ -#define AT_PSIZE_12 0 -#define AT_PSIZE_16 1 +#define AT_PSIZE_12 0 /* 12 bytes */ +#define AT_PSIZE_16 1 /* 16 bytes */ unsigned : 3; unsigned drqtype : 2; /* DRQ type */ #define AT_DRQT_MPROC 0 /* microprocessor DRQ - 3 msec delay */ #define AT_DRQT_INTR 1 /* interrupt DRQ - 10 msec delay */ #define AT_DRQT_ACCEL 2 /* accelerated DRQ - 50 usec delay */ unsigned removable : 1; /* device is removable */ - unsigned devtype : 5; /* packet command size */ + unsigned devtype : 5; /* device type */ #define AT_TYPE_DIRECT 0 /* direct-access (magnetic disk) */ #define AT_TYPE_TAPE 1 /* streaming tape (QIC-121 model) */ #define AT_TYPE_CDROM 5 /* CD-ROM device */ #define AT_TYPE_OPTICAL 7 /* optical disk */ unsigned : 1; - unsigned proto : 2; /* packet command size */ + unsigned proto : 2; /* command protocol */ #define AT_PROTO_ATAPI 2 short reserved1[9]; char serial[20]; /* serial number - optional */ @@ -146,7 +146,7 @@ short reserved4; u_short pio_timing; /* PIO cycle timing */ u_short dma_timing; /* DMA cycle timing */ - u_short flags; /* flags */ + u_short flags; #define AT_FLAG_54_58 1 /* words 54-58 valid */ #define AT_FLAG_64_70 2 /* words 64-70 valid */ short reserved5[8]; --- wcd-c.c Fri Sep 22 00:45:18 1995 +++ wcd.c Fri Sep 22 00:48:50 1995 @@ -12,12 +12,9 @@ * or modify this software as long as this message is kept with the software, * all derivative works or modified versions. * - * Version 1.2, Mon Jul 24 17:21:25 MSD 1995 + * Version 1.5, Thu Sep 21 23:08:11 MSD 1995 */ -/* - * The driver was tested on Toshiba XM-5302TA drive. (vak) - */ #include "wdc.h" #include "wcd.h" #if NWCD > 0 && NWDC > 0 && defined (ATAPI) @@ -166,6 +163,19 @@ u_short max_vol_levels; /* number of discrete volume levels */ u_short buf_size; /* internal buffer size in bytes/1024 */ u_short cur_speed; /* current data rate in bytes/1000 */ + + /* Digital drive output format description (optional?) */ + u_char reserved3; + u_char bckf : 1; /* data valid on failing edge of BCK */ + u_char rch : 1; /* high LRCK indicates left channel */ + u_char lsbf : 1; /* set if LSB first */ + u_char dlen: 2; +#define DLEN_32 0 /* 32 BCKs */ +#define DLEN_16 1 /* 16 BCKs */ +#define DLEN_24 2 /* 24 BCKs */ +#define DLEN_24_I2S 3 /* 24 BCKs (I2S) */ + u_char : 3; + u_char reserved4[2]; }; struct wcd { @@ -262,16 +272,22 @@ } /* Get drive capabilities. */ - /* Do it twice to avoid the stale media changed state. */ result = atapi_request_immediate (ata, unit, ATAPI_MODE_SENSE, 0, CAP_PAGE, 0, 0, 0, 0, sizeof (t->cap) >> 8, sizeof (t->cap), 0, 0, 0, 0, 0, 0, 0, (char*) &t->cap, sizeof (t->cap)); - if (result.code == RES_ERR && result.error == AER_SK_UNIT_ATTENTION) + /* Do it twice to avoid the stale media changed state. */ + if (result.code == RES_ERR && + (result.error & AER_SKEY) == AER_SK_UNIT_ATTENTION) result = atapi_request_immediate (ata, unit, ATAPI_MODE_SENSE, 0, CAP_PAGE, 0, 0, 0, 0, sizeof (t->cap) >> 8, sizeof (t->cap), 0, 0, 0, 0, 0, 0, 0, (char*) &t->cap, sizeof (t->cap)); + + /* Some drives have shorter capabilities page. */ + if (result.code == RES_UNDERRUN) + result.code = 0; + if (result.code == 0) { wcd_describe (t); if (t->flags & F_DEBUG) @@ -302,7 +318,7 @@ printf ("wcd%d: ", t->lun); if (t->cap.cur_speed != t->cap.max_speed) printf ("%d/", t->cap.cur_speed * 1000 / 1024); - printf ("%dKb/sec", t->cap.max_speed * 1000 / 1024, t->cap.buf_size); + printf ("%dKb/sec", t->cap.max_speed * 1000 / 1024); if (t->cap.buf_size) printf (", %dKb cache", t->cap.buf_size); @@ -373,7 +389,8 @@ result = atapi_request_wait (t->ata, t->unit, ATAPI_TEST_UNIT_READY, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0); - if (result.code == RES_ERR && result.error == AER_SK_UNIT_ATTENTION) { + if (result.code == RES_ERR && + (result.error & AER_SKEY) == AER_SK_UNIT_ATTENTION) { t->flags |= F_MEDIA_CHANGED; result = atapi_request_wait (t->ata, t->unit, ATAPI_TEST_UNIT_READY, 0, 0, 0, 0, 0, 0, 0, 0, @@ -394,6 +411,9 @@ return (EIO); t->info.volsize = ntohl (t->info.volsize); t->info.blksize = ntohl (t->info.blksize); + + /* Print the disc description string on every disc change. + * It would help to track the history of disc changes. */ if (t->flags & (F_MEDIA_CHANGED | F_DEBUG)) { printf ("wcd%d: ", t->lun); if (t->toc.tab[0].control & 4) @@ -538,37 +558,34 @@ { if (result.code != RES_ERR) return; - switch (result.error) { + switch (result.error & AER_SKEY) { case AER_SK_NOT_READY: + if (result.error & ~AER_SKEY) { + /* Audio disc. */ + printf ("wcd%d: cannot read audio disc\n", t->lun); + return; + } /* Tray open. */ if (! (t->flags & F_MEDIA_CHANGED)) printf ("wcd%d: tray open\n", t->lun); t->flags |= F_MEDIA_CHANGED; - break; + return; case AER_SK_UNIT_ATTENTION: /* Media changed. */ if (! (t->flags & F_MEDIA_CHANGED)) printf ("wcd%d: media changed\n", t->lun); t->flags |= F_MEDIA_CHANGED; - break; - - case AER_SK_NOT_READY | AER_ILI | AER_EOM: - /* Audio disc. */ - printf ("wcd%d: cannot read audio disc\n", t->lun); - break; + return; case AER_SK_ILLEGAL_REQUEST: /* Unknown command or invalid command arguments. */ if (t->flags & F_DEBUG) printf ("wcd%d: invalid command\n", t->lun); - break; - - default: - printf ("wcd%d: i/o error, status=%b, error=%b\n", t->lun, - result.status, ARS_BITS, result.error, AER_BITS); - break; + return; } + printf ("wcd%d: i/o error, status=%b, error=%b\n", t->lun, + result.status, ARS_BITS, result.error, AER_BITS); } static int wcd_request_wait (struct wcd *t, u_char cmd, u_char a1, u_char a2, @@ -617,11 +634,15 @@ return (ENOTTY); case CDIOCSETDEBUG: + if (p->p_cred->pc_ucred->cr_uid) + return (EPERM); t->flags |= F_DEBUG; atapi_debug (t->ata, 1); return 0; case CDIOCCLRDEBUG: + if (p->p_cred->pc_ucred->cr_uid) + return (EPERM); t->flags &= ~F_DEBUG; atapi_debug (t->ata, 0); return 0; @@ -651,6 +672,8 @@ 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0); case CDIOCRESET: + if (p->p_cred->pc_ucred->cr_uid) + return (EPERM); return wcd_request_wait (t, ATAPI_TEST_UNIT_READY, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0); --- Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development From owner-freebsd-current Thu Sep 21 14:26:31 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA29542 for current-outgoing; Thu, 21 Sep 1995 14:26:31 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA29521 for ; Thu, 21 Sep 1995 14:25:09 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id OAA00831; Thu, 21 Sep 1995 14:23:08 -0700 From: "Rodney W. Grimes" Message-Id: <199509212123.OAA00831@GndRsh.aac.dev.com> Subject: Re: rmail and brain-dead mail systems .. patch enclosed To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 21 Sep 1995 14:23:08 -0700 (PDT) Cc: dk+@ua.net, pst@shockwave.com, freebsd-current@FreeBSD.ORG In-Reply-To: <199509211738.TAA16378@uriah.heep.sax.de> from "J Wunsch" at Sep 21, 95 07:38:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 751 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > As Dmitry Kohmanyuk wrote: > > > > I also think sendmail can do the rmail's job, but possibly worser. > > Not worse. It does it as well, i've once been using it since it had > to work in an environment where some mails didn't have the From_ line > above, but rmail insists on it (for no good reason). You all do realize that our rmail sources come with sendmail: RCS file: /home/ncvs/src/bin/rmail/rmail.c,v Working file: rmail.c head: 1.6 branch: locks: strict access list: symbolic names: v8_6_12: 1.1.1.1 And if you have problems with rmail they should be sent to Eric... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Sep 21 14:38:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA29914 for current-outgoing; Thu, 21 Sep 1995 14:38:46 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA29905 ; Thu, 21 Sep 1995 14:38:42 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id RAA27504; Thu, 21 Sep 1995 17:44:11 -0400 Date: Thu, 21 Sep 1995 17:44:11 -0400 (EDT) From: Nathan Stratton To: questions@freebsd.org cc: current@freebsd.org Subject: IP accounting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk I have just set up a FreeBSD box as one of my backbone routers and it works great. I was using linux and it crashed with about 100 routes. But FreeBSD is working with no load and 30 K routes. My only problem is IP accounting I need to know many packets and kbs is going out of all my interfaces. Is there any software that will do this? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Thu Sep 21 15:11:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01264 for current-outgoing; Thu, 21 Sep 1995 15:11:13 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA01258 ; Thu, 21 Sep 1995 15:11:09 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA28851; Thu, 21 Sep 1995 17:10:04 -0500 From: Joe Greco Message-Id: <199509212210.RAA28851@brasil.moneng.mei.com> Subject: Re: IP accounting To: nathan@netrail.net (Nathan Stratton) Date: Thu, 21 Sep 1995 17:10:03 -0500 (CDT) Cc: questions@freebsd.org, current@freebsd.org In-Reply-To: from "Nathan Stratton" at Sep 21, 95 05:44:11 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > I have just set up a FreeBSD box as one of my backbone routers and it > works great. I was using linux and it crashed with about 100 routes. But > FreeBSD is working with no load and 30 K routes. > > My only problem is IP accounting I need to know many packets and kbs is > going out of all my interfaces. Is there any software that will do this? Look at IP Firewall (options IPFW in your kernel), there is plenty of support for that. :-) I keep fairly detailed stats myself. ... JG From owner-freebsd-current Thu Sep 21 15:15:50 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01455 for current-outgoing; Thu, 21 Sep 1995 15:15:50 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA01433 ; Thu, 21 Sep 1995 15:15:44 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id SAA28874; Thu, 21 Sep 1995 18:21:25 -0400 Date: Thu, 21 Sep 1995 18:21:24 -0400 (EDT) From: Nathan Stratton To: Joe Greco cc: questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-Reply-To: <199509212210.RAA28851@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Thu, 21 Sep 1995, Joe Greco wrote: > > I have just set up a FreeBSD box as one of my backbone routers and it > > works great. I was using linux and it crashed with about 100 routes. But > > FreeBSD is working with no load and 30 K routes. > > > > My only problem is IP accounting I need to know many packets and kbs is > > going out of all my interfaces. Is there any software that will do this? > > Look at IP Firewall (options IPFW in your kernel), there is plenty of > support for that. :-) I keep fairly detailed stats myself. > > ... JG Is there docs on how to use this? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Thu Sep 21 15:19:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01685 for current-outgoing; Thu, 21 Sep 1995 15:19:05 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA01664 ; Thu, 21 Sep 1995 15:18:55 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id SAA28905; Thu, 21 Sep 1995 18:24:37 -0400 Date: Thu, 21 Sep 1995 18:24:36 -0400 (EDT) From: Nathan Stratton To: Joe Greco cc: questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-Reply-To: <199509212210.RAA28851@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Thu, 21 Sep 1995, Joe Greco wrote: > > I have just set up a FreeBSD box as one of my backbone routers and it > > works great. I was using linux and it crashed with about 100 routes. But > > FreeBSD is working with no load and 30 K routes. > > > > My only problem is IP accounting I need to know many packets and kbs is > > going out of all my interfaces. Is there any software that will do this? > > Look at IP Firewall (options IPFW in your kernel), there is plenty of > support for that. :-) I keep fairly detailed stats myself. > I looked at options.info and options.doc and don't see IPFW. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Thu Sep 21 16:44:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA04170 for current-outgoing; Thu, 21 Sep 1995 16:44:55 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA04145 ; Thu, 21 Sep 1995 16:44:51 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id QAA02582 ; Thu, 21 Sep 1995 16:44:27 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id AAA03113 ; Fri, 22 Sep 1995 00:38:13 +0100 To: Nathan Stratton cc: questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-reply-to: Your message of "Thu, 21 Sep 1995 17:44:11 EDT." Date: Fri, 22 Sep 1995 00:38:11 +0100 Message-ID: <3111.811726691@palmer.demon.co.uk> From: Gary Palmer Sender: owner-current@freebsd.org Precedence: bulk In message , Nathan Strat ton writes: >My only problem is IP accounting I need to know many packets and kbs is >going out of all my interfaces. Is there any software that will do this? netstat -i will tell you packet volumes per interface. If you look at `man ipfw', and /sys/i386/conf/LINT for details of how to enable it, you can get more detailed reports. As for kilobytes/interface, I dunno if that's possible without using some sort of packet sniffer. Gary From owner-freebsd-current Thu Sep 21 17:05:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA05573 for current-outgoing; Thu, 21 Sep 1995 17:05:28 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA05566 ; Thu, 21 Sep 1995 17:05:25 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id RAA00957; Thu, 21 Sep 1995 17:03:38 -0700 From: "Rodney W. Grimes" Message-Id: <199509220003.RAA00957@GndRsh.aac.dev.com> Subject: Re: IP accounting To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 21 Sep 1995 17:03:38 -0700 (PDT) Cc: nathan@netrail.net, questions@freebsd.org, current@freebsd.org In-Reply-To: <199509212210.RAA28851@brasil.moneng.mei.com> from "Joe Greco" at Sep 21, 95 05:10:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 785 Sender: owner-current@freebsd.org Precedence: bulk > > > I have just set up a FreeBSD box as one of my backbone routers and it > > works great. I was using linux and it crashed with about 100 routes. But > > FreeBSD is working with no load and 30 K routes. > > > > My only problem is IP accounting I need to know many packets and kbs is > > going out of all my interfaces. Is there any software that will do this? > > Look at IP Firewall (options IPFW in your kernel), there is plenty of > support for that. :-) I keep fairly detailed stats myself. Correct option is: # IPACCT enables IP accounting. options IPACCT #ipaccounting > > ... JG > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Sep 21 17:07:37 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA05919 for current-outgoing; Thu, 21 Sep 1995 17:07:37 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA05909 for ; Thu, 21 Sep 1995 17:07:34 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id RAA00791 for ; Thu, 21 Sep 1995 17:06:17 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id RAA00158 for ; Thu, 21 Sep 1995 17:08:43 -0700 Message-Id: <199509220008.RAA00158@corbin.Root.COM> To: current@freebsd.org Subject: sig 10/11 problems From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 21 Sep 1995 17:08:43 -0700 Sender: owner-current@freebsd.org Precedence: bulk I just committed to CVS a work-around for the sig 10/11 problems that people have been having for the past 3 weeks. It should be available to SUP in about 4 hours (9pm PDT). -DG From owner-freebsd-current Thu Sep 21 17:11:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA06083 for current-outgoing; Thu, 21 Sep 1995 17:11:05 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA06077 ; Thu, 21 Sep 1995 17:11:01 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id RAA00992; Thu, 21 Sep 1995 17:07:03 -0700 From: "Rodney W. Grimes" Message-Id: <199509220007.RAA00992@GndRsh.aac.dev.com> Subject: Re: IP accounting To: gary@palmer.demon.co.uk (Gary Palmer) Date: Thu, 21 Sep 1995 17:07:03 -0700 (PDT) Cc: nathan@netrail.net, questions@freebsd.org, current@freebsd.org In-Reply-To: <3111.811726691@palmer.demon.co.uk> from "Gary Palmer" at Sep 22, 95 00:38:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1208 Sender: owner-current@freebsd.org Precedence: bulk > > In message , Nathan Strat > ton writes: > >My only problem is IP accounting I need to know many packets and kbs is > >going out of all my interfaces. Is there any software that will do this? > > netstat -i will tell you packet volumes per interface. If you look at > `man ipfw', and /sys/i386/conf/LINT for details of how to enable it, > you can get more detailed reports. > > As for kilobytes/interface, I dunno if that's possible without using > some sort of packet sniffer. See /usr/include/net/if.h: struct ifnet { ... u_long ifi_oerrors; /* output errors on interface */ u_long ifi_collisions; /* collisions on csma interfaces */ u_long ifi_ibytes; /* total number of octets received */ u_long ifi_obytes; /* total number of octets sent */ u_long ifi_imcasts; /* packets received via multicast */ u_long ifi_omcasts; /* packets sent via multicast */ -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Sep 21 18:21:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA07917 for current-outgoing; Thu, 21 Sep 1995 18:21:40 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA07912 for ; Thu, 21 Sep 1995 18:21:37 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA27331; Thu, 21 Sep 1995 18:19:46 -0700 From: Terry Lambert Message-Id: <199509220119.SAA27331@phaeton.artisoft.com> Subject: Re: sig 10/11 problems To: davidg@root.com Date: Thu, 21 Sep 1995 18:19:46 -0700 (MST) Cc: current@FreeBSD.ORG In-Reply-To: <199509220008.RAA00158@corbin.Root.COM> from "David Greenman" at Sep 21, 95 05:08:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 422 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > I just committed to CVS a work-around for the sig 10/11 problems that > people have been having for the past 3 weeks. It should be available to SUP > in about 4 hours (9pm PDT). What is the identity of the problem? How does the workaround operate? You are too cool. 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 Sep 21 18:46:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA08515 for current-outgoing; Thu, 21 Sep 1995 18:46:04 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA08496 ; Thu, 21 Sep 1995 18:45:57 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id VAA02900; Thu, 21 Sep 1995 21:45:31 -0400 Date: Thu, 21 Sep 1995 21:45:31 -0400 (EDT) From: Nathan Stratton To: Gary Palmer cc: questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-Reply-To: <3111.811726691@palmer.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Fri, 22 Sep 1995, Gary Palmer wrote: > In message , Nathan Strat > ton writes: > >My only problem is IP accounting I need to know many packets and kbs is > >going out of all my interfaces. Is there any software that will do this? > > netstat -i will tell you packet volumes per interface. If you look at > `man ipfw', and /sys/i386/conf/LINT for details of how to enable it, > you can get more detailed reports. > Ok I added IP accounting and firewalling and now it will not compile. -I../.. -I../../sys -I../../../include -DLOCAL -DI586_CPU -DI486_CPU -DUCONSOLE -DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DMSDOSFS -DNFS -DFFS -DET_CISCO_HDLC -DIPACCT -DIPFIREWALL_VERBOSE -DIPFIREWALL -DGATEWAY -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../netinet/ip_fwdef.c cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -nostdinc -I. -I../.. -I../../sys -I../../../include -DLOCAL -DI586_CPU -DI486_CPU -DUCONSOLE -DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DMSDOSFS -DNFS -DFFS -DET_CISCO_HDLC -DIPACCT -DIPFIREWALL_VERBOSE -DIPFIREWALL -DGATEWAY -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../netinet/ip_fw.c In file included from ../../netinet/ip_fw.c:41: ../../../include/arpa/inet.h:50: warning: redundant redeclaration of `inet_ntoa' in same scope ../../netinet/in.h:257: warning: previous declaration of `inet_ntoa' cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -nostdinc -I. -I../.. -I../../sys -I../../../include -DLOCAL -DI586_CPU -DI486_CPU -DUCONSOLE -DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DMSDOSFS -DNFS -DFFS -DET_CISCO_HDLC -DIPACCT -DIPFIREWALL_VERBOSE -DIPFIREWALL -DGATEWAY -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../netinet/tcp_input.c Killed *** Error code 137 Stop. nr-dc-1# Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Thu Sep 21 18:55:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA08997 for current-outgoing; Thu, 21 Sep 1995 18:55:00 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA08980 ; Thu, 21 Sep 1995 18:54:49 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id CAA03653 ; Fri, 22 Sep 1995 02:54:08 +0100 To: Nathan Stratton cc: questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-reply-to: Your message of "Thu, 21 Sep 1995 21:45:31 EDT." Date: Fri, 22 Sep 1995 02:54:07 +0100 Message-ID: <3651.811734847@palmer.demon.co.uk> From: Gary Palmer Sender: owner-current@freebsd.org Precedence: bulk In message , Nathan Stratt on writes: >On Fri, 22 Sep 1995, Gary Palmer wrote: >cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit >-nostdinc -I. >-I../.. -I../../sys -I../../../include -DLOCAL -DI586_CPU -DI486_CPU >-DUCONSOLE >-DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DMSDOSFS -DNFS >-DFFS -DET_CISCO_HDLC -DIPACCT -DIPFIREWALL_VERBOSE -DIPFIREWALL >-DGATEWAY -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 >../../netinet/ip_fw.c >In file included from ../../netinet/ip_fw.c:41: >../../../include/arpa/inet.h:50: warning: redundant redeclaration of >`inet_ntoa' in same scope >../../netinet/in.h:257: warning: previous declaration of `inet_ntoa' This isn't an error. >cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit >-nostdinc -I. >-I../.. -I../../sys -I../../../include -DLOCAL -DI586_CPU -DI486_CPU >-DUCONSOLE >-DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DMSDOSFS -DNFS >-DFFS -DET_CISCO_HDLC -DIPACCT -DIPFIREWALL_VERBOSE -DIPFIREWALL >-DGATEWAY -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 >../../netinet/tcp_input.c >Killed >*** Error code 137 Did you manually kill it or did it die? I've never seen that happen. Are you running -current perchance? :-) Gary From owner-freebsd-current Thu Sep 21 19:20:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA10174 for current-outgoing; Thu, 21 Sep 1995 19:20:07 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA10149 for ; Thu, 21 Sep 1995 19:20:01 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id TAA01015; Thu, 21 Sep 1995 19:18:43 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id TAA00233; Thu, 21 Sep 1995 19:21:09 -0700 Message-Id: <199509220221.TAA00233@corbin.Root.COM> To: Terry Lambert cc: current@freebsd.org Subject: Re: sig 10/11 problems In-reply-to: Your message of "Thu, 21 Sep 95 18:19:46 PDT." <199509220119.SAA27331@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 21 Sep 1995 19:21:09 -0700 Sender: owner-current@freebsd.org Precedence: bulk >> I just committed to CVS a work-around for the sig 10/11 problems that >> people have been having for the past 3 weeks. It should be available to SUP >> in about 4 hours (9pm PDT). > >What is the identity of the problem? > >How does the workaround operate? There is a problem in vfs_cluster.c that is messing up the paging I/O. The exact problem isn't yet known (if it were, I would have committed a real fix rather than the workaround). I think the problem has to do with the use of "pbuf"s (these are struct buf's with pre-allocated kernel virtual address space). They are used both by the (vfs) cluster code to do cluster file I/O and by the VM system to do paging I/O. I think the 64K virtual space that is allotted to each buffer is being overrun in some cases, clobbering the pbuf VA space that follows. This could result in all sorts of interesting things, like I/O getting done to wrong pages (or not at all to others). Of course, this might not be the problem - but whatever it is, it is definately in vfs_cluster.c. The workaround is to simply disable file read clustering. This escentially causes the reads to degrade to the behavior that existed in FreeBSD 1.x as well as other versions of "Unix". The other fix (the "long" version) is to replace the cluster code with the code before John's recent rewrite of it - this also gets rid of the sig 10/11 problems. The reason it took so long to find this is that the changes to vfs_cluster.c have really nothing to do with the VM system changes that John made, and the symptoms are clearly VM system related. vfs_cluster.c is not used to do page- ins; clustering in the VM system happens using a different scheme that is better tailored for that type of I/O. >You are too cool. 8-). :-) -DG From owner-freebsd-current Thu Sep 21 19:46:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA11142 for current-outgoing; Thu, 21 Sep 1995 19:46:28 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA11135 ; Thu, 21 Sep 1995 19:46:21 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id TAA01663; Thu, 21 Sep 1995 19:46:19 -0700 Date: Thu, 21 Sep 1995 19:46:19 -0700 Message-Id: <199509220246.TAA01663@silvia.HIP.Berkeley.EDU> To: wollman@freebsd.org CC: current@freebsd.org Subject: duplicate entry in tcp_var.h From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk Garret, seems like you added something that was already there (there's already one in line 242). By the way, can you test-compile before you commit, please? Satoshi ------- In file included from ../../netinet/in_proto.c:60: ../../netinet/tcp_var.h:289: duplicate member `tcps_persistdrop' *** Error code 1 Stop. From owner-freebsd-current Thu Sep 21 20:11:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA12205 for current-outgoing; Thu, 21 Sep 1995 20:11:17 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA12190 for ; Thu, 21 Sep 1995 20:11:13 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id UAA00641; Thu, 21 Sep 1995 20:11:03 -0700 Date: Thu, 21 Sep 1995 20:11:03 -0700 Message-Id: <199509220311.UAA00641@silvia.HIP.Berkeley.EDU> To: davidg@Root.COM CC: current@freebsd.org In-reply-to: <199509220008.RAA00158@corbin.Root.COM> (message from David Greenman on Thu, 21 Sep 1995 17:08:43 -0700) Subject: Re: sig 10/11 problems From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * I just committed to CVS a work-around for the sig 10/11 problems that * people have been having for the past 3 weeks. It should be available to SUP * in about 4 hours (9pm PDT). I grabbed it off the cvs tree and recompiled the -current kernel but the symptoms (sig 10/11 for X programs) are still the same for me.... ;< Satoshi From owner-freebsd-current Thu Sep 21 20:38:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA13036 for current-outgoing; Thu, 21 Sep 1995 20:38:58 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA13021 ; Thu, 21 Sep 1995 20:38:50 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id XAA06263; Thu, 21 Sep 1995 23:38:46 -0400 Date: Thu, 21 Sep 1995 23:38:45 -0400 (EDT) From: Nathan Stratton To: Gary Palmer cc: questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-Reply-To: <3651.811734847@palmer.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Fri, 22 Sep 1995, Gary Palmer wrote: > >-DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DMSDOSFS -DNFS > >-DFFS -DET_CISCO_HDLC -DIPACCT -DIPFIREWALL_VERBOSE -DIPFIREWALL > >-DGATEWAY -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 > >../../netinet/tcp_input.c > >Killed > >*** Error code 137 > > Did you manually kill it or did it die? I've never seen that > happen. Are you running -current perchance? :-) I am so sorry, I am new to FreeBSD but that wes dumb. I have 24 megs or ram and 16 meg swap. This box is doing full BGP4 peering with sprint +30,000 routes. And then I decide to compile a kernel. That will kill any compile with that little ram. :-( Sorry. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Thu Sep 21 22:07:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA15348 for current-outgoing; Thu, 21 Sep 1995 22:07:51 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA15343 for ; Thu, 21 Sep 1995 22:07:47 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id WAA01210; Thu, 21 Sep 1995 22:06:29 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id WAA00368; Thu, 21 Sep 1995 22:08:55 -0700 Message-Id: <199509220508.WAA00368@corbin.Root.COM> To: asami@cs.berkeley.edu (Satoshi Asami) cc: current@freebsd.org Subject: Re: sig 10/11 problems In-reply-to: Your message of "Thu, 21 Sep 95 20:11:03 PDT." <199509220311.UAA00641@silvia.HIP.Berkeley.EDU> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 21 Sep 1995 22:08:55 -0700 Sender: owner-current@freebsd.org Precedence: bulk > * I just committed to CVS a work-around for the sig 10/11 problems that > * people have been having for the past 3 weeks. It should be available to SUP > * in about 4 hours (9pm PDT). > >I grabbed it off the cvs tree and recompiled the -current kernel but >the symptoms (sig 10/11 for X programs) are still the same for >me.... ;< Is the problem you're having with specific binaries, and does it always fail? I think you might have a corrupt binary and/or shared library. Except for a shell bug reported by Stephen Hocking, all of the reports I've gotten back have indicated that the patch has gotten rid off all of the sig 10/11 flakiness they were experiancing. Also, can you verify that the revision you're using of ffs_vnops.c is indeed 1.13, please? ...oh, and there were other bugs that have been fixed recently, I assume that you're running -current from within the past day or so? -DG From owner-freebsd-current Thu Sep 21 22:14:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA15562 for current-outgoing; Thu, 21 Sep 1995 22:14:34 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA15557 for ; Thu, 21 Sep 1995 22:14:31 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id WAA00765; Thu, 21 Sep 1995 22:14:26 -0700 Date: Thu, 21 Sep 1995 22:14:26 -0700 Message-Id: <199509220514.WAA00765@silvia.HIP.Berkeley.EDU> To: davidg@Root.COM CC: current@freebsd.org In-reply-to: <199509220508.WAA00368@corbin.Root.COM> (message from David Greenman on Thu, 21 Sep 1995 22:08:55 -0700) Subject: Re: sig 10/11 problems From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * Is the problem you're having with specific binaries, and does it always * fail? I think you might have a corrupt binary and/or shared library. Except * for a shell bug reported by Stephen Hocking, all of the reports I've gotten * back have indicated that the patch has gotten rid off all of the sig 10/11 * flakiness they were experiancing. They are all X programs, like xterm, xload, etc. When I start X, the screen goes gray (so the server is fine), waits there for a while and then comes back to the console with a whole bunch of messages and a bunch of *.core files. This is exactly what I was seeing before. Other programs (sed and stuff) have never failed for me. I don't think it's corrupt binaries and/or shared libraries, because the same -current system runs fine with an older kernel (dated 8/30) and also -stable (the X programs/libraries are shared). * Also, can you verify that the revision you're using of ffs_vnops.c is * indeed 1.13, please? ...oh, and there were other bugs that have been fixed * recently, I assume that you're running -current from within the past day or * so? I haven't done a "make world" since 9/16. The kernel source is as new as it can get, I supped the cvs tree and did a cvs update right before the kernel build (had to take out the one line that Garret duplicated though). Satoshi From owner-freebsd-current Thu Sep 21 23:10:43 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA16471 for current-outgoing; Thu, 21 Sep 1995 23:10:43 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA16466 for ; Thu, 21 Sep 1995 23:10:41 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id XAA01284; Thu, 21 Sep 1995 23:09:23 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id XAA00445; Thu, 21 Sep 1995 23:11:50 -0700 Message-Id: <199509220611.XAA00445@corbin.Root.COM> To: asami@cs.berkeley.edu (Satoshi Asami) cc: current@freebsd.org Subject: Re: sig 10/11 problems In-reply-to: Your message of "Thu, 21 Sep 95 22:14:26 PDT." <199509220514.WAA00765@silvia.HIP.Berkeley.EDU> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 21 Sep 1995 23:11:49 -0700 Sender: owner-current@freebsd.org Precedence: bulk > * Is the problem you're having with specific binaries, and does it always > * fail? I think you might have a corrupt binary and/or shared library. Except > * for a shell bug reported by Stephen Hocking, all of the reports I've gotten > * back have indicated that the patch has gotten rid off all of the sig 10/11 > * flakiness they were experiancing. > >They are all X programs, like xterm, xload, etc. When I start X, the >screen goes gray (so the server is fine), waits there for a while and >then comes back to the console with a whole bunch of messages and a >bunch of *.core files. > >This is exactly what I was seeing before. Other programs (sed and >stuff) have never failed for me. Sorry everyone...I changed the wrong 'doclusterread' in the file on freefall before I committed it. Thanks to Poul-Henning for telling me that the patch I sent him (which worked) and what I actually committed (bogus) were different! ...and thanks to Steven Wallace for trying to point out the mistake originally (you should be more assertive Steven! :-)). Okay, the _correct_ change is now committed (changing both cases of doclusterread just to be certain!)...this should be available from SUP in at about 3AM PDT. -DG From owner-freebsd-current Thu Sep 21 23:59:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA17652 for current-outgoing; Thu, 21 Sep 1995 23:59:34 -0700 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA17646 for ; Thu, 21 Sep 1995 23:59:23 -0700 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id OAA04530 for freebsd-current@freebsd.org; Fri, 22 Sep 1995 14:59:11 +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: 22 Sep 1995 14:59:06 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <43tmrq$4de$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199509211738.TAA16378@uriah.heep.sax.de>, <199509212123.OAA00831@GndRsh.aac.dev.com> Subject: Re: rmail and brain-dead mail systems .. patch enclosed Sender: owner-current@freebsd.org Precedence: bulk rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) writes: >> >> As Dmitry Kohmanyuk wrote: >> > >> > I also think sendmail can do the rmail's job, but possibly worser. >> >> Not worse. It does it as well, i've once been using it since it had >> to work in an environment where some mails didn't have the From_ line >> above, but rmail insists on it (for no good reason). >You all do realize that our rmail sources come with sendmail: >RCS file: /home/ncvs/src/bin/rmail/rmail.c,v >Working file: rmail.c >symbolic names: > v8_6_12: 1.1.1.1 >And if you have problems with rmail they should be sent to Eric... Yep, and he'll tell you exactly what he thinks of uucp/rmail/etc... :-) "UUCP is dead" is pretty much what he'll say... :-) Whether or not he's right is another matter... :-) Anyway, there **is** a very good reason for "^From " line, and a very good reason for insisting on it. Each item of mail has at least 4 addresses. The envelope sender, the envelope recipient, the "to:" line and the "from:" line. The envelope recipient is passed on the rmail command line, eg: "rmail foo!bar!baz". The envelope recipient is passed in the "From " line. Sendmail needs these addresses to correctly function when errors happen, otherwise you get horrible things happening like bounced messages going to entire mailing lists, or the sender of mail to a mailing list getting all the error messages etc etc. -Peter >-- >Rod Grimes rgrimes@gndrsh.aac.dev.com >Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Sep 22 00:49:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA19011 for current-outgoing; Fri, 22 Sep 1995 00:49:14 -0700 Received: from MediaCity.com (easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA19006 for ; Fri, 22 Sep 1995 00:49:12 -0700 Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id AAA02536 for freebsd-current@freebsd.org; Fri, 22 Sep 1995 00:49:17 -0700 From: Brian Litzinger Message-Id: <199509220749.AAA02536@MediaCity.com> Subject: -current no longer sees my PCI bus To: freebsd-current@freebsd.org Date: Fri, 22 Sep 1995 00:49:16 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Content-Length: 375 Sender: owner-current@freebsd.org Precedence: bulk -current as of a sup at Fri Sep 22 00:15:40 PDT 1995 (with manual patch for sig11 problem) no longer recognizes my PCI bus on my Intel P5-90 PCI machine. And hence doesn't see my adaptec 2940 controller. The same kernel works fine on a 486DX4/100 PCI machine w/2940. A late August -current recognizes the PCI bus on the P5-90 machine. Brian Litzinger brian@mediacity.com From owner-freebsd-current Fri Sep 22 02:37:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA22357 for current-outgoing; Fri, 22 Sep 1995 02:37:23 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA22348 for ; Fri, 22 Sep 1995 02:37:11 -0700 Received: by Sysiphos id AA25456 (5.67b/IDA-1.5 for current@freebsd.org); Fri, 22 Sep 1995 11:33:28 +0200 Message-Id: <199509220933.AA25456@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 22 Sep 1995 11:33:27 +0200 In-Reply-To: Brian Litzinger "-current no longer sees my PCI bus" (Sep 22, 0:49) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Brian Litzinger Subject: Re: -current no longer sees my PCI bus Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Sep 22, 0:49, Brian Litzinger wrote: } Subject: -current no longer sees my PCI bus } -current as of a sup at Fri Sep 22 00:15:40 PDT 1995 (with manual patch for } sig11 problem) no longer recognizes my PCI bus on my Intel P5-90 PCI } machine. And hence doesn't see my adaptec 2940 controller. The code probably reports a different configuration mechanism (1 vs. 2) than before. } The same kernel works fine on a 486DX4/100 PCI machine w/2940. The problem is very PCI chip set specific. } A late August -current recognizes the PCI bus on the P5-90 machine. There have been recent changes to correctly probe new Compaq machines, which fail the specs in such a way, that the probe code had to be rewritten. Sorry to hear, that it no longer works on your machine ... Could you please boot a -current kernel in "verbose" mode (i.e. "-v" at the boot prompt) and send the PCI specific output ? Thanks in advance, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Fri Sep 22 02:55:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA22864 for current-outgoing; Fri, 22 Sep 1995 02:55:16 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA22854 for ; Fri, 22 Sep 1995 02:55:09 -0700 Received: by Sysiphos id AA25886 (5.67b/IDA-1.5 for current@freebsd.org); Fri, 22 Sep 1995 11:54:54 +0200 Message-Id: <199509220954.AA25886@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 22 Sep 1995 11:54:54 +0200 In-Reply-To: Steven Wallace "pcibus.c setup failure" (Sep 21, 23:08) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Steven Wallace Subject: Re: pcibus.c setup failure Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Sep 21, 23:08, Steven Wallace wrote: } Subject: pcibus.c setup failure } } Your commit last week of version 1.14 in pcibus.c now makes my } pcibus_setup() fail for me, as it worked for version 1.12 and earlier. } } It is failing on the first "Configuration mode 1?" test when it should } pass. Before you sent out a 0xF0000000ul and result= 0xf0000000ul } which passed. Now you send out a 0xF0000001ul and result = 0xF0000001ul } which fails since it wants the lsb to be 0. To fix it, either change: } } #define CONF1_ENABLE_CHK1 0xF0000001ul to 0xF0000000ul, } #define CONF1_ENABLE_MSK1 0x80000001ul to 0x80000000ul, } OR } #define CONF1_ENABLE_RES1 0x80000000ul to 0x80000001ul } } I am not sure which one is the correct fix. } Hope you understand what the problem is and are able to commit the } correct fix from above. Well, that's another broken chip set then ... The PCI specs require a chip set to either ignore the word write to that address, or clear the least significant TWO bits. The Intel Neptun fails to do so, because it tries to emulate both config mechanism 1 and 2, which have contradictionary specs ... But I did expect it to at least force the LSBit to '0'. The test I used before broke on recent Compaq machines, which just ignored very clearly expressed requirements of the PCI specs. The code as written is intentional, since it tries to determine mich config mechanism to use (if there is any PCI bus chip found at all :). If I made the change you propose, then reading back a value of 0xffffffff would be interpreted as success, while it most probably means there was no device at all at that port address ... I'll look into this and send you a patch later today. Sorry for the inconvenience. Compaq admitted to not conform to the specs, but this won't help, since they propbably won't change their Triflex chip set ... :) Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Fri Sep 22 03:13:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA23802 for current-outgoing; Fri, 22 Sep 1995 03:13:17 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA23795 ; Fri, 22 Sep 1995 03:13:10 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id DAA21684; Fri, 22 Sep 1995 03:11:50 -0700 To: Gary Palmer cc: Nathan Stratton , questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-reply-to: Your message of "Fri, 22 Sep 1995 00:38:11 BST." <3111.811726691@palmer.demon.co.uk> Date: Fri, 22 Sep 1995 03:11:50 -0700 Message-ID: <21681.811764710@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > As for kilobytes/interface, I dunno if that's possible without using > some sort of packet sniffer. Couldn't you just use the output from `netstat -ib' in a slow loop to essentially approximate that functionality? I don't know what kind of granularity is required, but David was able to meter wcarchive's bytes/sec traffic fairly well by doing that repeatedly. Jordan From owner-freebsd-current Fri Sep 22 03:20:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA24095 for current-outgoing; Fri, 22 Sep 1995 03:20:49 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA24086 ; Fri, 22 Sep 1995 03:20:41 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id DAA21727; Fri, 22 Sep 1995 03:19:29 -0700 To: Nathan Stratton cc: Gary Palmer , questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-reply-to: Your message of "Thu, 21 Sep 1995 21:45:31 EDT." Date: Fri, 22 Sep 1995 03:19:28 -0700 Message-ID: <21725.811765168@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > -DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DMSDOSFS -DNFS > -DFFS -DET_CISCO_HDLC -DIPACCT -DIPFIREWALL_VERBOSE -DIPFIREWALL > -DGATEWAY -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 > ../../netinet/tcp_input.c > Killed > *** Error code 137 "Killed"?? This isn't a compile error. Did you run out of swap space? Are there any suspicious messages around this time in /var/log/messages? Jordan From owner-freebsd-current Fri Sep 22 03:28:19 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA24487 for current-outgoing; Fri, 22 Sep 1995 03:28:19 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA24452 ; Fri, 22 Sep 1995 03:28:01 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id DAA01763; Fri, 22 Sep 1995 03:26:42 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id DAA00162; Fri, 22 Sep 1995 03:29:09 -0700 Message-Id: <199509221029.DAA00162@corbin.Root.COM> To: "Jordan K. Hubbard" cc: Gary Palmer , Nathan Stratton , questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-reply-to: Your message of "Fri, 22 Sep 95 03:11:50 PDT." <21681.811764710@time.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 22 Sep 1995 03:29:07 -0700 Sender: owner-current@freebsd.org Precedence: bulk >> As for kilobytes/interface, I dunno if that's possible without using >> some sort of packet sniffer. > >Couldn't you just use the output from `netstat -ib' in a slow loop to >essentially approximate that functionality? I don't know what kind of >granularity is required, but David was able to meter wcarchive's >bytes/sec traffic fairly well by doing that repeatedly. Actually, I use 'netstat -I de0 -b -w 60', and then calculate the per-second average from each 60 second sample. -DG From owner-freebsd-current Fri Sep 22 04:35:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA26668 for current-outgoing; Fri, 22 Sep 1995 04:35:40 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id EAA26663 for ; Fri, 22 Sep 1995 04:35:34 -0700 Received: by Sysiphos id AA26962 (5.67b/IDA-1.5 for current@freebsd.org); Fri, 22 Sep 1995 13:32:44 +0200 Message-Id: <199509221132.AA26962@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 22 Sep 1995 13:32:43 +0200 In-Reply-To: Brian Litzinger "Re: -current no longer sees my PCI bus" (Sep 22, 4:08) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Brian Litzinger Subject: Re: -current no longer sees my PCI bus Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Sep 22, 4:08, Brian Litzinger wrote: } Subject: Re: -current no longer sees my PCI bus } > } The fix that Steve Wallace suggested works on my system too. } > It's obvious how to fix this for a single system, but I } > need a solution that works on ALL systems. } } how about } } option BROKEN_PCI_BUS_CHIP_DETECT_WHICH_UPSETS_STEFAN } } I'd be happy to put that in the config for my one old PCI system. Well, you'd be ... But how about those who just got an old PCI system from some flea market and have to install from CDROM without a choice to build a custom kernel ... I'll change the structure of the PCI probe code to first determine whether there appears to be ANY PCI support at all in the system. And thereafter, tests will follow to choose either config mechanism 1 or 2, as appropriate. (The current code tries to do all in one step.) I'll send you and all thos ethat reported problems with the PCI probe at any time before my diffs and hope they'll work and will then make it into the next 2.1-SNAP ... Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Fri Sep 22 05:06:50 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA27407 for current-outgoing; Fri, 22 Sep 1995 05:06:50 -0700 Received: from vanuata.dcs.gla.ac.uk (vanuata.dcs.gla.ac.uk [130.209.240.50]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA27393 for ; Fri, 22 Sep 1995 05:06:34 -0700 Message-Id: <199509221206.FAA27393@freefall.freebsd.org> Received: from seram.dcs.gla.ac.uk by vanuata.dcs.gla.ac.uk with LOCAL SMTP (PP); Fri, 22 Sep 1995 13:05:30 +0100 To: Wolfram Schneider cc: "Garrett A. Wollman" , current@freebsd.org Subject: Re: from(1) In-reply-to: Your message of "Thu, 21 Sep 1995 15:14:51 +0200." <199509211314.PAA05392@caramba.cs.tu-berlin.de> Date: Fri, 22 Sep 1995 13:05:21 +0100 From: Simon Marlow Sender: owner-current@freebsd.org Precedence: bulk Wolfram Schneider writes: > Garrett A. Wollman writes: > >< de> said: > > > >> - Option '-c' print a count of matching lines > > > >Use wc(1). > > > An option is better than a pipe I disagree entirely. The generality provided by pipes and pipe combinators far outweighs the slight performance gain by implementing the options directly. How many other programs are you going to add '-c' to? What about the programs where '-c' is already taken, and you have to use an inconsistent flag? In Un*x, to count lines, one uses wc(1). > a) in a perl script, a pipe force system to use sh -c > instead exec/fork If efficiency is that important, the Perl script should be counting the lines itself. This is trivial in Perl. > b) for aliases > > alias fb='from -tcs owner-freebsd-security' > > is simpler than [for bash] > fb () { > from -tcs owner-freebsd-security "$@" | wc -l > } > most people forget the "$@" A valid point, but this is a shell problem and not worth sacrificing the philosophy of an operating system for. Cheers, Simon -- Simon Marlow simonm@dcs.gla.ac.uk Research Assistant http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key From owner-freebsd-current Fri Sep 22 05:45:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA27983 for current-outgoing; Fri, 22 Sep 1995 05:45:03 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA27971 for ; Fri, 22 Sep 1995 05:45:00 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4) id AA24157; Fri, 22 Sep 1995 08:44:57 -0400 Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA04947; Fri, 22 Sep 95 08:42:16 EDT Date: Fri, 22 Sep 95 08:42:16 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9509221242.AA04947@borg.ess.harris.com> To: davidg@root.com Subject: Re: sig 10/11 problems Cc: current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG Precedence: bulk I have been testing a patch from david since yesterday morning (compiles, make world, etc) and I have not seen the problem so the patch is either working or has moved the problem :-) Sorry it took a while to test but I wanted to try 2 make worlds at 7 hours each. It may help if people with 16Meg machines try it because I noticed that the problem was more frequent with 16M than 32M. Jim Leppek > From owner-freebsd-current@freefall.freebsd.org Thu Sep 21 21:21:07 1995 > From: Terry Lambert > Subject: Re: sig 10/11 problems > To: davidg@root.com > Date: Thu, 21 Sep 1995 18:19:46 -0700 (MST) > Cc: current@FreeBSD.ORG > 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 > > > > > I just committed to CVS a work-around for the sig 10/11 problems that > > people have been having for the past 3 weeks. It should be available to SUP > > in about 4 hours (9pm PDT). > > What is the identity of the problem? > > How does the workaround operate? > > You are too cool. 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 Fri Sep 22 05:49:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA28069 for current-outgoing; Fri, 22 Sep 1995 05:49:22 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA28063 ; Fri, 22 Sep 1995 05:49:19 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id FAA27600; Fri, 22 Sep 1995 05:49:03 -0700 Date: Fri, 22 Sep 1995 05:49:03 -0700 Message-Id: <199509221249.FAA27600@silvia.HIP.Berkeley.EDU> To: nate@rocky.sri.MT.net CC: roberto@keltia.Freenix.FR, nate@rocky.sri.MT.net, freebsd-current@FreeBSD.org, rich@FreeBSD.org In-reply-to: <199509211659.KAA02299@rocky.sri.MT.net> (message from Nate Williams on Thu, 21 Sep 1995 10:59:18 -0600) Subject: Re: XFree86 and the new malloc From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.org Precedence: bulk Don't know if Rich is listening to -current, so let me comment on this. * Basically, the stock BSD malloc caused a number of programs to be less * useful than they were if compiled against GNU malloc. The largest (literally) example was the X server. My 3.1.1 XF86_S3 in 16-bit mode routinely grew over 20MB and it was, um, very annoying, to say the least. With gnumalloc, it rarely goes over 10MB. Ditto for xv. With the old libc malloc, there really wasn't much choice but to use gnumalloc. We'll have to test how phkmalloc works, and see what we should recommend them for 3.1.3 (or 3.2?). I'm going to compile the X server with phkmalloc tomorrow (I'm doing a make world now) and let you guys know if something goes "puff" or "bloat". Satoshi From owner-freebsd-current Fri Sep 22 05:59:09 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA28333 for current-outgoing; Fri, 22 Sep 1995 05:59:09 -0700 Received: from alpha.netcraft.co.uk ([194.72.238.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA28318 ; Fri, 22 Sep 1995 05:59:05 -0700 Received: (from paul@localhost) by alpha.netcraft.co.uk (8.6.11/8.6.9) id NAA07347; Fri, 22 Sep 1995 13:56:25 +0100 From: Paul Richards Message-Id: <199509221256.NAA07347@alpha.netcraft.co.uk> Subject: Re: IP accounting To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 22 Sep 1995 13:56:25 +0100 (BST) Cc: gary@palmer.demon.co.uk, nathan@netrail.net, questions@FreeBSD.org, current@FreeBSD.org In-Reply-To: <21681.811764710@time.cdrom.com> from "Jordan K. Hubbard" at Sep 22, 95 03:11:50 am Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 928 Sender: owner-current@FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who said > > > As for kilobytes/interface, I dunno if that's possible without using > > some sort of packet sniffer. > > Couldn't you just use the output from `netstat -ib' in a slow loop to > essentially approximate that functionality? I don't know what kind of > granularity is required, but David was able to meter wcarchive's > bytes/sec traffic fairly well by doing that repeatedly. ipfw accounting gives the stats you need. If we ditch ipfw (and I tend to be in favour) then I really hope we can retain accurate ip traffic accounting because that's essential to the way we use it on our boxes. Netstat simply doesn't do the job since it measures traffic per interface and I have a number of virtual hosts and need traffic per ip address. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Fri Sep 22 06:17:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA29608 for current-outgoing; Fri, 22 Sep 1995 06:17:40 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA29600 for ; Fri, 22 Sep 1995 06:17:29 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA07515; Fri, 22 Sep 1995 23:13:37 +1000 Date: Fri, 22 Sep 1995 23:13:37 +1000 From: Bruce Evans Message-Id: <199509221313.XAA07515@godzilla.zeta.org.au> To: current@FreeBSD.org, josh@American.COM, vak@cronyx.ru Subject: Re: more ATAPI CD issues Sender: owner-current@FreeBSD.org Precedence: bulk >> First, the current layering of wd.c is obviously not well suited to this >> configuration. Your ATAPI controller has to react a certain way to particular >> ATA commands to get to the point of being probed at all as an ATAPI CD. The 3 >> trials of ATA you must pass are 1) writable byte count / cyl. address >> registers, 2) successful wdreset(), and 3) successful WDCC_DIAGNOSE behavior. >> >> The first test is reasonable, for what its worth. >This test could fail for single-drive configurations. >The driver does not set the drive unit number to 0 before testing >the cylinder register. If the BIOS leaves it set to 1, then the test >will fail... I tried toggling the drive select bit (in a debugger with interrupts off) on a single-drive IDE system and the test continued to work. The status register changed from 0x50 to 0x00 (0x00 for the nonexistent drive) and the cyl_lo register held values written to it. The altsts register did not change from 0xf0. Has EIDE changed the required behaviour here? Bruce From owner-freebsd-current Fri Sep 22 06:18:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA29661 for current-outgoing; Fri, 22 Sep 1995 06:18:11 -0700 Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA29655 ; Fri, 22 Sep 1995 06:18:07 -0700 Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id GAA04416; Fri, 22 Sep 1995 06:15:54 -0700 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami) cc: nate@rocky.sri.MT.net, roberto@keltia.Freenix.FR, freebsd-current@FreeBSD.org, rich@FreeBSD.org Subject: Re: XFree86 and the new malloc In-reply-to: Your message of "Fri, 22 Sep 1995 05:49:03 PDT." <199509221249.FAA27600@silvia.HIP.Berkeley.EDU> Date: Fri, 22 Sep 1995 06:15:48 -0700 Message-ID: <4412.811775748@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk > We'll have to test how phkmalloc works, and see what we should > recommend them for 3.1.3 (or 3.2?). I'm going to compile the X server > with phkmalloc tomorrow (I'm doing a make world now) and let you guys > know if something goes "puff" or "bloat". Just for the record: I'm VERY interested in numbers and data, but I'm also very interested in the subjective "how does it feel" reports, since that one number we really want isn't that easy to find: "current working set size in pages". The only semi-reliable way we have to measure this is on the paging- rate, not the amount paged, but the number of pages/sec or something. (This is, by a staggering coincidence, also why the app feels slow :-) If you run something with phkmalloc sufficiently long that you think it won't blow up on you, try #undef'ing EXTRA_SANITY and possibly SANITY as well in phkmalloc, and try again, that should give even better speed, at the expense of sanity-checks. EXTRA_SANITY is rather expensive, but checks for a lot of internal inconsistencies in phkmalloc, I expect that to be removed after a sufficient amount of testing has been done. SANITY checks the sanity of how the application calls phkmalloc. I expect this to be a standard compile option, since the results of leaving it out in a program which screws up is very confusing. I have a couple of ideas which could make phkmalloc better at freeing memory back to the OS (as opposed to just not accessing it) but I will not touch it for another couple of weeks I expect, and it will need a pretty tough bashing on my own boxes first before it gets committed. I will be most grateful if somebody will do a full-scale code-review too. Your testing is most appreciated... -- 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. It will be some time yet before progress goes to far... (Poul Henningsen) From owner-freebsd-current Fri Sep 22 06:34:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01198 for current-outgoing; Fri, 22 Sep 1995 06:34:05 -0700 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01187 for ; Fri, 22 Sep 1995 06:33:22 -0700 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.144.4]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id PAA28880; Fri, 22 Sep 1995 15:13:32 +0200 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id PAA25411; Fri, 22 Sep 1995 15:13:25 +0200 Date: Fri, 22 Sep 1995 15:13:25 +0200 Message-Id: <199509221313.PAA25411@caramba.cs.tu-berlin.de> To: Simon Marlow Cc: "Garrett A. Wollman" , current@freebsd.org Subject: Re: from(1) In-Reply-To: <199509221205.OAA27478@mail.cs.tu-berlin.de> References: <199509211314.PAA05392@caramba.cs.tu-berlin.de> <199509221205.OAA27478@mail.cs.tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org Precedence: bulk Simon Marlow writes: >I disagree entirely. The generality provided by pipes and pipe >combinators far outweighs the slight performance gain by implementing >the options directly. How many other programs are you going to add >'-c' to? What about the programs where '-c' is already taken, and you >have to use an inconsistent flag? grep have already '-c'. I add -c to locate. It is a real difference between 13MB I/O or 115MB. >A valid point, but this is a shell problem and not worth sacrificing >the philosophy of an operating system for. ^philosophy^religion Do you want remove 'z' flag from tar because $ tar cfvz - files ... > x.tgz break old unix philosophy? From owner-freebsd-current Fri Sep 22 06:45:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01467 for current-outgoing; Fri, 22 Sep 1995 06:45:51 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01461 for ; Fri, 22 Sep 1995 06:45:49 -0700 Received: from id.slip.bcm.tmc.edu (hou08.onramp.net [199.1.137.136]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id GAA07556 for ; Fri, 22 Sep 1995 06:45:37 -0700 Received: (from rich@localhost) by id.slip.bcm.tmc.edu (8.6.12/8.6.9) id IAA04437; Fri, 22 Sep 1995 08:40:13 -0500 Date: Fri, 22 Sep 1995 08:40:13 -0500 From: Rich Murphey Message-Id: <199509221340.IAA04437@id.slip.bcm.tmc.edu> To: asami@cs.berkeley.edu CC: nate@rocky.sri.MT.net, roberto@keltia.Freenix.FR, nate@rocky.sri.MT.net, freebsd-current@FreeBSD.org In-reply-to: <199509221249.FAA27600@silvia.HIP.Berkeley.EDU> (asami@cs.berkeley.edu) Subject: Re: XFree86 and the new malloc Reply-to: rich@lamprey.utmb.edu Sender: owner-current@FreeBSD.org Precedence: bulk |From: asami@cs.berkeley.edu (Satoshi Asami) | |Don't know if Rich is listening to -current, so let me comment on this. | | * Basically, the stock BSD malloc caused a number of programs to be less | * useful than they were if compiled against GNU malloc. |The largest (literally) example was the X server. My 3.1.1 XF86_S3 in |16-bit mode routinely grew over 20MB and it was, um, very annoying, to |say the least. With gnumalloc, it rarely goes over 10MB. Ditto for |xv. With the old libc malloc, there really wasn't much choice but to |use gnumalloc. Looking back.. In XFree86 2.x there were reports of -lgnumalloc breaking the server, but these have long since been fixed so that -lgnumalloc is what is used now in XFree86 3.1.x. In 3.0 we still used -lmalloc becuse it was faster than -lgnumalloc on smaller allocations and equally fast on large allocations. But there was strong interest in saving memory using gnumalloc and the switch was made after 3.0. Caveat: If you exit the clients in a FIFO order, the system get's all the memory back, but otherwise gnumalloc leaves holes which are't returned. |We'll have to test how phkmalloc works, and see what we should |recommend them for 3.1.3 (or 3.2?). I'm going to compile the X server |with phkmalloc tomorrow (I'm doing a make world now) and let you guys |know if something goes "puff" or "bloat". OK, I'll start building XFree86 alphas and betas with phkmalloc as well. If there are no complaints we can make it the default for XFree86. Rich From owner-freebsd-current Fri Sep 22 06:51:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01716 for current-outgoing; Fri, 22 Sep 1995 06:51:25 -0700 Received: from id.slip.bcm.tmc.edu (root@hou08.onramp.net [199.1.137.136]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01704 for ; Fri, 22 Sep 1995 06:51:21 -0700 Received: (from rich@localhost) by id.slip.bcm.tmc.edu (8.6.12/8.6.9) id IAA04468; Fri, 22 Sep 1995 08:48:33 -0500 Date: Fri, 22 Sep 1995 08:48:33 -0500 From: Rich Murphey Message-Id: <199509221348.IAA04468@id.slip.bcm.tmc.edu> To: bde@zeta.org.au CC: freebsd-current@FreeBSD.org, roberto@keltia.Freenix.FR In-reply-to: <199509210528.PAA29710@godzilla.zeta.org.au> (message from Bruce Evans on Thu, 21 Sep 1995 15:28:36 +1000) Subject: Re: XFree86 and the new malloc Reply-to: rich@lamprey.utmb.edu Sender: owner-current@FreeBSD.org Precedence: bulk |From: Bruce Evans | |>Has anyone tried to link the X server with the new libc's malloc from |>Poul-Henning ? | |It's already linked to libc's malloc unless you have a version that is |linked to a nonstandard libmalloc. This is one of the main advantages |(?) of not putting phkmalloc in a special library that almost no one |will use. It also shows why third party programs should not use |nonstandard libraries to avoid problems in standard libaries. Hey, wait a sec. XFree86 3.1.2 does use -lgnumalloc. We had been testing it but only switched when it passed all the alpha/beta tests, and that happened after 3.0 came out. Rich From owner-freebsd-current Fri Sep 22 06:53:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01938 for current-outgoing; Fri, 22 Sep 1995 06:53:46 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01931 for current@freebsd.org; Fri, 22 Sep 1995 06:53:44 -0700 Date: Fri, 22 Sep 1995 06:53:44 -0700 From: John Dyson Message-Id: <199509221353.GAA01931@freefall.freebsd.org> To: current@freebsd.org Subject: The Sig-11/10 saga & Thanks DG!!! Sender: owner-current@freebsd.org Precedence: bulk David has come up with a work-around, and last night (at about 4:00 AM my time) finally I found my bug. The bug was NOT in the new VFS layered GETPAGES routine where I kept looking :-(, but in some of the mods to the clustering code for EXT2FS!!! In hindsight, the code was pathetically broken, but could not see it. I am going to wait until at least 16:00 EST to commit the fix (and another one that DG found in the ufs_bmap code from Lite and Lite-2) so that everyone can grab a working system. The work-around does impact read perf significantly, but of course that is better than Sig-11s all over the place :-). The performance with the complete fix will be better again. I am so glad that DG pointed me in the right direction on this problem, otherwise I would have spent more time spinning my wheels!!! Thanks David!!! Also, look forward to the fix being commited today... I'll email to -current when it happens.... Now, I get to sleep tonight... John dyson@freebsd.org From owner-freebsd-current Fri Sep 22 06:58:37 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA03290 for current-outgoing; Fri, 22 Sep 1995 06:58:37 -0700 Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.35.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA03285 for ; Fri, 22 Sep 1995 06:58:35 -0700 Received: (from james@localhost) by miller.cs.uwm.edu (8.6.10/8.6.10) id IAA06648 for current@freebsd.org; Fri, 22 Sep 1995 08:58:33 -0500 Date: Fri, 22 Sep 1995 08:58:33 -0500 From: Jim Lowe Message-Id: <199509221358.IAA06648@miller.cs.uwm.edu> To: current@freebsd.org Subject: -current and PCI probs Sender: owner-current@freebsd.org Precedence: bulk Since the core dumping problem seemed to be fixed, I supped up a new kernel and compiled it. The new kernel not longer finds my pci bus. The motherboard I am using is a SuperMicro with the Triton Chip set. Unfortunatly, I removed the kernel I was running yesterday by mistake. I now have the system up, but many things don't work correctly -- I am running a kernel that is *real* old now (I think it might be a 2.0.5 kernel). I booted the old kernel with a -v (pci info attached). Stefan, if you need someone to test the new pci changes I will certainly be more than happy to do so :-). -Jim ------------- Probing for devices on the pci0 bus: configuration mode 1 allows 32 devices. pci0:0: INTEL CORPORATION, device=0x122d, class=bridge [not supported] pci0:7: INTEL CORPORATION, device=0x122e, class=bridge [not supported] vga0 rev 0 on pci0:17 pci0:18: INTEL CORPORATION, device=0x1223, class=multimedia [not supported] map(10): mem32(ffbdd000) ncr0 rev 2 int a irq 11 on pci0:19 mapreg[10] type=1 addr=0000fc00 size=0100. mapreg[14] type=0 addr=ffbdff00 size=0100. reg20: virtual=0xf47cef00 physical=0xffbdff00 size=0x100 ncr0: restart (scsi reset). ncr0 scanning for targets 0..6 (V2 pl21 95/03/21) (ncr0:0:0): "HP C2247-300 0BH4" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1003MB (2054864 512 byte sectors) sd0(ncr0:0:0): with 2051 cyls, 13 heads, and an average 77 sectors/track (ncr0:2:0): "TOSHIBA CD-ROM XM-3401TA 2873" type 5 removable SCSI 2 cd0(ncr0:2:0): CD-ROM cd0(ncr0:2:0): 250ns (4 Mb/sec) offset 8. cd0(ncr0:2:0): NOT READY asc:4,1 cd0(ncr0:2:0): Logical unit is in process of becoming ready can't get the size de0 rev 17 int a irq 10 on pci0:20 mapreg[10] type=1 addr=0000f880 size=0080. mapreg[14] type=0 addr=ffbdfe80 size=0080. reg20: virtual=0xf47cfe80 physical=0xffbdfe80 size=0x80 de0: DC21140 [10-100Mb/s] pass 1.1 Ethernet address 00:00:c0:b3:d0:9a de0: enabling 10baseT UTP port bpf: de0 attached @@@ pcibus_ihandler_attach: result=16 irq 10 already in use. pci0: uses 384 bytes of memory from ffbdfe80 upto ffbdffff. pci0: uses 384 bytes of I/O space from f880 upto fcff. From owner-freebsd-current Fri Sep 22 07:23:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA04885 for current-outgoing; Fri, 22 Sep 1995 07:23:23 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA04866 for ; Fri, 22 Sep 1995 07:22:39 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA10070; Sat, 23 Sep 1995 00:14:43 +1000 Date: Sat, 23 Sep 1995 00:14:43 +1000 From: Bruce Evans Message-Id: <199509221414.AAA10070@godzilla.zeta.org.au> To: bde@zeta.org.au, rich@lamprey.utmb.edu Subject: Re: XFree86 and the new malloc Cc: freebsd-current@FreeBSD.org, roberto@keltia.Freenix.FR Sender: owner-current@FreeBSD.org Precedence: bulk >|From: Bruce Evans >| >|>Has anyone tried to link the X server with the new libc's malloc from >|>Poul-Henning ? >| >|It's already linked to libc's malloc unless you have a version that is >|linked to a nonstandard libmalloc. This is one of the main advantages >|(?) of not putting phkmalloc in a special library that almost no one >|will use. It also shows why third party programs should not use >|nonstandard libraries to avoid problems in standard libaries. >Hey, wait a sec. XFree86 3.1.2 does use -lgnumalloc. We >had been testing it but only switched when it passed all the >alpha/beta tests, and that happened after 3.0 came out. Yes, XFree86 3.1.2 is linked to a nonstandard malloc. This unfortunately means that people running the newest versions of everything, so that they have phkmalloc, the latest Xfree, and sig11's (:-), won't automatically be testing phkmalloc where testing/use is most important/beneficial. FreeBSD-2.0.5 only has Xfree 3.1.1. I don't use X much, and 3.2.2 doesn't work here (*), so I just use the version of the cdrom. (*) The W32 version used to hang waiting for a bit in ACL_ACCELERATOR_STATUS, always after switching the console back to X and sometimes at startup. In 3.1.2, it aborts early in initialization related to this when it references an uninitialized ACL_ACCELERATOR pointer. Bruce From owner-freebsd-current Fri Sep 22 07:32:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA05058 for current-outgoing; Fri, 22 Sep 1995 07:32:46 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA05053 ; Fri, 22 Sep 1995 07:32:40 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id KAA06739; for ; Fri, 22 Sep 1995 10:32:14 -0400 Date: Fri, 22 Sep 95 10:30:51 PDT From: "Ugen J.S.Antsilevich" Subject: Re: IP accounting To: "Jordan K. Hubbard" , davidg@Root.COM Cc: Gary Palmer , Nathan Stratton , questions@freebsd.org, current@freebsd.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk > Actually, I use 'netstat -I de0 -b -w 60', and then calculate the per-second >average from each 60 second sample. Auch..ipacct could really do that and much more...and that is not so hard ever. --Ugen From owner-freebsd-current Fri Sep 22 08:02:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA06024 for current-outgoing; Fri, 22 Sep 1995 08:02:22 -0700 Received: from irbs.irbs.com (irbs.com [199.182.75.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA06016 for ; Fri, 22 Sep 1995 08:02:14 -0700 Received: (from jc@localhost) by irbs.irbs.com (8.6.12/8.6.6) id LAA02965 for freebsd-current@freefall.cdrom.com; Fri, 22 Sep 1995 11:02:04 -0400 From: John Capo Message-Id: <199509221502.LAA02965@irbs.irbs.com> Subject: Re: sig 10/11 problems To: freebsd-current@freefall.FreeBSD.org (freebsd-current) Date: Fri, 22 Sep 1995 11:02:02 -0400 (EDT) In-Reply-To: <9509221242.AA04947@borg.ess.harris.com> from "James Leppek" at Sep 22, 95 08:42:16 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 629 Sender: owner-current@FreeBSD.org Precedence: bulk James Leppek writes: > > I have been testing a patch from david since yesterday morning > (compiles, make world, etc) and I have not seen the problem so > the patch is either working or has moved the problem :-) > > Sorry it took a while to test but I wanted to try 2 make worlds at > 7 hours each. > > It may help if people with 16Meg machines try it because I noticed > that the problem was more frequent with 16M than 32M. > I have been running one heavily loaded 16M machine for an hour with no problems. Innd, 2 makes, X, NFS server. It wouldn't make it an hour with previous kernels. John Capo IRBS Engineering From owner-freebsd-current Fri Sep 22 08:24:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA07035 for current-outgoing; Fri, 22 Sep 1995 08:24:34 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA07026 for ; Fri, 22 Sep 1995 08:24:26 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA26708; Fri, 22 Sep 95 17:26:32 +0100 Date: Fri, 22 Sep 95 17:26:32 +0100 Message-Id: <9509221626.AA26708@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: FreeBSD-current@freefall.freebsd.org Subject: pci bus not probed X-Mailer: Emacs Sender: owner-current@FreeBSD.org Precedence: bulk With a kernel compiled today, my pci bus is not more detected. I have a P55TP4XE Mboard (P90, Triton chipset) Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-current Fri Sep 22 08:35:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA07431 for current-outgoing; Fri, 22 Sep 1995 08:35:11 -0700 Received: from id.slip.bcm.tmc.edu (root@hou37.onramp.net [199.1.137.165]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA07423 for ; Fri, 22 Sep 1995 08:34:57 -0700 Received: (from rich@localhost) by id.slip.bcm.tmc.edu (8.6.12/8.6.9) id KAA04960; Fri, 22 Sep 1995 10:33:00 -0500 Date: Fri, 22 Sep 1995 10:33:00 -0500 From: Rich Murphey Message-Id: <199509221533.KAA04960@id.slip.bcm.tmc.edu> To: bde@zeta.org.au CC: bde@zeta.org.au, freebsd-current@FreeBSD.org, roberto@keltia.Freenix.FR In-reply-to: <199509221414.AAA10070@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 23 Sep 1995 00:14:43 +1000) Subject: Re: XFree86 and the new malloc Reply-to: rich@lamprey.utmb.edu Sender: owner-current@FreeBSD.org Precedence: bulk |From: Bruce Evans |>Hey, wait a sec. XFree86 3.1.2 does use -lgnumalloc. We |>had been testing it but only switched when it passed all the |>alpha/beta tests, and that happened after 3.0 came out. | |Yes, XFree86 3.1.2 is linked to a nonstandard malloc. This unfortunately |means that people running the newest versions of everything, so that they |have phkmalloc, the latest Xfree, and sig11's (:-), won't automatically |be testing phkmalloc where testing/use is most important/beneficial. People wanted gnumalloc linked into the server, so yes. You can build a phkmalloc shared library and call it /usr/lib/libgnumalloc.so.2.0 if you want the 3.1.2 server to use phkmalloc. I've done this in the past to test the server with various versions of malloc and I plan on doing it again for the alpha/beta tests. |FreeBSD-2.0.5 only has Xfree 3.1.1. I don't use X much, and 3.2.2 doesn't |work here (*), so I just use the version of the cdrom. | |(*) The W32 version used to hang waiting for a bit in ACL_ACCELERATOR_STATUS, |always after switching the console back to X and sometimes at startup. In |3.1.2, it aborts early in initialization related to this when it references |an uninitialized ACL_ACCELERATOR pointer. OK, I'll forward this to the alpha list so they'll know. Rich From owner-freebsd-current Fri Sep 22 08:42:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA07698 for current-outgoing; Fri, 22 Sep 1995 08:42:41 -0700 Received: from mramirez.sy.yale.edu (mramirez.sy.yale.edu [130.132.57.207]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA07691 for ; Fri, 22 Sep 1995 08:42:36 -0700 Received: (from mrami@localhost) by mramirez.sy.yale.edu (8.6.12/8.6.9) id LAA04065; Fri, 22 Sep 1995 11:41:29 -0400 Date: Fri, 22 Sep 1995 11:41:29 -0400 (EDT) From: Marc Ramirez Reply-To: mrami@minerva.cis.yale.edu To: Bruce Evans cc: bde@zeta.org.au, rich@lamprey.utmb.edu, freebsd-current@FreeBSD.org, roberto@keltia.freenix.fr Subject: Re: XFree86 and the new malloc In-Reply-To: <199509221414.AAA10070@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Sat, 23 Sep 1995, Bruce Evans wrote: > (*) The W32 version used to hang waiting for a bit in ACL_ACCELERATOR_STATUS, > always after switching the console back to X and sometimes at startup. In > 3.1.2, it aborts early in initialization related to this when it references > an uninitialized ACL_ACCELERATOR pointer. That explains the problems I've been having! I've been beating my brains out the past couple of days! Marc. From owner-freebsd-current Fri Sep 22 09:52:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA09950 for current-outgoing; Fri, 22 Sep 1995 09:52:05 -0700 Received: from main.statsci.com (main.statsci.com [198.145.127.110]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA09945 for ; Fri, 22 Sep 1995 09:52:02 -0700 Received: by main.statsci.com (Smail3.1.29.1 #3) id m0swBH8-000r3uC; Fri, 22 Sep 95 09:48 PDT Message-Id: X-Mailer: exmh version 1.6.1 5/23/95 To: rich@lamprey.utmb.edu cc: bde@zeta.org.au, freebsd-current@freebsd.org, roberto@keltia.Freenix.FR Subject: Re: XFree86 and the new malloc In-reply-to: Your message of "Fri, 22 Sep 1995 10:33:00 -0500." <199509221533.KAA04960@id.slip.bcm.tmc.edu> Reply-to: scott@statsci.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Sep 1995 09:48:15 -0700 From: Scott Blachowicz Sender: owner-current@freebsd.org Precedence: bulk > |FreeBSD-2.0.5 only has Xfree 3.1.1. I don't use X much, and 3.2.2 doesn't > |work here (*), so I just use the version of the cdrom. Would any of this talk of mallocs explain why I get segmentation violations out of xrdb on a stock 2.0.5R/XFree 3.1.1 form CD system? Or should I investigate a bit more? Scott Blachowicz Ph: 206/283-8802x240 StatSci, a div of MathSoft, Inc. 1700 Westlake Ave N #500 scott@statsci.com Seattle, WA USA 98109 Scott.Blachowicz@seaslug.org From owner-freebsd-current Fri Sep 22 10:03:20 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA10319 for current-outgoing; Fri, 22 Sep 1995 10:03:20 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA10314 for ; Fri, 22 Sep 1995 10:03:18 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id KAA09743; Fri, 22 Sep 1995 10:02:26 -0700 Message-Id: <199509221702.KAA09743@precipice.shockwave.com> To: "Ugen J.S.Antsilevich" cc: current@freebsd.org Subject: Re: IP accounting In-reply-to: Your message of "Fri, 22 Sep 1995 10:30:51 PDT." Date: Fri, 22 Sep 1995 10:02:26 -0700 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk Ugen, Would you be interested in making your IP accounting code standalone or able to dove-tail in with Darren's newer firewall code? Paul From owner-freebsd-current Fri Sep 22 11:13:31 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA12498 for current-outgoing; Fri, 22 Sep 1995 11:13:31 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA12484 for ; Fri, 22 Sep 1995 11:13:23 -0700 Received: by crox.net.kiae.su id WAA00271; (8.6.9/vak/1.8a) Fri, 22 Sep 1995 22:06:23 +0400 Date: Fri, 22 Sep 1995 22:06:23 +0400 (MSD) From: "Serge V.Vakulenko" To: current@freebsd.org Subject: [patch] make wdprobe to recognize single-drive ATAPI CD-ROM configurations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk After this patch my Wearnes 120A CD-ROM drive probes fine. And it seems unlikely to break anything. --- wd1.c Thu Sep 21 21:56:28 1995 +++ wd2.c Fri Sep 22 21:37:46 1995 @@ -299,6 +299,7 @@ wdc_registerdev(dvp); /* check if we have registers that work */ + outb(du->dk_port + wd_sdh, WDSD_IBM); /* select unit 0 */ outb(du->dk_port + wd_cyl_lo, 0xa5); /* wd_cyl_lo is read/write */ if (inb(du->dk_port + wd_cyl_lo) == 0xff) /* XXX too weak */ goto nodevice; Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development From owner-freebsd-current Fri Sep 22 11:18:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA12703 for current-outgoing; Fri, 22 Sep 1995 11:18:40 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA12694 for ; Fri, 22 Sep 1995 11:18:27 -0700 Received: by crox.net.kiae.su id WAA00280; (8.6.9/vak/1.8a) Fri, 22 Sep 1995 22:09:41 +0400 Date: Fri, 22 Sep 1995 22:09:41 +0400 (MSD) From: "Serge V.Vakulenko" To: current@freebsd.org Subject: [patch] wcd.c version 1.6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Some ATAPI CD-ROM drives don't support READ_CAPACITY and READ_TOC commands. Fortunately, these commands are not necessary for data i/o. This patch makes such drives happy. Serge --- wcd15.c Fri Sep 22 00:06:44 1995 +++ wcd.c Fri Sep 22 21:40:28 1995 @@ -12,7 +12,7 @@ * or modify this software as long as this message is kept with the software, * all derivative works or modified versions. * - * Version 1.5, Thu Sep 21 23:08:11 MSD 1995 + * Version 1.6, Fri Sep 22 21:40:12 MSD 1995 */ #include "wd.h" @@ -403,18 +403,19 @@ /* Read table of contents. */ if (wcd_read_toc (t) != 0) - return (EIO); + bzero (&t->toc, sizeof (t->toc)); /* Read disc capacity. */ if (wcd_request_wait (t, ATAPI_READ_CAPACITY, 0, 0, 0, 0, 0, 0, 0, sizeof(t->info), 0, (char*)&t->info, sizeof(t->info)) != 0) - return (EIO); + bzero (&t->info, sizeof (t->info)); t->info.volsize = ntohl (t->info.volsize); t->info.blksize = ntohl (t->info.blksize); /* Print the disc description string on every disc change. * It would help to track the history of disc changes. */ - if (t->flags & (F_MEDIA_CHANGED | F_DEBUG)) { + if (t->info.volsize && t->toc.hdr.ending_track && + (t->flags & (F_MEDIA_CHANGED | F_DEBUG))) { printf ("wcd%d: ", t->lun); if (t->toc.tab[0].control & 4) printf ("%ldMB ", t->info.volsize / 512); @@ -692,6 +693,8 @@ 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0); case CDIOREADTOCHEADER: + if (! t->toc.hdr.ending_track) + return (ENODEV); bcopy (&t->toc.hdr, addr, sizeof t->toc.hdr); break; @@ -702,6 +705,8 @@ struct toc buf; u_long len; + if (! t->toc.hdr.ending_track) + return (ENODEV); if (te->starting_track < toc->hdr.starting_track || te->starting_track > toc->hdr.ending_track) return (EINVAL); @@ -792,6 +797,9 @@ struct ioc_play_track *args = (struct ioc_play_track*) addr; u_long start, len; int t1, t2; + + if (! t->toc.hdr.ending_track) + return (ENODEV); /* Ignore index fields, * play from start_track to end_track inclusive. */ --- Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development From owner-freebsd-current Fri Sep 22 11:19:10 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA12763 for current-outgoing; Fri, 22 Sep 1995 11:19:10 -0700 Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA12758 for ; Fri, 22 Sep 1995 11:19:08 -0700 Received: from balboa.eng.uci.edu by meter.eng.uci.edu (8.6.12) id LAA01195; Fri, 22 Sep 1995 11:19:04 -0700 Received: from localhost.uci.edu by balboa.eng.uci.edu (8.6.12) id LAA23364; Fri, 22 Sep 1995 11:19:03 -0700 Message-Id: <199509221819.LAA23364@balboa.eng.uci.edu> To: Brian Litzinger cc: freebsd-current@freebsd.org Subject: Re: -current no longer sees my PCI bus In-reply-to: Your message of "Fri, 22 Sep 1995 00:49:16 PDT." <199509220749.AAA02536@MediaCity.com> Date: Fri, 22 Sep 1995 11:18:58 -0700 From: Steven Wallace Sender: owner-current@freebsd.org Precedence: bulk > -current as of a sup at Fri Sep 22 00:15:40 PDT 1995 (with manual patch for > sig11 problem) no longer recognizes my PCI bus on my Intel P5-90 PCI > machine. And hence doesn't see my adaptec 2940 controller. > For all of you who's PCI bus is not recognized, here is a TEMPORARY fix to get it working again until Stefan commits a real fix. For those of you who are wondering, I have Triton chipset with configuration mode 1, 32 device pci bridge: chip0 rev 1 on pci0:0 chip1 rev 2 on pci0:7 So anyone who was working with a mode 1 bridge and is not anymore, should try this patch. Steven *** i386/isa/pcibus.c.orig Mon Sep 18 20:11:17 1995 --- i386/isa/pcibus.c Thu Sep 21 23:11:02 1995 *************** *** 146,152 **** #define CONF1_ENABLE 0x80000000ul #define CONF1_ENABLE_CHK1 0xF0000001ul ! #define CONF1_ENABLE_MSK1 0x80000001ul #define CONF1_ENABLE_RES1 0x80000000ul #define CONF1_ENABLE_CHK2 0xfffffffful #define CONF1_ENABLE_RES2 0x80fffffcul --- 146,152 ---- #define CONF1_ENABLE 0x80000000ul #define CONF1_ENABLE_CHK1 0xF0000001ul ! #define CONF1_ENABLE_MSK1 0x80000000ul #define CONF1_ENABLE_RES1 0x80000000ul #define CONF1_ENABLE_CHK2 0xfffffffful #define CONF1_ENABLE_RES2 0x80fffffcul From owner-freebsd-current Fri Sep 22 11:33:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA13267 for current-outgoing; Fri, 22 Sep 1995 11:33:03 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA13262 for ; Fri, 22 Sep 1995 11:33:00 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id LAA00551; Fri, 22 Sep 1995 11:31:57 -0700 From: "Rodney W. Grimes" Message-Id: <199509221831.LAA00551@GndRsh.aac.dev.com> Subject: Re: from(1) To: wosch@cs.tu-berlin.de (Wolfram Schneider) Date: Fri, 22 Sep 1995 11:31:56 -0700 (PDT) Cc: simonm@dcs.gla.ac.uk, wollman@lcs.mit.edu, current@freebsd.org In-Reply-To: <199509221313.PAA25411@caramba.cs.tu-berlin.de> from "Wolfram Schneider" at Sep 22, 95 03:13:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2302 Sender: owner-current@freebsd.org Precedence: bulk > > Simon Marlow writes: > >I disagree entirely. The generality provided by pipes and pipe > >combinators far outweighs the slight performance gain by implementing > >the options directly. How many other programs are you going to add > >'-c' to? What about the programs where '-c' is already taken, and you > >have to use an inconsistent flag? > > grep have already '-c'. I add -c to locate. It is a real difference > between 13MB I/O or 115MB. grep should not have the -c option. > > >A valid point, but this is a shell problem and not worth sacrificing > >the philosophy of an operating system for. > > ^philosophy^religion Go read some of the old Bell labs papers and rethink that, unix does have a philosophy, and this point is one of them! Small simple programs that act as filters and are strung togeather with pipes and shell scripts was the very thing that Unix was when it was designed. Too bad so many folks have lost sight of the elegance that really is :-(. > Do you want remove 'z' flag from tar because > > $ tar cfvz - files ... > x.tgz break old unix philosophy? Yes, because it gives me no control over the level of gzip compression or other gzip glags when you do it that way. IMHO, and I am on record with this in some of the freebsd lists long ago, way way way too many options have proliferated through out the source. tar having a z option is defanitly one of them! Programs that have options in them that cause there input or output to be filtered by execing another program are brain dead. You either have to add all the options of the other program or you have to suffer from inflexibility :-(. I think the basic reasoning of these ``optimizations'' is to make things faster, well, attack the more general problem so that ALL things can be faster, fix pipe I/O bandwidth :-). SkyRsh# dd if=/dev/zero bs=8192 count=1024 | dd of=/dev/null 1024+0 records in 1024+0 records out 8388608 bytes transferred in 3 secs (2796202 bytes/sec) SkyRsh# dd if=/dev/zero bs=8192 count=1024 >/dev/null 1024+0 records in 1024+0 records out 8388608 bytes transferred in 1 secs (8388608 bytes/sec) Pipes are slow :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Sep 22 11:47:57 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA13800 for current-outgoing; Fri, 22 Sep 1995 11:47:57 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA13789 for ; Fri, 22 Sep 1995 11:47:37 -0700 Received: by crox.net.kiae.su id WAA00337; (8.6.9/vak/1.8a) Fri, 22 Sep 1995 22:40:52 +0400 To: bde@zeta.org.au, current@FreeBSD.org, josh@American.COM References: <199509221313.XAA07515@godzilla.zeta.org.au> Message-ID: Organization: Cronyx Ltd. Date: Fri, 22 Sep 95 22:40:52 +0400 X-Mailer: BML [UNIX Beauty Mail v.1.39] From: vak@cronyx.ru Subject: Re: more ATAPI CD issues Sender: owner-current@FreeBSD.org Precedence: bulk > >This test could fail for single-drive configurations. > >The driver does not set the drive unit number to 0 before testing > >the cylinder register. If the BIOS leaves it set to 1, then the test > >will fail... > > I tried toggling the drive select bit (in a debugger with interrupts > off) on a single-drive IDE system and the test continued to work. The > status register changed from 0x50 to 0x00 (0x00 for the nonexistent > drive) and the cyl_lo register held values written to it. The altsts > register did not change from 0xf0. I tested it from the other end: my new CD-ROM drive (Wearnes 120A) failed on the cyl_lo check. I added the unit 0 select before it: outb(du->dk_port + wd_sdh, WDSD_IBM); Now it works fine. (The patch is posted to freebsd-current) Serge --- Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development From owner-freebsd-current Fri Sep 22 12:13:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA15018 for current-outgoing; Fri, 22 Sep 1995 12:13:24 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA14972 ; Fri, 22 Sep 1995 12:13:12 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id PAA28076; Fri, 22 Sep 1995 15:13:38 -0400 Date: Fri, 22 Sep 1995 15:13:36 -0400 (EDT) From: Nathan Stratton To: "Ugen J.S.Antsilevich" cc: "Jordan K. Hubbard" , davidg@Root.COM, Gary Palmer , questions@freebsd.org, current@freebsd.org Subject: Re: IP accounting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Fri, 22 Sep 1995, Ugen J.S.Antsilevich wrote: > > > Actually, I use 'netstat -I de0 -b -w 60', and then calculate the > per-second > >average from each 60 second sample. > Auch..ipacct could really do that and much more...and that is not > so hard ever. I would like to take 1 or 2 second samples to get 5 min averages. Would it be best to use ipacct or netstat? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Fri Sep 22 12:15:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA15098 for current-outgoing; Fri, 22 Sep 1995 12:15:24 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA15093 for ; Fri, 22 Sep 1995 12:15:22 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id PAA13443; for ; Fri, 22 Sep 1995 15:15:14 -0400 Date: Fri, 22 Sep 95 15:13:47 PDT From: "Ugen J.S.Antsilevich" Subject: Re: IP accounting To: Paul Traina Cc: current@freebsd.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk >Would you be interested in making your IP accounting code standalone or >able to dove-tail in with Darren's newer firewall code? Hmmm...what is that new firewall code anyway? I have not even seen it... Whoul could it do and where is the sources? --Ugen From owner-freebsd-current Fri Sep 22 12:49:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA16072 for current-outgoing; Fri, 22 Sep 1995 12:49:53 -0700 Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA16067 for ; Fri, 22 Sep 1995 12:49:43 -0700 Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.6.11/8.6.9) id VAA27733 for freebsd-current@freefall.cdrom.com; Fri, 22 Sep 1995 21:06:35 +0200 Date: Fri, 22 Sep 1995 21:06:35 +0200 From: "Christoph P. Kukulies" Message-Id: <199509221906.VAA27733@gilberto.physik.RWTH-Aachen.DE> To: freebsd-current@freefall.FreeBSD.org Subject: sig11s gone Sender: owner-current@FreeBSD.org Precedence: bulk Just FYI, the sed and login sig11s are gone with the recent ffs_vnops.c. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Fri Sep 22 13:14:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA17126 for current-outgoing; Fri, 22 Sep 1995 13:14:21 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA17116 for ; Fri, 22 Sep 1995 13:14:02 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA22318; Fri, 22 Sep 1995 22:13:05 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA06391; Fri, 22 Sep 1995 22:13:04 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id UAA06415; Fri, 22 Sep 1995 20:29:05 +0200 From: J Wunsch Message-Id: <199509221829.UAA06415@uriah.heep.sax.de> Subject: Re: rmail and brain-dead mail systems .. patch enclosed To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 22 Sep 1995 20:29:02 +0200 (MET DST) Cc: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) In-Reply-To: <199509212123.OAA00831@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Sep 21, 95 02:23:08 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 787 Sender: owner-current@FreeBSD.org Precedence: bulk As Rodney W. Grimes wrote: > > You all do realize that our rmail sources come with sendmail: Yes, of course. > And if you have problems with rmail they should be sent to Eric... The problem is rmail itself, and its idea of insisting on From_. I don't know which ancient environment Eric has been designing this for... i assume he might have had a reason for it, but for all "modern" environments, /bin/rmail can safely be replaced by sendmail. Perhaps configurations where only old UUCP mailers communicate together (without intervening RFC-822 mailers) might be the cause, perhaps there's no From: line then so From_ will be important. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Sep 22 13:15:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA17215 for current-outgoing; Fri, 22 Sep 1995 13:15:15 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA17175 ; Fri, 22 Sep 1995 13:14:58 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA22431; Fri, 22 Sep 1995 22:14:41 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA06449; Fri, 22 Sep 1995 22:14:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA06882; Fri, 22 Sep 1995 21:41:09 +0200 From: J Wunsch Message-Id: <199509221941.VAA06882@uriah.heep.sax.de> Subject: Re: IP accounting To: nathan@netrail.net (Nathan Stratton) Date: Fri, 22 Sep 1995 21:41:07 +0200 (MET DST) Cc: gary@palmer.demon.co.uk, questions@freebsd.org, current@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Nathan Stratton" at Sep 21, 95 09:45:31 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 432 Sender: owner-current@freebsd.org Precedence: bulk As Nathan Stratton wrote: > > In file included from ../../netinet/ip_fw.c:41: > ../../../include/arpa/inet.h:50: warning: redundant redeclaration of > `inet_ntoa' in same scope > ../../netinet/in.h:257: warning: previous declaration of `inet_ntoa' Btw., this has been fixed meanwhile. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Sep 22 14:16:59 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21055 for current-outgoing; Fri, 22 Sep 1995 14:16:59 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21017 for ; Fri, 22 Sep 1995 14:16:51 -0700 Received: by Sysiphos id AA02489 (5.67b/IDA-1.5 for current@freebsd.org); Fri, 22 Sep 1995 23:16:34 +0200 Message-Id: <199509222116.AA02489@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 22 Sep 1995 23:16:33 +0200 In-Reply-To: Steven Wallace "Re: -current no longer sees my PCI bus" (Sep 22, 11:18) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Steven Wallace Subject: Re: -current no longer sees my PCI bus Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Sep 22, 11:18, Steven Wallace wrote: } Subject: Re: -current no longer sees my PCI bus } > -current as of a sup at Fri Sep 22 00:15:40 PDT 1995 (with manual patch for } > sig11 problem) no longer recognizes my PCI bus on my Intel P5-90 PCI } > machine. And hence doesn't see my adaptec 2940 controller. } > } } For all of you who's PCI bus is not recognized, here is a TEMPORARY } fix to get it working again until Stefan commits a real fix. } } For those of you who are wondering, I have Triton chipset with } configuration mode 1, 32 device pci bridge: } chip0 rev 1 on pci0:0 } chip1 rev 2 on pci0:7 } So anyone who was working with a mode 1 bridge and is not anymore, should } try this patch. I sent out a patch a few hours ago, that ought to fix the problem. Please report on success or failure of the patch, since the one that Steven Wallace included in his mail is known to fail on a number of systems ... (Yes, it will fix -current on the Triton). If you want to have PCI support for your system, then please report on how my patch worked. I don't have enough different systems to test it on myself. And I need it tested on non-PCI systems, too ! I REALLY depend on YOUR feedback ... STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Fri Sep 22 14:29:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23056 for current-outgoing; Fri, 22 Sep 1995 14:29:04 -0700 Received: from haywire.DIALix.COM (peter@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23050 for ; Fri, 22 Sep 1995 14:28:58 -0700 Received: (from peter@localhost) by haywire.DIALix.COM (sendmail) id FAA15859 for freebsd-current@FreeBSD.org; Sat, 23 Sep 1995 05:28:53 +0800 (WST) From: Peter Wemm Message-Id: <199509222128.FAA15859@haywire.DIALix.COM> Subject: Re: rmail and brain-dead mail systems .. patch enclosed To: freebsd-current@FreeBSD.org Date: Sat, 23 Sep 1995 05:28:52 +0800 (WST) 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 Precedence: bulk In freebsd.current you write: >As Rodney W. Grimes wrote: >> >> You all do realize that our rmail sources come with sendmail: >Yes, of course. >> And if you have problems with rmail they should be sent to Eric... > >The problem is rmail itself, and its idea of insisting on From_. I >don't know which ancient environment Eric has been designing this >for... i assume he might have had a reason for it, but for all >"modern" environments, /bin/rmail can safely be replaced by sendmail. > >Perhaps configurations where only old UUCP mailers communicate >together (without intervening RFC-822 mailers) might be the cause, >perhaps there's no From: line then so From_ will be important. If you drop the From_ line, how do you communicate the envelope sender address? It's most definately needed... For example, when you send email to (say) current@freebsd.org, the envelope sender is "owner-freebsd-current@freebsd.org" which happens to be aliased to "mailman". If your uucp mailer cannot tell the mail system to send all 90 bounces/deferred messages to jmb, instead of the "From: joerg@...", then you'd get pretty annoyed pretty quick.. :-) You can only replace rmail with sendmail if you can get all of your neighbors to call your rmail as "rmail -f envelope_sender -oMrUUCP envelope_recipient" - they may as well just be allowed to call sendmail directly... -Peter From owner-freebsd-current Fri Sep 22 16:17:39 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA27372 for current-outgoing; Fri, 22 Sep 1995 16:17:39 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA27365 for ; Fri, 22 Sep 1995 16:17:35 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA26614; Sat, 23 Sep 1995 01:17:29 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA09099; Sat, 23 Sep 1995 01:17:27 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA10420; Fri, 22 Sep 1995 22:48:08 +0200 From: J Wunsch Message-Id: <199509222048.WAA10420@uriah.heep.sax.de> Subject: Re: XFree86 and the new malloc To: scott@statsci.com Date: Fri, 22 Sep 1995 22:48:05 +0200 (MET DST) Cc: rich@lamprey.utmb.edu, bde@zeta.org.au, freebsd-current@FreeBSD.org, roberto@keltia.Freenix.FR Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Scott Blachowicz" at Sep 22, 95 09:48:15 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 814 Sender: owner-current@FreeBSD.org Precedence: bulk As Scott Blachowicz wrote: > > Would any of this talk of mallocs explain why I get segmentation violations > out of xrdb on a stock 2.0.5R/XFree 3.1.1 form CD system? Or should I > investigate a bit more? On which server? xrdb is programmed ugly. It constantly dumped core when run against an IRIX server, so i've investigated, and replaced all the "big enough" :-) static arrays by a dynamic approach. (The SGI server simply had too many server extensions, and for each extension, a -D will be added to the cpp command line.) I've submitted my fix to the XConsortium, but haven't heard back anything except the initial autoreply. Try running xrdb without cpp. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Sep 22 16:34:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA28491 for current-outgoing; Fri, 22 Sep 1995 16:34:30 -0700 Received: from main.statsci.com (main.statsci.com [198.145.127.110]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA28473 for ; Fri, 22 Sep 1995 16:34:19 -0700 Received: by main.statsci.com (Smail3.1.29.1 #3) id m0swHbS-000r3tC; Fri, 22 Sep 95 16:33 PDT Message-Id: X-Mailer: exmh version 1.6.1 5/23/95 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: rich@lamprey.utmb.edu, bde@zeta.org.au, freebsd-current@freebsd.org, roberto@keltia.Freenix.FR Subject: Re: XFree86 and the new malloc In-reply-to: Your message of "Fri, 22 Sep 1995 22:48:05 +0200." <199509222048.WAA10420@uriah.heep.sax.de> Reply-to: scott@statsci.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Sep 1995 16:33:36 -0700 From: Scott Blachowicz Sender: owner-current@freebsd.org Precedence: bulk J Wunsch wrote: > As Scott Blachowicz wrote: > > > > Would any of this talk of mallocs explain why I get segmentation violations > > out of xrdb on a stock 2.0.5R/XFree 3.1.1 form CD system? Or should I > > investigate a bit more? > > On which server? This is all standalone on my home PC - So the answer would be, I guess, the 3.1.1 (u1?) XF86_Mach64 server. > Try running xrdb without cpp. I'll try that (or would upgrading to 3.1.2 possibly solve the problem too?). Thanx, Scott Blachowicz Ph: 206/283-8802x240 StatSci, a div of MathSoft, Inc. 1700 Westlake Ave N #500 scott@statsci.com Seattle, WA USA 98109 Scott.Blachowicz@seaslug.org From owner-freebsd-current Fri Sep 22 16:38:57 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA28836 for current-outgoing; Fri, 22 Sep 1995 16:38:57 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA28826 for ; Fri, 22 Sep 1995 16:38:52 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA27166 for ; Sat, 23 Sep 1995 01:38:43 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA09182 for freebsd-current@FreeBSD.ORG; Sat, 23 Sep 1995 01:38:43 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id BAA15700 for freebsd-current@FreeBSD.ORG; Sat, 23 Sep 1995 01:38:01 +0200 From: J Wunsch Message-Id: <199509222338.BAA15700@uriah.heep.sax.de> Subject: Re: rmail and brain-dead mail systems .. patch enclosed To: freebsd-current@FreeBSD.ORG Date: Sat, 23 Sep 1995 01:37:59 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.ORG In-Reply-To: <199509222128.FAA15859@haywire.DIALix.COM> from "Peter Wemm" at Sep 23, 95 05:28:52 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1159 Sender: owner-current@FreeBSD.ORG Precedence: bulk As Peter Wemm wrote: > > If you drop the From_ line, how do you communicate the envelope sender > address? > > It's most definately needed... For example, when you send email to > (say) current@freebsd.org, the envelope sender is > "owner-freebsd-current@freebsd.org" which happens to be aliased to > "mailman". Hmmmmmm.... j@uriah 138% perl -e 'while(<>) {\ next unless /^From /;\ ($f,$u)=split; $fr{$u}++;\ }\ \ foreach $u reverse(sort(bycount (keys %fr))) {\ print "$u: $fr{$u} times\n"\ }\ exit;\ sub bycount {$fr{$a} <=> $fr{$b}}' $mail joerg_wunsch: 34 times bde@zeta.org.au: 3 times sax-saxnet-request@sax.sax.de: 3 times uucp: 3 times syssgm@devetir.qld.gov.au: 2 times uk1@irz301.inf.tu-dresden.de: 2 times peter@freefall.freebsd.org: 2 times cutie.ka.sub.org!pmh@pilhuhn.de: 1 times ... (remaining addresses that only appear once) As you can see, there's 34 times "joerg_wunsch" in the envelope address. Pretty much useless, don't you think? And that's with the stock rmail(1), of course. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Sep 22 17:10:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01305 for current-outgoing; Fri, 22 Sep 1995 17:10:17 -0700 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA01262 for ; Fri, 22 Sep 1995 17:10:12 -0700 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id IAA00614 for freebsd-current@freebsd.org; Sat, 23 Sep 1995 08:10:07 +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: 23 Sep 1995 08:10:02 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <43vj8q$iq$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199509222128.FAA15859@haywire.DIALix.COM>, <199509222338.BAA15700@uriah.heep.sax.de> Subject: Re: rmail and brain-dead mail systems .. patch enclosed Sender: owner-current@freebsd.org Precedence: bulk j@uriah.heep.sax.de (J Wunsch) writes: >As Peter Wemm wrote: >> >> If you drop the From_ line, how do you communicate the envelope sender >> address? >> >> It's most definately needed... For example, when you send email to >> (say) current@freebsd.org, the envelope sender is >> "owner-freebsd-current@freebsd.org" which happens to be aliased to >> "mailman". >Hmmmmmm.... >j@uriah 138% perl -e 'while(<>) {\ > next unless /^From /;\ > ($f,$u)=split; $fr{$u}++;\ >}\ >\ >foreach $u reverse(sort(bycount (keys %fr))) {\ > print "$u: $fr{$u} times\n"\ >}\ >exit;\ >sub bycount {$fr{$a} <=> $fr{$b}}' $mail >joerg_wunsch: 34 times >bde@zeta.org.au: 3 times >sax-saxnet-request@sax.sax.de: 3 times >uucp: 3 times >syssgm@devetir.qld.gov.au: 2 times >uk1@irz301.inf.tu-dresden.de: 2 times >peter@freefall.freebsd.org: 2 times >cutie.ka.sub.org!pmh@pilhuhn.de: 1 times >... (remaining addresses that only appear once) >As you can see, there's 34 times "joerg_wunsch" in the envelope >address. Pretty much useless, don't you think? >And that's with the stock rmail(1), of course. :) Ahh, yes.. but those 34 joerg_wunsch addresses were probably from cvs-committers, or core or one of the other "unguarded" mailing lists on freefall.. If you mail to -committers or core, you get the bounces personally because of the sendmail configuration on freefall. But the other mailing list stuff goes to jmb. Cheers, -Peter >-- >cheers, J"org >joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ >Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Sep 23 01:14:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA15636 for current-outgoing; Sat, 23 Sep 1995 01:14:24 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA15624 for ; Sat, 23 Sep 1995 01:14:17 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA04649 for ; Sat, 23 Sep 1995 10:14:11 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA12470 for freebsd-current@FreeBSD.ORG; Sat, 23 Sep 1995 10:14:11 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA17272 for freebsd-current@FreeBSD.ORG; Sat, 23 Sep 1995 09:38:13 +0200 From: J Wunsch Message-Id: <199509230738.JAA17272@uriah.heep.sax.de> Subject: Re: rmail and brain-dead mail systems .. patch enclosed To: freebsd-current@FreeBSD.ORG Date: Sat, 23 Sep 1995 09:38:12 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.ORG In-Reply-To: <43vj8q$iq$1@haywire.DIALix.COM> from "Peter Wemm" at Sep 23, 95 08:10:02 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3194 Sender: owner-current@FreeBSD.ORG Precedence: bulk As Peter Wemm wrote: > > >As you can see, there's 34 times "joerg_wunsch" in the envelope > >address. Pretty much useless, don't you think? > > >And that's with the stock rmail(1), of course. :) > > Ahh, yes.. but those 34 joerg_wunsch addresses were probably from > cvs-committers, ... No, for example the message i'm replying to does also contain such a "joerg_wunsch" in the From_ line: ~From joerg_wunsch Sat Sep 23 06:20:53 1995 ~Received: (from uucp@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) with \ ~ UUCP id GAA16983 for freebsd-current@uriah.heep.sax.de; Sat, 23 Sep 1995 \ ~ 06:20:53 +0200 [serveral Received's] ~To: freebsd-current@FreeBSD.ORG ~Date: 23 Sep 1995 08:10:02 +0800 ~From: peter@haywire.dialix.com (Peter Wemm) [...] ~Subject: Re: rmail and brain-dead mail systems .. patch enclosed ~Sender: owner-current@FreeBSD.ORG The only hint to the actual sender is the Sender: header. As the first Receveived header shows, the messages wasn't even directed to joerg_wunsch, but to freebsd-current@uriah.heep.sax.de instead. The From_ line (also refered to as the "Unix From line") is not part of RFC822. In particular, UUCP mailers tend to trash this line, so it's entirely useless. Sendmail immediately strips it from each incoming message and discards it. (Look into the mail queue, you'll find a header and a data file for each queue entry, and the header file does not include this line.) Since the "envelope" addresses are often bogus, they should IMHO not be used. Instead, RFC822 says: 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO For systems which automatically generate address lists for replies to messages, the following recommendations are made: o The "Sender" field mailbox should be sent notices of any problems in transport or delivery of the original messages. If there is no "Sender" field, then the "From" field mailbox should be used. o The "Sender" field mailbox should NEVER be used automatically, in a recipient's reply message. o If the "Reply-To" field exists, then the reply should go to the addresses indicated in that field and not to the address(es) indicated in the "From" field. o If there is a "From" field, but no "Reply-To" field, the reply should be sent to the address(es) indicated in the "From" field. Sometimes, a recipient may actually wish to communicate with the person that initiated the message transfer. In such cases, it is reasonable to use the "Sender" address. ... I think, sendmail does it this way. vacation(1) is the last program i know that does not comply to RFC822. It should probably be rewritten to do a better job. I cannot use it in its current form, and last time i've been using it, i've put a Perl wrapper around that generated the beloved From_ line out of the RFC822 headers... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Sep 23 03:04:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA23452 for current-outgoing; Sat, 23 Sep 1995 03:04:18 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA23436 for ; Sat, 23 Sep 1995 03:04:10 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id MAA16673 ; Sat, 23 Sep 1995 12:04:08 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id MAA20206 ; Sat, 23 Sep 1995 12:04:07 +0200 Received: (from roberto@localhost) by keltia.Freenix.FR (8.7/keltia-uucp-2.5.1) id MAA09573; Sat, 23 Sep 1995 12:03:00 +0200 (MET DST) From: Ollivier Robert Message-Id: <199509231003.MAA09573@keltia.Freenix.FR> Subject: Re: The Sig-11/10 saga & Thanks DG!!! To: dyson@freefall.freebsd.org (John Dyson) Date: Sat, 23 Sep 1995 12:03:00 +0200 (MET DST) Cc: current@freebsd.org In-Reply-To: <199509221353.GAA01931@freefall.freebsd.org> from "John Dyson" at Sep 22, 95 06:53:44 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1085 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 Precedence: bulk It seems that John Dyson said: > I am so glad that DG pointed me in the right direction on this problem, > otherwise I would have spent more time spinning my wheels!!! Thanks > David!!! Also, look forward to the fix being commited today... I'll > email to -current when it happens.... Now, I get to sleep tonight... We cannot thank both of you enough for all your work. You're great. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.Freenix.FR 2.2-CURRENT #1: Sun Sep 10 18:50:19 MET DST 1995 From owner-freebsd-current Sat Sep 23 05:34:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA02332 for current-outgoing; Sat, 23 Sep 1995 05:34:11 -0700 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA02327 for ; Sat, 23 Sep 1995 05:34:06 -0700 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.144.4]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id OAA28944 for ; Sat, 23 Sep 1995 14:32:58 +0200 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id OAA16787; Sat, 23 Sep 1995 14:32:54 +0200 Date: Sat, 23 Sep 1995 14:32:54 +0200 Message-Id: <199509231232.OAA16787@caramba.cs.tu-berlin.de> To: current@freebsd.org Subject: from MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org Precedence: bulk "Dann macht doch euren Dreck alleene" (letzter sächsischer König, 1918) I hate this discussion. Stop it now. Delete my patch from your mailbox or disk. I have other things to do than reading mails from fundamentalistic grandmothers who fighting against options which they will never use. From owner-freebsd-current Sat Sep 23 10:10:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA11494 for current-outgoing; Sat, 23 Sep 1995 10:10:16 -0700 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA11477 for ; Sat, 23 Sep 1995 10:10:03 -0700 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id BAA29954 for freebsd-current@freebsd.org; Sun, 24 Sep 1995 01:09:49 +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: 23 Sep 1995 19:56:45 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <440slt$9bb$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <43vj8q$iq$1@haywire.DIALix.COM>, <199509230738.JAA17272@uriah.heep.sax.de> Subject: Re: rmail and brain-dead mail systems .. patch enclosed Sender: owner-current@freebsd.org Precedence: bulk j@uriah.heep.sax.de (J Wunsch) writes: >As Peter Wemm wrote: >> >> >As you can see, there's 34 times "joerg_wunsch" in the envelope >> >address. Pretty much useless, don't you think? >> >> >And that's with the stock rmail(1), of course. :) >> >> Ahh, yes.. but those 34 joerg_wunsch addresses were probably from >> cvs-committers, ... >No, for example the message i'm replying to does also contain such a >"joerg_wunsch" in the From_ line: >From joerg_wunsch Sat Sep 23 06:20:53 1995 >Received: (from uucp@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) with \ > UUCP id GAA16983 for freebsd-current@uriah.heep.sax.de; Sat, 23 Sep 1995 \ > 06:20:53 +0200 >[serveral Received's] >To: freebsd-current@FreeBSD.ORG >Date: 23 Sep 1995 08:10:02 +0800 >From: peter@haywire.dialix.com (Peter Wemm) >[...] >Subject: Re: rmail and brain-dead mail systems .. patch enclosed >Sender: owner-current@FreeBSD.ORG You're confusing two things here... You're looking at something generated by "mail.local", not "rmail". >The only hint to the actual sender is the Sender: header. As the >first Receveived header shows, the messages wasn't even directed to >joerg_wunsch, but to freebsd-current@uriah.heep.sax.de instead. I've not been able to check, because your machine is not answering smtp interrogation.. :-) but what I suspect is happening is this: On your machine, you have some exploder aliases set up. freebsd-current@uriah.heep.sax.de aliased to the recipients, while owner-freebsd-current@uriah... is aliased to "joerg_wunsch" What is happening, is that you're receiving your uucp rmail job like this: uux ... uriah!rmail freebsd-current From owner-current@freeBSD.ORG From: peter@haywire.dialix.com (peter wemm) To: freebsd-current@freebsd.org .... What happens is that rmail takes the "From " line, and passes that to sendmail with the "-f" option, meaning rmail is piping the message to sendmail like this: sendmail -fowner-current@freebsd.org -oMrUUCP freebsd-current@uriah.heep.sax.de Up until this sendmail is successfully delivered to your exploder, any bounces go back to "owner-current@freebsd.org", aka jmb@freebsd.org However, I think you have that owner-freebsd-current alias in there. So, the original envelope sender is *replaced*, *BY SENDMAIL*, with "joerg_wunsch". This is in the sendmail docs and FAQ, and a workaround on how to avoid your name being there. Sendmail is recording the original envelope sender in the "sender:" line, so you can see where it's come from. >The From_ line (also refered to as the "Unix From line") is not part >of RFC822. In particular, UUCP mailers tend to trash this line, so >it's entirely useless. Sendmail immediately strips it from each >incoming message and discards it. (Look into the mail queue, you'll >find a header and a data file for each queue entry, and the header >file does not include this line.) Yes, but UUCP is *not* RFC822. :-) Yes, sendmail does discard it, because it's expecting rmail to retreive it out and pass it in through the "-f" switch. It's not sendmail's job to understand a "uucp format" message.. :-) That's for rmail to translate. >Since the "envelope" addresses are often bogus, they should IMHO not >be used. Instead, RFC822 says: > 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO > For systems which automatically generate address lists for > replies to messages, the following recommendations are made: > o The "Sender" field mailbox should be sent notices of > any problems in transport or delivery of the original > messages. If there is no "Sender" field, then the > "From" field mailbox should be used. > o The "Sender" field mailbox should NEVER be used > automatically, in a recipient's reply message. > o If the "Reply-To" field exists, then the reply should > go to the addresses indicated in that field and not to > the address(es) indicated in the "From" field. > o If there is a "From" field, but no "Reply-To" field, > the reply should be sent to the address(es) indicated > in the "From" field. > Sometimes, a recipient may actually wish to communicate with > the person that initiated the message transfer. In such > cases, it is reasonable to use the "Sender" address. >... >I think, sendmail does it this way. Yes. Dont forget, this behaviour is very much clarified and reinforced in later RFC's. RFC822 is getting rather dated. I think RFC1123 (the host requirements RFC) says the mail system must handle envelope addresses. I've not seen the context of the bit of rfc822 that you've quoted, but it looks to me like it's the MUA section, not the MTA section. It's saying that the envelope sender should not be used for personal replies. It's saying the envelope sender should be used for transport/delivery initiated replies. IMHO, "vacation" is a "transport" notification, and *should* use the envelope sender, which is what it currently does. If you sent a message to freebsd-hackers, do you *want* to get (say) 6 vacation replies from people you've never heard of? No... It's the list-owner's problem whether he decides to drop them off the mailing list until they return and resubscribe. There's no sense in wasting network resources on somebody who's left a vacation message running saying they've changed jobs and their new address is enclosed in the reply. Imagine the complaints if some user sent mail to -hackers, and got one of those because the hacked vacation program on the remote end used the "From: " line instead of the "From " line.. The originater is totally powerless to do anything about it. >vacation(1) is the last program i know that does not comply to RFC822. >It should probably be rewritten to do a better job. I cannot use it >in its current form, and last time i've been using it, i've put a Perl >wrapper around that generated the beloved From_ line out of the RFC822 >headers... (My reading suggests it is quite compliant, because it's a transport/delivery initiated message, not a personal/user initiated message...) Hmm.. How have you changed your sendmail and sendmail.cf? The standard freebsd sendmail.cf generates a new "From " line as it pipes it to vacation. .forward: "| cat > /tmp/mailfile" % sendmail testuser test ^D % cat /tmp/mailfile >From peter Sat Sep 23 19:27:45 1995 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id TAA04373 for testuser; Sat, 23 Sep 1995 19:27:45 +0800 Date: Sat, 23 Sep 1995 19:27:45 +0800 From: Peter Wemm Message-Id: <199509231127.TAA04373@jhome.DIALix.COM> Apparently-To: testuser test % sendmail -fpresident@usa.org testuser test2 ^D % cat /tmp/mailfile >From president@usa.org Sat Sep 23 19:30:58 1995 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id TAA04384 for testuser; Sat, 23 Sep 1995 19:30:58 +0800 Date: Sat, 23 Sep 1995 19:30:58 +0800 From: president@usa.com Message-Id: <199509231130.TAA04384@jhome.DIALix.COM> Apparently-To: testuser test2 As you can see, sendmail has *generated* a "From " line for our benefit.. :-) mail.local will as well when it delivers it to the mailbox. Dont confuse these with what rmail wants.. It's unfortunate that the meaning is overloaded... You can change the Mprog mailer definition so that it doesn't include the "From " line, but instead includes things like "Return-Path:" or "Sender:" instead. An RFC822-style address isn't an easy thing to parse once several styles of comments get in there.. :-) They can get really UGLY.. :-) As a side note, in SMTP, the envelope sender and recipient are passed like this... MAIL From: RCPT To: It's no different to this: uux .... rmail uriah.heep.sax.de!freebsd-current From owner-current@freebsd.org ..... It does work very well on the whole, far better than you're giving it credit for... :-) (witness the amount of bounce jmb/mailman get on freefall, and how much (zero!) bounce mail people get when sending to -current.) However, as you say, there are some pretty horrible ways older systems *mangle* it. IMHO, SYSV mailers tend to be some of the worst offenders, followed very closely by Suns. -Peter >-- >cheers, J"org >joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ >Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Sep 23 12:58:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28164 for current-outgoing; Sat, 23 Sep 1995 12:58:41 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA28159 for ; Sat, 23 Sep 1995 12:58:39 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4) id AA04831; Sat, 23 Sep 1995 15:58:33 -0400 Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA07295; Sat, 23 Sep 95 15:55:55 EDT Date: Sat, 23 Sep 95 15:55:55 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9509231955.AA07295@borg.ess.harris.com> To: freebsd-current@freefall.FreeBSD.org Subject: more core dumps Sender: owner-current@FreeBSD.org Precedence: bulk netscape worked yesterday but today's kernel causes a core dump (sig 11) I have tried netscape 1.0 and 1.1 and they both core :-( This is with a kernel that has doclusterread as 0. anyone else seeing this? Jim Leppek From owner-freebsd-current Sat Sep 23 13:47:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00219 for current-outgoing; Sat, 23 Sep 1995 13:47:49 -0700 Received: from port14.hubbard2.t.ic.net (root@port14.hubbard2.t.ic.net [152.160.88.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00210 for ; Sat, 23 Sep 1995 13:47:38 -0700 Received: (from rob@localhost) by port14.hubbard2.t.ic.net (8.6.11/8.6.9) id QAA00746 for current@freefall.cdrom.com; Sat, 23 Sep 1995 16:42:08 -0400 Message-Id: <199509232042.QAA00746@port14.hubbard2.t.ic.net> Subject: "proc size mismatch (14208 total, 620 chunks)" To: current@freefall.FreeBSD.org Date: Sat, 23 Sep 1995 16:42:07 -0400 (EDT) From: "Rob Misiak" Reply-To: rdm@ic.net X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 451 Sender: owner-current@FreeBSD.org Precedence: bulk Ever since I started using -current (a couple days ago) I get the following message whenever I try to 'ps' or 'w': proc size mismatch (14208 total, 620 chunks) A friend suggested rebooting, but the problem persisted after reboot. I have the latest -current kernel (as of 4:30PM EDT Sat 23). The kernel is compiled with PPP (the one for pppd; not the one for the 'ppp' program,) Sony CDU31a, pcvt, and SysV options. Anyone know how to fix this? Rob From owner-freebsd-current Sat Sep 23 14:00:47 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA00730 for current-outgoing; Sat, 23 Sep 1995 14:00:47 -0700 Received: from localhost.lightside.com (user59.lightside.com [198.81.209.59]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA00724 for ; Sat, 23 Sep 1995 14:00:43 -0700 Received: (from jehamby@localhost) by localhost.lightside.com (8.6.12/8.6.9) id OAA02142; Sat, 23 Sep 1995 14:01:35 -0700 Date: Sat, 23 Sep 1995 14:01:35 -0700 (PDT) From: Jake Hamby X-Sender: jehamby@localhost To: Rob Misiak cc: current@freefall.FreeBSD.org Subject: Re: "proc size mismatch (14208 total, 620 chunks)" In-Reply-To: <199509232042.QAA00746@port14.hubbard2.t.ic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Sat, 23 Sep 1995, Rob Misiak wrote: > Ever since I started using -current (a couple days ago) I get the following > message whenever I try to 'ps' or 'w': > > proc size mismatch (14208 total, 620 chunks) > > A friend suggested rebooting, but the problem persisted after reboot. I have > the latest -current kernel (as of 4:30PM EDT Sat 23). The kernel is compiled > with PPP (the one for pppd; not the one for the 'ppp' program,) Sony CDU31a, > pcvt, and SysV options. Anyone know how to fix this? > > Rob This is a pretty common question, maybe it should be in the FAQ? :-) I know I stumbled on it when I first tried to use stable. The problem is that programs like ps and w, as well as pstat, vmstat, and my personal favorite, top (from the ports collection), all find out their information by poking around into raw kernel data structures. When you upgrade the kernel, all those structures change and the old programs don't work anymore. You'll need to get the entire -current source and rebuild EVERYTHING to be completely safe (you'll pick up some enhancements to the other programs along the way, which is nice), or if you're really in a hurry, you can just recompile the libkvm library (which is shared so programs like ps should pick up the changes automatically).. ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------ From owner-freebsd-current Sat Sep 23 14:16:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01416 for current-outgoing; Sat, 23 Sep 1995 14:16:30 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA01405 for ; Sat, 23 Sep 1995 14:16:26 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4) id AA05193; Sat, 23 Sep 1995 17:16:21 -0400 Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA07376; Sat, 23 Sep 95 17:13:43 EDT Date: Sat, 23 Sep 95 17:13:43 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9509232113.AA07376@borg.ess.harris.com> To: freebsd-current@freefall.FreeBSD.org Subject: runtime warnings Sender: owner-current@FreeBSD.org Precedence: bulk I am not sure if this is current or hackers topic but since I run current... This may have come up before but what is the purpose of having runtime warnings for things like gets. Compile time warnings I can understand, but runtime??? I give someone the latest gnuchess and everytime they start it, up pops this warning about gets being unsafe. To most folks that means "don't run this program, it's broken". If this has been discussed before I guess I had forgotten the reason and it once again strikes me as a "no win" warning. If you have the sources and are compiling it, a compile time warning would be fine, if you just have a binary you are stuck with the warning. Jim Leppek From owner-freebsd-current Sat Sep 23 14:21:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01606 for current-outgoing; Sat, 23 Sep 1995 14:21:42 -0700 Received: from inlab.m.eunet.de (inlab.m.eunet.de [193.96.78.21]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA01596 for ; Sat, 23 Sep 1995 14:21:36 -0700 Received: (from tommy@localhost) by inlab (8.6.11/8.6.9) id SAA00814; Sat, 23 Sep 1995 18:53:01 GMT Date: Sat, 23 Sep 1995 18:51:45 +0000 () From: Thomas Obermair To: freebsd-current@freefall.freebsd.org Subject: Any coincidence between bug report 688 and the SIG11 problem ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk Hello, I have since I am trying to install FreeBSD on my pentium 90 machine (asus P565TP4XE mainboard) some problems. The first time I was installing directly from the 2.0.5 CD-ROM I have a problem that is at it's best represented by the bug report 688 (Page fault: supervisor write, page not present) in GNATS. When I try to run different kernels (*-SNAP, current etc..) the problem seems to change for me to the obviously well known SIG 11/10 problem. For me the two problems seem to be basically the same but it could be that there are two errors though. OK, I would be glad hearing from you concerning the following questions: - Does anyone have found the same coincidence between the two errors ? - Does the SIG 11 problem exist in 2.0.5 for faster machines ? - Does anyone run an asus P55TP4XE motherboard succesfully with freebsd of *any* kind at this time ? - Does it make sense to run simply a (SIG 11 fixed) GENERIC kernel of current leaving the entire 2.0.5 installation unchanged (for a first time fix) ? - Does anyone supply GERNERIC kernels of current for testing ? Where could I find them ? Thank you all for your great work and patience, Thanks for any reply, Regards, Thomas ___ Thomas Obermair | Inlab Software GmbH tommy@inlab.m.eunet.de | Josef-Wuerth-Str. 1 Fax: +49 89 6411160 | 82031 Gruenwald / Germany From owner-freebsd-current Sat Sep 23 14:25:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01790 for current-outgoing; Sat, 23 Sep 1995 14:25:02 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01779 for current@freebsd.org; Sat, 23 Sep 1995 14:24:59 -0700 Date: Sat, 23 Sep 1995 14:24:59 -0700 From: John Dyson Message-Id: <199509232124.OAA01779@freefall.freebsd.org> To: current@freebsd.org Subject: The Sig-11 thing Sender: owner-current@freebsd.org Precedence: bulk I have just committed the vfs_clustering fixes for the Sig-11 problem. I have not yet turned off the "work around" and will do so in the next few hours. Note that there still might be a lower level problem that we are investigating. John From owner-freebsd-current Sat Sep 23 14:29:19 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02029 for current-outgoing; Sat, 23 Sep 1995 14:29:19 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02018 ; Sat, 23 Sep 1995 14:29:15 -0700 From: John Dyson Message-Id: <199509232129.OAA02018@freefall.freebsd.org> Subject: Re: more core dumps To: jleppek@suw2k.ess.harris.com (James Leppek) Date: Sat, 23 Sep 1995 14:29:14 -0700 (PDT) Cc: freebsd-current@freefall.FreeBSD.org In-Reply-To: <9509231955.AA07295@borg.ess.harris.com> from "James Leppek" at Sep 23, 95 03:55:55 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 586 Sender: owner-current@FreeBSD.org Precedence: bulk > > netscape worked yesterday but today's kernel causes a core dump (sig 11) > I have tried netscape 1.0 and 1.1 and they both core :-( > This is with a kernel that has doclusterread as 0. > > anyone else seeing this? > > Jim Leppek > I haven't seen it, but one of the underlying problems that was covered up by the work-around could still cause problems. The problem was with buffer cache corruption, and that has been fixed in the latest commit. Try the latest stuff with doclusterread == 0, and your problem might go away. Then, turn on read clustering, it should work. John From owner-freebsd-current Sat Sep 23 14:46:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02623 for current-outgoing; Sat, 23 Sep 1995 14:46:51 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA02609 for ; Sat, 23 Sep 1995 14:46:46 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA20853; Sat, 23 Sep 1995 23:46:42 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA18151; Sat, 23 Sep 1995 23:46:42 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA26046; Sat, 23 Sep 1995 23:45:35 +0200 From: J Wunsch Message-Id: <199509232145.XAA26046@uriah.heep.sax.de> Subject: Re: runtime warnings To: jleppek@suw2k.ess.harris.com (James Leppek) Date: Sat, 23 Sep 1995 23:45:34 +0200 (MET DST) Cc: freebsd-current@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9509232113.AA07376@borg.ess.harris.com> from "James Leppek" at Sep 23, 95 05:13:43 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 628 Sender: owner-current@FreeBSD.org Precedence: bulk As James Leppek wrote: > > having runtime warnings for things like gets. Compile time warnings > I can understand, but runtime??? I give someone the latest gnuchess > and everytime they start it, up pops this warning about gets being > unsafe. To most folks that means "don't run this program, it's broken". It has been discussed before. The only way to convince people replacing dangerous functions (like gets()) is to annoy them. If you don't have the source, bug the author... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Sep 23 15:39:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA05339 for current-outgoing; Sat, 23 Sep 1995 15:39:41 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA05331 for ; Sat, 23 Sep 1995 15:39:37 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4) id AA05511; Sat, 23 Sep 1995 18:39:32 -0400 Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA07462; Sat, 23 Sep 95 18:36:54 EDT Date: Sat, 23 Sep 95 18:36:54 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9509232236.AA07462@borg.ess.harris.com> To: freebsd-current@freefall.FreeBSD.org Subject: Re: runtime warnings, opinion warning Sender: owner-current@FreeBSD.org Precedence: bulk This is the reason to upset users or break programs!! The only person that gets annoyed is the user or support person who must field all the queries. Since when did fbsd become a religion where you conform or are damned for all time? This position is clearly in the "advocacy" or personal pet peeve catagory that I always find amusing. I think this type of attitude is OK if you are talking about a small group of developers working on an OS, doing their own ports, etc. I can change things in a few minutes, but if I had a hundred users I would not be happy because they would be coming to me saying its broken. (to most users unsafe == broken) As the number of fbsd sites grow and commercial acceptance appears the basis for this decision does not make sense. Consider the many gnu/freeware apps that exist, would each support group have to track all these releases so that they can change them to cater to fbsd whims? I would not get a "this program is unsafe" message from sun/sg/dec/hp so what does that say to the person running a program on fbsd? If we continued with this thought then shouldn't gcc error if it detects that you have included malloc.h?? How about sprintf or strcpy, or any function that can blow a buffer? As fbsd grows these arbitrary, inconsistencies must be weeded out. The gets man page says don't use it, good place to mention it :-) Jim Leppek (stepping down from his podium :-) ) > From owner-freebsd-current@freefall.freebsd.org Sat Sep 23 17:45:34 1995 > From: J Wunsch > Subject: Re: runtime warnings > To: jleppek@suw2k.ess.harris.com (James Leppek) > Date: Sat, 23 Sep 1995 23:45:34 +0200 (MET DST) > Cc: freebsd-current@freefall.freebsd.org > Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) > X-Phone: +49-351-2012 669 > X-Mailer: ELM [version 2.4 PL23] > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset=ISO-8859-1> > Content-Transfer-Encoding: 8bit > Sender: owner-current@FreeBSD.org > > As James Leppek wrote: > > > > having runtime warnings for things like gets. Compile time warnings > > I can understand, but runtime??? I give someone the latest gnuchess > > and everytime they start it, up pops this warning about gets being > > unsafe. To most folks that means "don't run this program, it's broken". > > It has been discussed before. The only way to convince people > replacing dangerous functions (like gets()) is to annoy them. If > you don't have the source, bug the author... > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-current Sat Sep 23 17:54:48 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA11047 for current-outgoing; Sat, 23 Sep 1995 17:54:48 -0700 Received: from localhost.lightside.com (user38.lightside.com [198.81.209.38]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA11040 for ; Sat, 23 Sep 1995 17:54:46 -0700 Received: (from jehamby@localhost) by localhost.lightside.com (8.6.12/8.6.9) id RAA00199; Sat, 23 Sep 1995 17:55:30 -0700 Date: Sat, 23 Sep 1995 17:55:29 -0700 (PDT) From: Jake Hamby X-Sender: jehamby@localhost To: "Serge V.Vakulenko" cc: current@freebsd.org Subject: Re: [patch] wcd.c version 1.6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Fri, 22 Sep 1995, Serge V.Vakulenko wrote: > > Some ATAPI CD-ROM drives don't support READ_CAPACITY > and READ_TOC commands. Fortunately, these commands are not > necessary for data i/o. This patch makes such drives happy. > > Serge When I tried to apply the last three patches you've posted to my copy of wcd 1.3, a couple of them were rejected. Can you repost the whole wcd package to freefall.freebsd.org, please? Thanks! By the way, if these patches have resolved whatever IDE hard drive probing problems existed, what are the chances of getting them into FreeBSD-stable (i.e. 2.1.0)? ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------ From owner-freebsd-current Sat Sep 23 19:02:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA12702 for current-outgoing; Sat, 23 Sep 1995 19:02:16 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA12697 for ; Sat, 23 Sep 1995 19:02:11 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4) id AA06386; Sat, 23 Sep 1995 22:02:07 -0400 Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA07525; Sat, 23 Sep 95 21:59:28 EDT Date: Sat, 23 Sep 95 21:59:28 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9509240159.AA07525@borg.ess.harris.com> To: freebsd-current@freefall.FreeBSD.org Subject: netscape Sender: owner-current@FreeBSD.org Precedence: bulk has anyone gotten netscape 1.1 to work? after the last couple of weeks I don't know if its the system or kernel or that netscape really won't run :-) 1.0 runs fine, but 1.1 core dumps Jim Leppek From owner-freebsd-current Sat Sep 23 19:20:10 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA13083 for current-outgoing; Sat, 23 Sep 1995 19:20:10 -0700 Received: from bacchus.eng.umd.edu (bacchus.eng.umd.edu [129.2.94.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA13076 for ; Sat, 23 Sep 1995 19:20:05 -0700 Received: from cappuccino.eng.umd.edu (cappuccino.eng.umd.edu [129.2.98.14]) by bacchus.eng.umd.edu (8.7.Gamma.0/8.7.Gamma.0) with ESMTP id WAA11502; Sat, 23 Sep 1995 22:19:53 -0400 (EDT) Received: (chuckr@localhost) by cappuccino.eng.umd.edu (8.7/8.6.4) id WAA04548; Sat, 23 Sep 1995 22:19:52 -0400 (EDT) Date: Sat, 23 Sep 1995 22:19:52 -0400 (EDT) From: Chuck Robey To: James Leppek cc: freebsd-current@freefall.freebsd.org Subject: Re: netscape In-Reply-To: <9509240159.AA07525@borg.ess.harris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Sat, 23 Sep 1995, James Leppek wrote: > has anyone gotten netscape 1.1 to work? > after the last couple of weeks I don't know if > its the system or kernel or that netscape really won't run :-) > > 1.0 runs fine, but 1.1 core dumps Mine works, well, I have trouble with it refusing to backspace and correct errors in text entry, but otherwise than that, it works. I got it directly from the netscape ftp location (I don't remember where that was, but I'd be willing to look if you wanted me to). Tell you the truth, I'm just not thrilled with netscape, so I don't use it all that much. > > Jim Leppek > > ----------------------------+----------------------------------------------- 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 Sat Sep 23 19:43:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA13942 for current-outgoing; Sat, 23 Sep 1995 19:43:30 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA13932 for ; Sat, 23 Sep 1995 19:43:26 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id TAA00882; Sat, 23 Sep 1995 19:43:03 -0700 From: "Rodney W. Grimes" Message-Id: <199509240243.TAA00882@GndRsh.aac.dev.com> Subject: Re: Any coincidence between bug report 688 and the SIG11 problem ? To: tommy@inlab.m.eunet.de (Thomas Obermair) Date: Sat, 23 Sep 1995 19:43:03 -0700 (PDT) Cc: freebsd-current@freefall.freebsd.org In-Reply-To: from "Thomas Obermair" at Sep 23, 95 06:51:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1839 Sender: owner-current@FreeBSD.org Precedence: bulk > > > Hello, > > I have since I am trying to install FreeBSD on my pentium 90 machine > (asus P565TP4XE mainboard) some problems. The first time I was installing > directly from the 2.0.5 CD-ROM I have a problem that is at it's best > represented by the bug report 688 (Page fault: supervisor write, page not > present) in GNATS. When I try to run different kernels (*-SNAP, current > etc..) the problem seems to change for me to the obviously well known > SIG 11/10 problem. For me the two problems seem to be basically the > same but it could be that there are two errors though. > > OK, I would be glad hearing from you concerning the following questions: > > - Does anyone have found the same coincidence between the two errors ? > - Does the SIG 11 problem exist in 2.0.5 for faster machines ? > - Does anyone run an asus P55TP4XE motherboard succesfully with freebsd of > *any* kind at this time ? 100+ customers of mine are running some variant of FreeBSD on this board, it is not a board problem. Run -stable, it runs just fine on this board, if you still see sig 11's running -stable then you either have bad memory, bad cache or a bad MB. > - Does it make sense to run simply a (SIG 11 fixed) GENERIC kernel of > current leaving the entire 2.0.5 installation unchanged (for a > first time fix) ? > - Does anyone supply GERNERIC kernels of current for testing ? Where > could I find them ? > > Thank you all for your great work and patience, > Thanks for any reply, > Regards, > Thomas > > ___ > Thomas Obermair | Inlab Software GmbH > tommy@inlab.m.eunet.de | Josef-Wuerth-Str. 1 > Fax: +49 89 6411160 | 82031 Gruenwald / Germany > > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sat Sep 23 21:30:08 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA18735 for current-outgoing; Sat, 23 Sep 1995 21:30:08 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA18718 for ; Sat, 23 Sep 1995 21:30:04 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA07778; Sat, 23 Sep 1995 22:32:12 -0600 Date: Sat, 23 Sep 1995 22:32:12 -0600 From: Nate Williams Message-Id: <199509240432.WAA07778@rocky.sri.MT.net> To: jleppek@suw2k.ess.harris.com (James Leppek) Cc: freebsd-current@freefall.freebsd.org Subject: Re: runtime warnings In-Reply-To: <9509232113.AA07376@borg.ess.harris.com> References: <9509232113.AA07376@borg.ess.harris.com> Sender: owner-current@FreeBSD.org Precedence: bulk > I am not sure if this is current or hackers topic but since I > run current... > > This may have come up before but what is the purpose of > having runtime warnings for things like gets. Compile time warnings > I can understand, but runtime??? Originally, it was impossible to generate compile time warnings. So, by adding run-time warnings and access to the source you get the user of the program to quickly fix the problem because it is so annoying. ;) I'm pretty sure we can generate compile time warnings now, and it would also be easy to generate run-time warnings only once, rather than for each call of the program. Unfortunately, I don't remember how to do it and I don't have time to look right now. The place to start would be in the NetBSD version of gets.c, which has a linker directive to generate compile time warnings. Nate