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 <current@freebsd.org>; 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 <bde@zeta.org.au>
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 <current@FreeBSD.org>; 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 <j@uriah.heep.sax.de>
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 <current@freefall.freebsd.org>; 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 <j@uriah.heep.sax.de>
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 <current@freebsd.org>; 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 <dufault@hda.com>
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 <paul@netcraft.co.uk>
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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org> ; Sun, 17 Sep 1995 13:45:36 -0400
Date: Sun, 17 Sep 95 13:43:19 PDT
From: "Ugen J.S.Antsilevich" <ugen@latte.worldbank.org>
Subject: COMPAT_43
To: freebsd-current@FreeBSD.org
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.00.4.950917134448.ugen@ugen>
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" <jkh@time.cdrom.com>
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" <ugen@latte.worldbank.org>
Subject: IDE CDROM....
To: freebsd-current@FreeBSD.org, serge@FreeBSD.org
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.00.4.950917134318.ugen@ugen>
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 <freebsd-current@freefall.FreeBSD.org>; 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 <freebsd-current@freefall.cdrom.com>); 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 <hsu@cs.hut.fi>
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 <current@freefall.freebsd.org>; 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 <paul@netcraft.co.uk>
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 <paul@netcraft.co.uk>
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 <current@freefall.freebsd.org>; 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 <j@uriah.heep.sax.de>
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 <freebsd-current@FreeBSD.ORG>; 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 <freebsd-current@FreeBSD.ORG>; 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 <j@uriah.heep.sax.de>
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: <Chameleon.4.00.4.950917134448.ugen@ugen> 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 <current@FreeBSD.org>; 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" <wollman@lcs.mit.edu>
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: <v0213050eac80e627493a@[199.183.109.242]>
References: <v0213050eac80e627493a@[199.183.109.242]>
Sender: owner-current@FreeBSD.org
Precedence: bulk
<<On Sat, 16 Sep 1995 15:40:37 -0500, rkw@dataplex.net (Richard Wackerbarth) said:
> 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 <current@freefall.freebsd.org>; 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 <terry@lambert.org>
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 <current@FreeBSD.org>; 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 <jehamby@lightside.com>
X-Sender: jehamby@localhost
To: jdl@chromatic.com
cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, current@FreeBSD.org
Subject: Re: Release numbering
In-Reply-To: <199509170528.AAA14969@chrome.onramp.net>
Message-ID: <Pine.BSF.3.91.950917131334.168B-100000@localhost>
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 <terry@lambert.org>
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 <current@FreeBSD.ORG>; 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 <terry@lambert.org>
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 <current@freefall.freebsd.org>; 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 <j@uriah.heep.sax.de>
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" <rgrimes@GndRsh.aac.dev.com>
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 <freebsd-current@freebsd.org>; 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: <see above> + 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 <freebsd-current@freebsd.org>; 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 <rmallory@wiley.csusb.edu>
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 <gary@palmer.demon.co.uk>
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 <current@FreeBSD.org>; 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" <wollman@lcs.mit.edu>
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" <jkh@time.cdrom.com>
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 <current@FreeBSD.org>; 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: <v02130500ac8281cd00ee@[199.183.109.242]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 17 Sep 1995 21:18:39 -0500
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
From: rkw@dataplex.net (Richard Wackerbarth)
Subject: Re: Which SUP files are available and where ?
Cc: "Garrett A. Wollman" <wollman@lcs.mit.edu>, 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 <current@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
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 <current@freebsd.org>; 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 <jmz@cabri.obs-besancon.fr>
"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 <jmz@cabri.obs-besancon.fr>
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 <se@ZPR.Uni-Koeln.DE>
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 <current@freebsd.org>; 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 <j@uriah.heep.sax.de>
"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 <se@ZPR.Uni-Koeln.DE>
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 <current@freefall.FreeBSD.org>; 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" <jkh@time.cdrom.com>
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 <current@freebsd.org>; 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 <dufault@hda.com>
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 <freebsd-current@freefall.freebsd.org>; 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 <bde@zeta.org.au>
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 <current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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 <freebsd-current@freefall.freebsd.org>; 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 <bde@zeta.org.au>
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 <davidg@Root.COM>
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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org> ; Mon, 18 Sep 1995 09:27:58 -0400
Date: Mon, 18 Sep 95 09:26:43 PDT
From: "Ugen J.S.Antsilevich" <ugen@latte.worldbank.org>
Subject: IDE CDROM..
To: freebsd-current@FreeBSD.org
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.00.4.950918092704.ugen@ugen>
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 <paul@netcraft.co.uk>
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" <wollman@lcs.mit.edu>
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
<<On Mon, 18 Sep 1995 14:41:05 +0100 (BST), Paul Richards <paul@netcraft.co.uk> 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 <current@freebsd.org>; 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 <jmz@cabri.obs-besancon.fr>
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 <current@freebsd.org>; 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" <rgrimes@GndRsh.aac.dev.com>
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" <rgrimes@GndRsh.aac.dev.com>
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 <freebsd-current@freefall.freebsd.org>; 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" <rgrimes@GndRsh.aac.dev.com>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <smp@csn.net>
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 <paul@netcraft.co.uk>
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 <current@freebsd.org>; 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" <rgrimes@GndRsh.aac.dev.com>
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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org>; 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 <j@uriah.heep.sax.de>
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 <freebsd-current@freebsd.org>; 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 <j@uriah.heep.sax.de>
"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 <se@ZPR.Uni-Koeln.DE>
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 <current@freebsd.org>; 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: <m0sumwK-0000ReC@puffin.pelican.com>
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 <current@freebsd.org>; 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."
<m0sumwK-0000ReC@puffin.pelican.com>
Date: Mon, 18 Sep 1995 13:57:44 -0700
From: "Justin T. Gibbs" <gibbs@freefall.FreeBSD.org>
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 <freebsd-current@freebsd.org>; 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 <j@uriah.heep.sax.de>
"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 <current@FreeBSD.ORG>; 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 <mark@grondar.za>
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" <rgrimes@GndRsh.aac.dev.com>
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" <jkh@time.cdrom.com>
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 <current@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
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 <current@freebsd.org>; 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 <bde@zeta.org.au>
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 <current@freebsd.org>; 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" <rgrimes@GndRsh.aac.dev.com>
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 <current@freebsd.org>; 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 <bde@zeta.org.au>
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 <freebsd-current@FreeBSD.ORG>; 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 <paul@netcraft.co.uk>
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 <current@freebsd.org>; 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" <rgrimes@GndRsh.aac.dev.com>
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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org> ; Tue, 19 Sep 1995 17:01:10 -0400
Date: Tue, 19 Sep 95 16:58:46 PDT
From: "Ugen J.S.Antsilevich" <ugen@latte.worldbank.org>
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: <Chameleon.4.00.4.950919170158.ugen@ugen>
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 <freebsd-current@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <Chameleon.4.00.4.950919170158.ugen@ugen> 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 <current@freebsd.org>; 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 <bde@zeta.org.au>
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 <nathan@netrail.net>
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: <Pine.LNX.3.91.950920102037.15101A-100000@netrail.net>
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 <current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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 <FreeBSD-current@freefall.FreeBSD.org>; 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 <rich@lamprey.utmb.edu>
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 <majorname> (<jumpversion>) => <fullname>.
If it prints "not found" in stead of <fullname> it means that you
need an extra library. Which library this is, is shown in <major-
name>, which will be of the form libXXXX.so.<N> You will need to
find a libXXXX.so.<N>.<mm> on a Linux ftp site, and install it on
your system. The XXXX (name) and <N> (major revision number) should
match; the minor number(s) <mm> 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 <current@freebsd.org>; 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 <current@freebsd.org>; Wed, 20 Sep 1995 19:37:14 +0200
From: Wolfram Schneider <wosch@cs.tu-berlin.de>
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 <graichen@omega.physik.fu-berlin.de>
From: Thomas Graichen <graichen@omega.physik.fu-berlin.de>
From: Wolfram Schneider <wosch@cs.tu-berlin.de>
From: Wolfram Schneider <wosch@cs.tu-berlin.de>
From: Wolfram Schneider <wosch@cs.tu-berlin.de>
From: Wolfram Schneider <wosch@cs.tu-berlin.de>
--- /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 <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
#include <ctype.h>
#include <pwd.h>
#include <stdio.h>
#include <paths.h>
+#include <string.h>
+#include <stdlib.h>
-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: <bytes>" 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 <current@freebsd.org>; 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 <bugs@ns1.win.net>
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 <current@freebsd.org>; 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" <wollman@lcs.mit.edu>
Message-Id: <9509201814.AA04895@halloran-eldar.lcs.mit.edu>
To: Wolfram Schneider <wosch@cs.tu-berlin.de>
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
<<On Wed, 20 Sep 1995 19:37:08 +0200, Wolfram Schneider <wosch@cs.tu-berlin.de> 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 <current@freebsd.org>; 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 <tom@uniserve.com>
To: "Garrett A. Wollman" <wollman@lcs.mit.edu>
cc: Wolfram Schneider <wosch@cs.tu-berlin.de>, current@freebsd.org
Subject: Re: from(1)
In-Reply-To: <9509201814.AA04895@halloran-eldar.lcs.mit.edu>
Message-ID: <Pine.BSF.3.91.950920112938.1671D-100000@haven.uniserve.com>
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 <current@FreeBSD.org>; 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" <ugen@latte.worldbank.org>
Subject: RE: 2.2 looking up
To: current@FreeBSD.org, Mark Hittinger <bugs@ns1.win.net>
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.00.4.950920143150.ugen@ugen>
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 <current@freebsd.org>; 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 <bugs@ns1.win.net>
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 <current@FreeBSD.org>; 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 <staff@kyklopen.ping.dk>
To: "Ugen J.S.Antsilevich" <ugen@latte.worldbank.org>
Cc: current@FreeBSD.org, Mark Hittinger <bugs@ns1.win.net>
Subject: RE: 2.2 looking up
In-Reply-To: <Chameleon.4.00.4.950920143150.ugen@ugen>
Message-Id: <Pine.BSF.3.91.950920231628.435A-100000@kyklopen>
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 <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 <current@FreeBSD.org>; 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" <ugen@latte.worldbank.org>
Subject: RE: 2.2 looking up
To: Thomas Sparrevohn <staff@kyklopen.ping.dk>
Cc: current@FreeBSD.org, Mark Hittinger <bugs@ns1.win.net>
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.00.4.950920180553.ugen@ugen>
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 <freebsd-current@FreeBSD.ORG>; 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 <freebsd-current@FreeBSD.ORG>; 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 <roberto@keltia.Freenix.FR>
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: <Chameleon.4.00.4.950918092704.ugen@ugen> 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 <nathan@netrail.net>
To: freebsd-current@FreeBSD.org
cc: freebsd-questions@FreeBSD.org
Subject: network setup
In-Reply-To: <199509202226.PAA03738@freefall.freebsd.org>
Message-ID: <Pine.LNX.3.91.950920194205.32462B-100000@netrail.net>
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: <Pine.LNX.3.91.950920194205.32462B-100000@netrail.net> 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 <current@FreeBSD.org>; 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 <terry@lambert.org>
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: <Pine.BSF.3.91.950920231628.435A-100000@kyklopen> 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 <current@freebsd.org>; 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 <terry@lambert.org>
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 <davidg@Root.COM>
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 <current@FreeBSD.org>; 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 <terry@lambert.org>
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 <current@freebsd.org>; 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 <terry@lambert.org>
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 <davidg@Root.COM>
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" <rgrimes@GndRsh.aac.dev.com>
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 <freebsd-current@FreeBSD.ORG>; 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 <jdli@linux.csie.nctu.edu.tw>
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 <freebsd-current@FreeBSD.org>; 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 <bde@zeta.org.au>
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 <freebsd-current@FreeBSD.org>; 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 <nate@rocky.sri.MT.net>
Message-Id: <199509210623.AAA01482@rocky.sri.MT.net>
To: Bruce Evans <bde@zeta.org.au>
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 <freebsd-current@FreeBSD.ORG>; 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 <j@uriah.heep.sax.de>
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 <freebsd-current@freebsd.org>; 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 <dk@dog.farm.org>
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 <inj.2-305b1ebb-2771@bee.cs.kiev.ua> 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 <current@freebsd.org>; 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 <dfr@render.com>
To: Bruce Evans <bde@zeta.org.au>
cc: current@freebsd.org
Subject: Re: pathconf under nfsv3
In-Reply-To: <199509201209.WAA25816@godzilla.zeta.org.au>
Message-ID: <Pine.BSF.3.91.950921113325.1545E-100000@minnow.render.com>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <davidg@Root.COM>
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 <freebsd-current@FreeBSD.ORG>; 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 <jc@irbs.com>
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 <current@FreeBSD.org>; 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 <current@FreeBSD.org>; Thu, 21 Sep 1995 14:46:51 +0200
From: Wolfram Schneider <wosch@cs.tu-berlin.de>
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@cs.tu-berlin.de>
<a href="http://hyperg.cs.tu-berlin.de/C~wosch">wosch</a>
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 <current@freebsd.org>; 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 <wosch@cs.tu-berlin.de>
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" <wollman@lcs.mit.edu>
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:
><<On Wed, 20 Sep 1995 19:37:08 +0200, Wolfram Schneider <wosch@cs.tu-berlin.de> 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@cs.tu-berlin.de>
<a href="http://hyperg.cs.tu-berlin.de/C~wosch">wosch</a>
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 <freebsd-current@FreeBSD.org>; 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 <nate@rocky.sri.MT.net>
Message-Id: <199509211659.KAA02299@rocky.sri.MT.net>
To: Ollivier Robert <roberto@keltia.Freenix.FR>
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 <current@freebsd.org>; 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" <vak@crox.net.kiae.su>
To: current@freebsd.org
Subject: [patch] more stable version of wdreset()
Message-ID: <Pine.BSF.3.91.950921222404.867B-100000@crox.net.kiae.su>
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 <vak@cronyx.msk.su>
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 <FreeBSD-current@FreeBSD.org>; 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 <paul@alpha.netcraft.co.uk>
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 <freebsd-current@FreeBSD.org>; 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 <FreeBSD-current@FreeBSD.org>; 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" <jmb@kryten.Atinc.COM>
Subject: Re: sup files
To: paul@netcraft.co.uk
cc: FreeBSD current mailing list <FreeBSD-current@FreeBSD.org>
In-Reply-To: <199509211909.UAA05332@alpha.netcraft.co.uk>
Message-ID: <Pine.3.89.9509211552.V3125-0100000@kryten.atinc.com>
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 <FreeBSD-current@FreeBSD.org>; 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 <paul@alpha.netcraft.co.uk>
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: <Pine.3.89.9509211552.V3125-0100000@kryten.atinc.com> 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 <current@FreeBSD.org>; 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 <terry@lambert.org>
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 <current@FreeBSD.org>; 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 <terry@lambert.org>
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: <Pine.BSF.3.91.950921113325.1545E-100000@minnow.render.com> 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 <freebsd-current@FreeBSD.ORG>; 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 <j@uriah.heep.sax.de>
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 <current@freebsd.org>; 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: <freebsd.current/199509130003.UAA11780@mozart.american.com>
Message-ID: <AB0ZSOm0B0@crox.net.kiae.su>
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 <vak@cronyx.msk.su>
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 <current@freebsd.org>; 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 <terry@lambert.org>
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 <current@freebsd.org>; 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" <vak@crox.net.kiae.su>
To: current@freebsd.org
Subject: [patch] version 1.5 of ATAPI CD-ROM driver
Message-ID: <Pine.BSF.3.91.950922005032.286A-100000@crox.net.kiae.su>
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+len; ++p)
+ if (! *p)
+ *p = ' ';
+ for (p=buf+len-1; 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; i<len; i+=sizeof(short))
+ outw (ata->port + 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; i<len; i+=sizeof(short))
+ inw (ata->port + 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 <vak@cronyx.msk.su>
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 <freebsd-current@FreeBSD.ORG>; 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" <rgrimes@GndRsh.aac.dev.com>
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 <nathan@netrail.net>
To: questions@freebsd.org
cc: current@freebsd.org
Subject: IP accounting
In-Reply-To: <Pine.BSF.3.91.950921222404.867B-100000@crox.net.kiae.su>
Message-ID: <Pine.LNX.3.91.950921174046.27361B-100000@netrail.net>
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 <jgreco@brasil.moneng.mei.com>
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: <Pine.LNX.3.91.950921174046.27361B-100000@netrail.net> 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 <nathan@netrail.net>
To: Joe Greco <jgreco@brasil.moneng.mei.com>
cc: questions@freebsd.org, current@freebsd.org
Subject: Re: IP accounting
In-Reply-To: <199509212210.RAA28851@brasil.moneng.mei.com>
Message-ID: <Pine.LNX.3.91.950921182102.28790A-100000@netrail.net>
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 <nathan@netrail.net>
To: Joe Greco <jgreco@brasil.moneng.mei.com>
cc: questions@freebsd.org, current@freebsd.org
Subject: Re: IP accounting
In-Reply-To: <199509212210.RAA28851@brasil.moneng.mei.com>
Message-ID: <Pine.LNX.3.91.950921182405.28790B-100000@netrail.net>
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 <nathan@netrail.net>
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."
<Pine.LNX.3.91.950921174046.27361B-100000@netrail.net>
Date: Fri, 22 Sep 1995 00:38:11 +0100
Message-ID: <3111.811726691@palmer.demon.co.uk>
From: Gary Palmer <gary@palmer.demon.co.uk>
Sender: owner-current@freebsd.org
Precedence: bulk
In message <Pine.LNX.3.91.950921174046.27361B-100000@netrail.net>, 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" <rgrimes@GndRsh.aac.dev.com>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <davidg@Root.COM>
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" <rgrimes@GndRsh.aac.dev.com>
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 <Pine.LNX.3.91.950921174046.27361B-100000@netrail.net>, 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 <current@FreeBSD.ORG>; 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 <terry@lambert.org>
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 <nathan@netrail.net>
To: Gary Palmer <gary@palmer.demon.co.uk>
cc: questions@freebsd.org, current@freebsd.org
Subject: Re: IP accounting
In-Reply-To: <3111.811726691@palmer.demon.co.uk>
Message-ID: <Pine.LNX.3.91.950921214059.2536B-100000@netrail.net>
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 <Pine.LNX.3.91.950921174046.27361B-100000@netrail.net>, 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 <nathan@netrail.net>
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."
<Pine.LNX.3.91.950921214059.2536B-100000@netrail.net>
Date: Fri, 22 Sep 1995 02:54:07 +0100
Message-ID: <3651.811734847@palmer.demon.co.uk>
From: Gary Palmer <gary@palmer.demon.co.uk>
Sender: owner-current@freebsd.org
Precedence: bulk
In message <Pine.LNX.3.91.950921214059.2536B-100000@netrail.net>, 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 <current@freebsd.org>; 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 <terry@lambert.org>
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 <davidg@Root.COM>
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 <current@freebsd.org>; 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 <nathan@netrail.net>
To: Gary Palmer <gary@palmer.demon.co.uk>
cc: questions@freebsd.org, current@freebsd.org
Subject: Re: IP accounting
In-Reply-To: <3651.811734847@palmer.demon.co.uk>
Message-ID: <Pine.LNX.3.91.950921233713.5786E-100000@netrail.net>
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 <current@freebsd.org>; 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 <davidg@Root.COM>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <davidg@Root.COM>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <brian@MediaCity.com>
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 <current@freebsd.org>; 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 <brian@MediaCity.com>
"-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 <brian@mediacity.com>
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 <se@ZPR.Uni-Koeln.DE>
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 <current@freebsd.org>; 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 <swallace@ece.uci.edu>
"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 <swallace@ece.uci.edu>
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 <se@ZPR.Uni-Koeln.DE>
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 <gary@palmer.demon.co.uk>
cc: Nathan Stratton <nathan@netrail.net>, 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" <jkh@time.cdrom.com>
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 <nathan@netrail.net>
cc: Gary Palmer <gary@palmer.demon.co.uk>, questions@freebsd.org,
current@freebsd.org
Subject: Re: IP accounting
In-reply-to: Your message of "Thu, 21 Sep 1995 21:45:31 EDT."
<Pine.LNX.3.91.950921214059.2536B-100000@netrail.net>
Date: Fri, 22 Sep 1995 03:19:28 -0700
Message-ID: <21725.811765168@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
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" <jkh@time.cdrom.com>
cc: Gary Palmer <gary@palmer.demon.co.uk>,
Nathan Stratton <nathan@netrail.net>, 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 <davidg@Root.COM>
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 <current@freebsd.org>; 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 <brian@MediaCity.com>
"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 <brian@mediacity.com>
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 <se@ZPR.Uni-Koeln.DE>
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 <current@freebsd.org>; 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 <wosch@cs.tu-berlin.de>
cc: "Garrett A. Wollman" <wollman@lcs.mit.edu>, 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 <simonm@dcs.gla.ac.uk>
Sender: owner-current@freebsd.org
Precedence: bulk
Wolfram Schneider writes:
> Garrett A. Wollman writes:
> ><<On Wed, 20 Sep 1995 19:37:08 +0200, Wolfram Schneider <wosch@cs.tu-berlin.
> 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 <current@FreeBSD.ORG>; 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 <terry@lambert.org>
> 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 <paul@alpha.netcraft.co.uk>
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 <current@FreeBSD.org>; 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 <bde@zeta.org.au>
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 <phk@critter.tfs.com>
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 <current@freebsd.org>; 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 <wosch@cs.tu-berlin.de>
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 <simonm@dcs.gla.ac.uk>
Cc: "Garrett A. Wollman" <wollman@lcs.mit.edu>, 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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org>; 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 <rich@lamprey.utmb.edu>
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 <freebsd-current@FreeBSD.org>; 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 <rich@lamprey.utmb.edu>
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 <bde@zeta.org.au>
|
|>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 <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 <current@freebsd.org>; 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 <james@miller.cs.uwm.edu>
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 <Display device> rev 0 on pci0:17
pci0:18: INTEL CORPORATION, device=0x1223, class=multimedia [not supported]
map(10): mem32(ffbdd000)
ncr0 <ncr 53c825 wide scsi> 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 <Digital DC21140 Fast Ethernet> 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 <freebsd-current@FreeBSD.org>; 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 <bde@zeta.org.au>
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 <bde@zeta.org.au>
>|
>|>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" <ugen@latte.worldbank.org>
Subject: Re: IP accounting
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>, davidg@Root.COM
Cc: Gary Palmer <gary@palmer.demon.co.uk>,
Nathan Stratton <nathan@netrail.net>, questions@freebsd.org,
current@freebsd.org
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.00.4.950922103134.ugen@ugen>
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 <freebsd-current@freefall.FreeBSD.org>; 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 <jc@irbs.com>
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 <FreeBSD-current@freefall.freebsd.org>; 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 <jmz@cabri.obs-besancon.fr>
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 <freebsd-current@FreeBSD.org>; 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 <rich@lamprey.utmb.edu>
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 <bde@zeta.org.au>
|>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 <freebsd-current@FreeBSD.org>; 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 <mrami@mramirez.sy.yale.edu>
Reply-To: mrami@minerva.cis.yale.edu
To: Bruce Evans <bde@zeta.org.au>
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: <Pine.BSF.3.91.950922114044.1754A-100000@mramirez.sy.yale.edu>
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 <freebsd-current@freebsd.org>; 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: <m0swBH8-000r3uC@main.statsci.com>
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 <scott@statsci.com>
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 <current@freebsd.org>; 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" <ugen@latte.worldbank.org>
cc: current@freebsd.org
Subject: Re: IP accounting
In-reply-to: Your message of "Fri, 22 Sep 1995 10:30:51 PDT."
<Chameleon.4.00.4.950922103134.ugen@ugen>
Date: Fri, 22 Sep 1995 10:02:26 -0700
From: Paul Traina <pst@shockwave.com>
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 <current@freebsd.org>; 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" <vak@crox.net.kiae.su>
To: current@freebsd.org
Subject: [patch] make wdprobe to recognize single-drive ATAPI CD-ROM configurations
Message-ID: <Pine.BSF.3.91.950922220240.262A-100000@crox.net.kiae.su>
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 <vak@cronyx.msk.su>
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 <current@freebsd.org>; 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" <vak@crox.net.kiae.su>
To: current@freebsd.org
Subject: [patch] wcd.c version 1.6
Message-ID: <Pine.BSF.3.91.950922220641.274A-100000@crox.net.kiae.su>
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 <vak@cronyx.msk.su>
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 <freebsd-current@freebsd.org>; 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 <brian@mediacity.com>
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 <swallace@ece.uci.edu>
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 <Intel 82437 (Triton)> rev 1 on pci0:0
chip1 <Intel 82371 (Triton)> 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 <current@freebsd.org>; 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" <rgrimes@GndRsh.aac.dev.com>
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 <current@FreeBSD.org>; 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: <AAqCmOmWK0@crox.net.kiae.su>
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 <vak@cronyx.msk.su>
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 <nathan@netrail.net>
To: "Ugen J.S.Antsilevich" <ugen@latte.worldbank.org>
cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, davidg@Root.COM,
Gary Palmer <gary@palmer.demon.co.uk>, questions@freebsd.org,
current@freebsd.org
Subject: Re: IP accounting
In-Reply-To: <Chameleon.4.00.4.950922103134.ugen@ugen>
Message-ID: <Pine.LNX.3.91.950922151223.27916A-100000@netrail.net>
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 <current@freebsd.org>; 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" <ugen@latte.worldbank.org>
Subject: Re: IP accounting
To: Paul Traina <pst@Shockwave.COM>
Cc: current@freebsd.org
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.00.4.950922151434.ugen@ugen>
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 <freebsd-current@freefall.FreeBSD.org>; 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" <kuku@gilberto.physik.RWTH-Aachen.DE>
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 <freebsd-current@FreeBSD.org>; 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 <j@uriah.heep.sax.de>
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 <j@uriah.heep.sax.de>
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: <Pine.LNX.3.91.950921214059.2536B-100000@netrail.net> 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 <current@freebsd.org>; 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 <swallace@ece.uci.edu>
"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 <swallace@ece.uci.edu>
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 <Intel 82437 (Triton)> rev 1 on pci0:0
} chip1 <Intel 82371 (Triton)> 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 <se@ZPR.Uni-Koeln.DE>
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 <freebsd-current@FreeBSD.org>; 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 <peter@haywire.DIALix.COM>
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 <freebsd-current@FreeBSD.org>; 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 <j@uriah.heep.sax.de>
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: <m0swBH8-000r3uC@main.statsci.com> 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 <freebsd-current@freebsd.org>; 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: <m0swHbS-000r3tC@main.statsci.com>
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 <scott@statsci.com>
Sender: owner-current@freebsd.org
Precedence: bulk
J Wunsch <j@uriah.heep.sax.de> 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 <freebsd-current@FreeBSD.ORG>; 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 <freebsd-current@FreeBSD.ORG>; 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 <j@uriah.heep.sax.de>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@FreeBSD.ORG>; 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 <freebsd-current@FreeBSD.ORG>; 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 <j@uriah.heep.sax.de>
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 <current@freebsd.org>; 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 <roberto@keltia.Freenix.FR>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Sat, 23 Sep 1995 14:32:58 +0200
From: Wolfram Schneider <wosch@cs.tu-berlin.de>
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 <freebsd-current@freebsd.org>; 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 <peter>
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: <owner-current@freebsd.org>
RCPT To: <freebsd-current@uriah.heep.sax.de>
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 <freebsd-current@freefall.cdrom.com>; 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 <current@freefall.FreeBSD.org>; 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" <rdm@ic.net>
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 <current@freefall.FreeBSD.org>; 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 <jehamby@lightside.com>
X-Sender: jehamby@localhost
To: Rob Misiak <rdm@ic.net>
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: <Pine.BSF.3.91.950923135741.2132A-100000@localhost>
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 <freebsd-current@freefall.cdrom.com>; 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 <freebsd-current@freefall.freebsd.org>; 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 <tommy@inlab.m.eunet.de>
To: freebsd-current@freefall.freebsd.org
Subject: Any coincidence between bug report 688 and the SIG11 problem ?
Message-ID: <Pine.BSF.3.91.950923183614.798A-100000@inlab.m.eunet.de>
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 <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 <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 <freebsd-current@freefall.freebsd.org>; 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 <j@uriah.heep.sax.de>
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 <freebsd-current@freefall.cdrom.com>; 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 <j@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)
> 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 <current@freebsd.org>; 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 <jehamby@lightside.com>
X-Sender: jehamby@localhost
To: "Serge V.Vakulenko" <vak@crox.net.kiae.su>
cc: current@freebsd.org
Subject: Re: [patch] wcd.c version 1.6
In-Reply-To: <Pine.BSF.3.91.950922220641.274A-100000@crox.net.kiae.su>
Message-ID: <Pine.BSF.3.91.950923175317.191A-100000@localhost>
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 <freebsd-current@freefall.cdrom.com>; 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 <freebsd-current@freefall.freebsd.org>; 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 <chuckr@eng.umd.edu>
To: James Leppek <jleppek@suw2k.ess.harris.com>
cc: freebsd-current@freefall.freebsd.org
Subject: Re: netscape
In-Reply-To: <9509240159.AA07525@borg.ess.harris.com>
Message-ID: <Pine.SUN.3.91.950923221727.4519A-100000@cappuccino.eng.umd.edu>
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 <freebsd-current@freefall.freebsd.org>; 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" <rgrimes@GndRsh.aac.dev.com>
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: <Pine.BSF.3.91.950923183614.798A-100000@inlab.m.eunet.de> 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 <freebsd-current@freefall.freebsd.org>; 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 <nate@rocky.sri.MT.net>
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