From owner-freebsd-current Sun Jul 23 04:17:17 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id EAA28761
for current-outgoing; Sun, 23 Jul 1995 04:17:17 -0700
Received: from vistec.com (luna.vistec.com [194.64.40.71])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id EAA28755
for <freebsd-current@freebsd.org>; Sun, 23 Jul 1995 04:17:14 -0700
Received: by vistec.com (Smail3.1.28.1 #10)
id m0sZz3L-0001ItC; Sun, 23 Jul 95 13:18 MET DST
Message-Id: <m0sZz3L-0001ItC@vistec.com>
Date: Sun, 23 Jul 95 13:18 MET DST
From: n6156@vistec.com (Marcus John)
To: freebsd-current@freebsd.org
Subject: Boot problems with WD 8003
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: current-owner@freebsd.org
Precedence: bulk
Hi,
I often get "ed0 device timeout"-errors directly after booting up my 2.0
or 2.0.5 release. My machine is eqipped with a WD 8003 compatible :-).
Surprisingly after I load a Packet-driver in DOS mode the problem
disappears. Unfortuately I have no source for this rather old driver.
Perhaps there is already fix for this problem (I joined this maillist on July
ยด95)
marcus.john@wiesbaden.netsurf.de
From owner-freebsd-current Sun Jul 23 12:55:06 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id MAA11239
for current-outgoing; Sun, 23 Jul 1995 12:55:06 -0700
Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id MAA11230
for <current@freebsd.org>; Sun, 23 Jul 1995 12:55:00 -0700
Received: by sovcom.kiae.su id AA01605
(5.65.kiae-1 for current@freebsd.org); Sun, 23 Jul 1995 22:52:28 +0300
Received: by sovcom.KIAE.su (UUMAIL/2.0); Sun, 23 Jul 95 22:52:28 +0300
Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id XAA00564 for current@freebsd.org; Sun, 23 Jul 1995 23:48:49 +0400
To: current@freebsd.org
Message-Id: <KHXUg4maY2@astral.msk.su>
Organization: Olahm Ha-Yetzirah
Date: Sun, 23 Jul 1995 23:48:49 +0400 (MSD)
X-Mailer: Mail/@ [v2.40 FreeBSD]
From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka
"Andrey A. Chernov, Black Mage" <ache@astral.msk.su>
X-Class: Fast
Subject: does xdr_float addition requires minor number bumping or what?
Lines: 6
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 309
Sender: current-owner@freebsd.org
Precedence: bulk
Subj. says all.
--
Andrey A. Chernov : And I rest so composedly, /Now, in my bed,
ache@astral.msk.su : That any beholder /Might fancy me dead -
FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead.
RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849
From owner-freebsd-current Sun Jul 23 17:22:17 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id RAA20806
for current-outgoing; Sun, 23 Jul 1995 17:22:17 -0700
Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id RAA20798
for <current@freebsd.org>; Sun, 23 Jul 1995 17:21:54 -0700
Received: from localhost.cs.tu-berlin.de ([130.149.1.123]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id CAA08899; Mon, 24 Jul 1995 02:13:06 +0200
Received: (from w@localhost) by localhost (8.6.9/8.6.9) id MAA01071; Sun, 23 Jul 1995 12:09:09 +0200
Date: Sun, 23 Jul 1995 12:09:09 +0200
From: Wolfram Schneider <w@cs.tu-berlin.de>
Message-Id: <199507231009.MAA01071@localhost>
To: current@freebsd.org, joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Subject: Re: New options for lastcomm(1)
In-Reply-To: <199507211047.MAA21429@uriah.heep.sax.de>
References: <199507210926.CAA11990@gndrsh.aac.dev.com>
<199507211047.MAA21429@uriah.heep.sax.de>
Reply-to: Wolfram Schneider <wosch@cs.tu-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: current-owner@freebsd.org
Precedence: bulk
J. Wunsch writes:
>As Rodney W. Grimes wrote:
>>
>> > The additions would make sense for me.
>>
>> Find someone running accounting to review your ``cleanedup'' diff
>> and I am all for addeded functionality to lastcomm as a 2 mintue
>> read of the current lastcomm man pages shows it to be seriously
>> lacking in functionality of just what data it can produce :-(.
>
>So who is running accounting? (Or can someone explain me in a
>nutshell what i'd have to setup? I'd try it myself, even though i
>cannot bill someone, it's at least interesting. ;-)
I use accounting as poor man's (k)trace, for debugging and
optimization of shell/perl scripts.
Wolfram
From owner-freebsd-current Sun Jul 23 18:31:12 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id SAA22639
for current-outgoing; Sun, 23 Jul 1995 18:31:12 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id SAA22633
for <current@freebsd.org>; Sun, 23 Jul 1995 18:31:09 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA17222; Sun, 23 Jul 1995 18:30:40 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507240130.SAA17222@gndrsh.aac.dev.com>
Subject: Re: New options for lastcomm(1)
To: wosch@cs.tu-berlin.de
Date: Sun, 23 Jul 1995 18:30:40 -0700 (PDT)
Cc: current@freebsd.org, joerg_wunsch@uriah.heep.sax.de
In-Reply-To: <199507231009.MAA01071@localhost> from "Wolfram Schneider" at Jul 23, 95 12:09:09 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: 889
Sender: current-owner@freebsd.org
Precedence: bulk
>
> J. Wunsch writes:
> >As Rodney W. Grimes wrote:
> >>
> >> > The additions would make sense for me.
> >>
> >> Find someone running accounting to review your ``cleanedup'' diff
> >> and I am all for addeded functionality to lastcomm as a 2 mintue
> >> read of the current lastcomm man pages shows it to be seriously
> >> lacking in functionality of just what data it can produce :-(.
> >
> >So who is running accounting? (Or can someone explain me in a
> >nutshell what i'd have to setup? I'd try it myself, even though i
> >cannot bill someone, it's at least interesting. ;-)
>
> I use accounting as poor man's (k)trace, for debugging and
> optimization of shell/perl scripts.
Why do that when we have ktrace in FreeBSD???
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
From owner-freebsd-current Sun Jul 23 20:18:14 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id UAA26846
for current-outgoing; Sun, 23 Jul 1995 20:18:14 -0700
Received: from po2.andrew.cmu.edu (PO2.ANDREW.CMU.EDU [128.2.10.102])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id UAA26838
for <freebsd-current@freefall.cdrom.com>; Sun, 23 Jul 1995 20:18:12 -0700
Received: (from postman@localhost) by po2.andrew.cmu.edu (8.6.12/8.6.12) id XAA11319 for freebsd-current@freefall.cdrom.com; Sun, 23 Jul 1995 23:18:07 -0400
Received: via switchmail; Sun, 23 Jul 1995 23:18:06 -0400 (EDT)
Received: from unix19.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.Ek4l2Du00YUvI0flRm>;
Sun, 23 Jul 1995 23:16:32 -0400 (EDT)
Received: from unix19.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr15/tj2n/.Outgoing/QF.Ek4l2Bq00YUvIX:lV3>;
Sun, 23 Jul 1995 23:16:30 -0400 (EDT)
Received: from VUI.Andrew.3.70.CUILIB.3.45.SNAP.NOT.LINKED.unix19.andrew.cmu.edu.sun4c.411
via MS.5.6.unix19.andrew.cmu.edu.sun4c_411;
Sun, 23 Jul 1995 23:16:29 -0400 (EDT)
Message-ID: <Ik4l2Bm00YUv0X_lMF@andrew.cmu.edu>
Date: Sun, 23 Jul 1995 23:16:29 -0400 (EDT)
From: Tao Jiang <tj2n+@andrew.cmu.edu>
To: freebsd-current@freefall.cdrom.com
Subject: Problem in using sup to get current
Sender: current-owner@FreeBSD.org
Precedence: bulk
Hi,
I don't know if I post at the right place. I just installed
freebsd 2.0.5 at my home machie by using PPP to transfer
the whole distrubition and it successfully load the distrubition
to my computer from ftp.freebsd.org.
It's a great work! Thanks.
But after that, when I tried to use sup to sup the current source
tree, I never got it work. (I followed the sup faq) The problem
I found at my machine is that after I use PPP to connect to the
internet, I can use ftp, telnet to connect to other site but
never connected to freefall.cdrom.com by anonymous ftp.
(the ftp just hung as soon as I entered "anonymous" at the
username prompt. Don't know what's wrong here? (By the
way, if I used dos and use dos's slip to connect to the internet,
then there is no problem at all to connect to freefall.cdrom.com).
Any one can point out what might be the cause of my setting?
Thanks!
From owner-freebsd-current Sun Jul 23 23:05:12 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id XAA03364
for current-outgoing; Sun, 23 Jul 1995 23:05:12 -0700
Received: from throck.cdrom.com (throck.cdrom.com [192.216.222.24])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id XAA03354
for <current@freefall.cdrom.com>; Sun, 23 Jul 1995 23:05:07 -0700
Received: (from jkh@localhost) by throck.cdrom.com (8.6.11/8.6.9) id XAA00457 for current@freefall; Sun, 23 Jul 1995 23:05:51 -0700
Date: Sun, 23 Jul 1995 23:05:51 -0700
From: "Jordan K. Hubbard" <jkh@freebsd.org>
Message-Id: <199507240605.XAA00457@throck.cdrom.com>
To: current@freefall.cdrom.com
Subject: Interesting NFS problem with -current
Sender: current-owner@freebsd.org
Precedence: bulk
Scenario: Several hosts with cross-mount privs managed by AMD. Host foo
exports its cdrom drive to host bar, which can see it in /host/foo/cdrom.
So far, so good. Now say that foo unmounts the CD in the drive and mounts
a new one. Host bar now sees:
<some command>: /host/foo/cdrom: Stale NFS file handle
In response to any access to the newly mounted CD. At the
same time as the access, host foo prints:
fhtovp: file start miss 60 vs 20
On its system console.
I figure this is something to do with NFS v3, but perhaps the data
is of use to someone working in that area.
Jordan
From owner-freebsd-current Mon Jul 24 03:58:02 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id DAA15501
for current-outgoing; Mon, 24 Jul 1995 03:58:02 -0700
Received: from minnow.render.com (render.demon.co.uk [158.152.30.118])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id DAA15493
; Mon, 24 Jul 1995 03:57:57 -0700
Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id MAA12553; Mon, 24 Jul 1995 12:00:56 +0100
Date: Mon, 24 Jul 1995 12:00:54 +0100 (BST)
From: Doug Rabson <dfr@render.com>
To: "Jordan K. Hubbard" <jkh@freebsd.org>
cc: current@freefall.cdrom.com
Subject: Re: Interesting NFS problem with -current
In-Reply-To: <199507240605.XAA00457@throck.cdrom.com>
Message-ID: <Pine.BSF.3.91.950724115416.12542C-100000@minnow.render.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
On Sun, 23 Jul 1995, Jordan K. Hubbard wrote:
> Scenario: Several hosts with cross-mount privs managed by AMD. Host foo
> exports its cdrom drive to host bar, which can see it in /host/foo/cdrom.
> So far, so good. Now say that foo unmounts the CD in the drive and mounts
> a new one. Host bar now sees:
>
> <some command>: /host/foo/cdrom: Stale NFS file handle
>
> In response to any access to the newly mounted CD. At the
> same time as the access, host foo prints:
>
> fhtovp: file start miss 60 vs 20
>
> On its system console.
>
> I figure this is something to do with NFS v3, but perhaps the data
> is of use to someone working in that area.
The problem is that cd9660 filehandles are only valid for one particular
disk. The handle for the old disk was being used for the new one and the
system was, correctly, complaining. The extra printf shouldn't really be
there but it does no harm. This shouldn't be affected by v3 since the
filehandle concepts are the same in v2.
When a server changes a disk in its CD drive, all the clients should remount
the filesystem to get a new root filehandle. With AMD, the only thing you
can do is to reduce the timeout on the client or forcible unmount it using
something like:
amq -u /host/foo/cdrom
--
Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com
Phone: +44 171 251 4411
FAX: +44 171 251 0939
From owner-freebsd-current Mon Jul 24 04:24:37 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id EAA16355
for current-outgoing; Mon, 24 Jul 1995 04:24:37 -0700
Received: from minnow.render.com (render.demon.co.uk [158.152.30.118])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id EAA16345
for <freebsd-current@freebsd.org>; Mon, 24 Jul 1995 04:24:28 -0700
Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id LAA12501; Mon, 24 Jul 1995 11:50:15 +0100
Date: Mon, 24 Jul 1995 11:50:14 +0100 (BST)
From: Doug Rabson <dfr@render.com>
To: Terry Lambert <terry@cs.weber.edu>
cc: peter@haywire.dialix.com, freebsd-current@freebsd.org
Subject: Re: what's going on here? (NFSv3 problem?)
In-Reply-To: <9507212036.AA06811@cs.weber.edu>
Message-ID: <Pine.BSF.3.91.950724112353.12542B-100000@minnow.render.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
On Fri, 21 Jul 1995, Terry Lambert wrote:
> > NFSv3 defines a mechanism to validate the cookies used to read directory
> > entries. Each readdir request returns a set of directory entries, each
> > with a cookie which can be used to start another readdir just after the
> > entry. To read from the beginning of the directory, one passes a NULL
> > cookie.
> >
> > NFSv3 also returns a 'cookie verifier' which must be passed with the next
> > readdir, along with the cookie representing the place to read from. If the
> > directory block was compacted, then the server should use the verifier to
> > detect this and can return an error to the client to force it to retry the
> > read from the beginning of the directory.
>
> Most file systems do not provide a generation count on directory blocks
> with which to validate the "cookie".
>
> With that in mind, the "cookie" is typically interpreted either as an
> entry offset or as a byte offset of entry, either in the block or in
> the directory.
The NFSv3 code in -current uses the modification time of the directory as
the verifier. This is perhaps a slightly pessimistic solution but it
should detect compactions. The client reacts to bad cookie errors by
flushing its cached information about the directory. This seems to be a
reasonable reaction to the directory being modified.
Can the ufs code ever compact a directory block *without* the
modification time of the directory changing? Presumably it only ever
does this as a result of some other operation on the directory.
>
> It is this use which one uses to resynchronize entries in the case of
> block compaction, with the inevitable problem potential this has
> associated with it (duplicate vs. skipped entries, as you point out).
>
> > > The buffer crap that got done to avoid a file system top end user
> > > presentation layer is totally bogus, and remains the cause of the
> > > prblem. If no one is interested in fixing it, I suggest reducing
> > > the transfer size to the page size or smaller.
> >
> > I can't parse this one.
>
> The stat structure passed around internally is larger than the stat
> structure expected by NFS.
>
> Rather than fix the view of things at the time it was exported to
> NFS, the internal buffer representation for all file system capable
> of being exported was changed.
>
> I can't say I'm not glad that this is coming back to haunt us.
>
At the time, I was more interested in fixing the completely stupid
assumption the NFS server was making about the FS implementation which
only ever worked for UFS. Adding a whole new layer of code between NFS
and the VFS would have added maintenance problems, consistency problems
(we would be caching directory information; when is the cache invalid?
when should stuff be removed from it?) and needless complication.
I added code as part of this fix which would deal with unaligned UFS
directory reads, more or less on the lines of the approach you suggested.
The FS reads from the aligned address. NFS then finds from the information
returned by the FS the first entry whose cookie is greater or equal to the
cookie sent by the client. The only restriction this places on VFS for
directory cookies is that they increase monotonically in a directory.
In the case of a compacted directory block, the client may recieve
filenames it has already seen or it may miss a few entries. It will
never recieve corrupt information.
> > > And, of course, at the same time eat the increased and otherwise
> > > unnecessary overhead in the read/write path transfers that will
> > > result from doing this "fix".
> >
> > I don't think that any fix is needed. The NFSv2 behaviour is adequate
> > and NFSv3 has the mechanism to detect this problem.
>
> This is the "drop the buffer size" fix, not the detection fix (which would
> be unnecessary if the buffer size "fix" wasn't there).
>
>
> It should also be noted that NFSv3 classifies the blocked directory
> entry retrieval as an *optional* implementation for the server, and the
> problem would also go away were the option declined and versioning more
> strictly enforced.
>
> I don't think this would be the cannonically correct thing to do.
The current v2 server has an adequate strategy for dealing with directory
compaction for all read sizes, IMHO. The directory verifier is *not*
optional in NFSv3. The only optional part AFAIK is the use of READDIRPLUS by
the client to read file attributes with the names. Both READDIR and
READDIRPLUS *must* implement a verifier strategy.
A server *can* choose to return zero for a verifier but only if the
cookies it generates are *always* valid, e.g. for read-only media. From
rfc1813, section 3.3.16:
One implementation of the cookie-verifier mechanism might
be for the server to use the modification time of the
directory. This might be overly restrictive, however. A
better approach would be to record the time of the last
directory modification that changed the directory
organization in a way that would make it impossible to
reliably interpret a cookie. Servers in which directory
cookies are always valid are free to use zero as the
verifier always.
--
Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com
Phone: +44 171 251 4411
FAX: +44 171 251 0939
From owner-freebsd-current Mon Jul 24 04:59:39 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id EAA17372
for current-outgoing; Mon, 24 Jul 1995 04:59:39 -0700
Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id EAA17366
for <current@freebsd.org>; Mon, 24 Jul 1995 04:59:37 -0700
Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id EAA17746 for <current@freebsd.org>; Mon, 24 Jul 1995 04:59:29 -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 NAA21435; Mon, 24 Jul 1995 13:45:15 +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 NAA09809; Mon, 24 Jul 1995 13:45:02 +0200
Date: Mon, 24 Jul 1995 13:45:02 +0200
Message-Id: <199507241145.NAA09809@caramba.cs.tu-berlin.de>
To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Cc: current@freebsd.org, joerg_wunsch@uriah.heep.sax.de
Subject: Re: New options for lastcomm(1)
In-Reply-To: <199507240130.SAA17222@gndrsh.aac.dev.com>
References: <199507231009.MAA01071@localhost>
<199507240130.SAA17222@gndrsh.aac.dev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: current-owner@freebsd.org
Precedence: bulk
Rodney W. Grimes writes:
>> I use accounting as poor man's (k)trace, for debugging and
>> optimization of shell/perl scripts.
>
>Why do that when we have ktrace in FreeBSD???
ktrace is to low level :-)
ktrace.out grow rapidly. Ktrace is slow, and you must call ktrace
explict. Accounting run in 'background' for all processes. I don't
want know which system call start sh(1), I want see how many subshell
(heavy system time) or if perl use exec instead 'sh -c'. E.g. start
accounting and make world. You see thousands sh(1), test(1), cpp(1),
gzip(1) etc.
Wolfram
From owner-freebsd-current Mon Jul 24 10:03:32 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA27350
for current-outgoing; Mon, 24 Jul 1995 10:03:32 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id KAA27343
for <current@FreeBSD.org>; Mon, 24 Jul 1995 10:03:29 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA25622; Tue, 25 Jul 1995 02:57:57 +1000
Date: Tue, 25 Jul 1995 02:57:57 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507241657.CAA25622@godzilla.zeta.org.au>
To: ache@astral.msk.su, current@FreeBSD.org
Subject: Re: does xdr_float addition requires minor number bumping or what?
Sender: current-owner@FreeBSD.org
Precedence: bulk
It requires bumping of the minor version number of libc.so but I think
we intend to only bump it (if necessary) before releases.
Bruce
From owner-freebsd-current Mon Jul 24 10:04:00 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA27404
for current-outgoing; Mon, 24 Jul 1995 10:04:00 -0700
Received: from FIMP01.fim.uni-linz.ac.at (gopher.fim.uni-linz.ac.at [140.78.100.24])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id KAA27393
; Mon, 24 Jul 1995 10:03:50 -0700
Received: by FIMP01.fim.uni-linz.ac.at (5.57/Ultrix3.0-C)
id AA24558; Mon, 24 Jul 95 19:09:50 +0200
Received: from scotty (scotty [192.168.1.1]) by uhura (8.6.11/8.6.9) with ESMTP id SAA00151; Mon, 24 Jul 1995 18:21:30 +0200
Received: (from cg@localhost) by scotty (8.6.11/8.6.9) id SAA00172; Mon, 24 Jul 1995 18:22:48 +0200
Date: Mon, 24 Jul 1995 18:22:48 +0200 (MET DST)
From: "DI. Christian Gusenbauer" <cg@scotty.edvz.uni-linz.ac.at>
Reply-To: cg@fimp01.fim.uni-linz.ac.at
To: FreeBSD Current <freebsd-current@freebsd.org>,
FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject: panic: vm_page_free with -current
Message-Id: <Pine.BSF.3.91.950724181556.164A-100000@scotty>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
Hi!
A kernel built today panics while booting the machine. I get the following
messages:
ncr0 targ 1?: ERROR (81:40) (8-28-0) (8/13) @(1008:0).
reg: da 10 c0 13 47 8 1 1f 1 8 81 28 80 0 8 0
ncr0: restart (fatal error).
sd0 (ncr0:1:0): COMMAND FAILED (9 ff) @f0670200
sd0 (ncr0:1:0): COMMAND FAILED (9 ff) @f0670a00
vm_page_free: offset(0), bmapped(1), busy(0), PG_BUSY(0)
panic vm_page_free: freeing busy page
I don't know if the panic is triggerd by the ncr fault or vice versa. The
only thing I really know is, that my last kernel (7-15-95) works fine :-)
Any clues?
Christian.
--
Christian Gusenbauer "The best way you can accelerate windows,
cg@fimp01.fim.uni-linz.ac.at is through one." - Ivan Wheelwright
From owner-freebsd-current Mon Jul 24 10:44:29 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA29724
for current-outgoing; Mon, 24 Jul 1995 10:44:29 -0700
Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id KAA29716
for <current@freebsd.org>; Mon, 24 Jul 1995 10:44:28 -0700
Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA05123; Mon, 24 Jul 1995 13:44:27 -0400
Date: Mon, 24 Jul 1995 13:44:27 -0400
From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
Message-Id: <9507241744.AA05123@halloran-eldar.lcs.mit.edu>
To: current@freebsd.org
Subject: bsd.{info,doc}.mk change
Sender: current-owner@freebsd.org
Precedence: bulk
I am about to commit a change that causes Info files and traditional
documents to get compressed before they are installed, thus saving a
potentially significant amount of space. Speak up within a day or
forever hold your peace...
-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 Jul 24 11:39:56 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id LAA04670
for current-outgoing; Mon, 24 Jul 1995 11:39:56 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id LAA04664
for <current@freebsd.org>; Mon, 24 Jul 1995 11:39:54 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA07658; Mon, 24 Jul 95 12:32:14 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507241832.AA07658@cs.weber.edu>
Subject: Re: New options for lastcomm(1)
To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes)
Date: Mon, 24 Jul 95 12:32:12 MDT
Cc: wosch@cs.tu-berlin.de, current@freebsd.org, joerg_wunsch@uriah.heep.sax.de
In-Reply-To: <199507240130.SAA17222@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 23, 95 06:30:40 pm
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@freebsd.org
Precedence: bulk
> > I use accounting as poor man's (k)trace, for debugging and
> > optimization of shell/perl scripts.
>
> Why do that when we have ktrace in FreeBSD???
Sean Eric Fagan has modifications to procfs and a user space truss
program (a non-'k' trace).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Mon Jul 24 13:20:46 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id NAA09430
for current-outgoing; Mon, 24 Jul 1995 13:20:46 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id NAA09422
for <current@freebsd.org>; Mon, 24 Jul 1995 13:20:42 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id NAA19851; Mon, 24 Jul 1995 13:20:38 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507242020.NAA19851@gndrsh.aac.dev.com>
Subject: Re: bsd.{info,doc}.mk change
To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman)
Date: Mon, 24 Jul 1995 13:20:38 -0700 (PDT)
Cc: current@freebsd.org
In-Reply-To: <9507241744.AA05123@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 24, 95 01:44:27 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: 718
Sender: current-owner@freebsd.org
Precedence: bulk
>
> I am about to commit a change that causes Info files and traditional
> documents to get compressed before they are installed, thus saving a
> potentially significant amount of space. Speak up within a day or
> forever hold your peace...
Yes, please do do this, but could I have a quick look at the diff
before you commit it.
This not only saves disk space, it keeps repeated make worlds from
totally fragmenting /usr/share to death! [Run 5 back to back make
worlds and then look at the file system fragmentation of /usr if
you want to see what I mean.]
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
From owner-freebsd-current Mon Jul 24 14:44:52 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id OAA13399
for current-outgoing; Mon, 24 Jul 1995 14:44:52 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id OAA13393
for <freebsd-current@freebsd.org>; Mon, 24 Jul 1995 14:44:49 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA09885; Mon, 24 Jul 95 15:36:49 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507242136.AA09885@cs.weber.edu>
Subject: Re: what's going on here? (NFSv3 problem?)
To: dfr@render.com (Doug Rabson)
Date: Mon, 24 Jul 95 15:36:48 MDT
Cc: peter@haywire.dialix.com, freebsd-current@freebsd.org
In-Reply-To: <Pine.BSF.3.91.950724112353.12542B-100000@minnow.render.com> from "Doug Rabson" at Jul 24, 95 11:50:14 am
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@freebsd.org
Precedence: bulk
> > Most file systems do not provide a generation count on directory blocks
> > with which to validate the "cookie".
> >
> > With that in mind, the "cookie" is typically interpreted either as an
> > entry offset or as a byte offset of entry, either in the block or in
> > the directory.
>
> The NFSv3 code in -current uses the modification time of the directory as
> the verifier. This is perhaps a slightly pessimistic solution but it
> should detect compactions. The client reacts to bad cookie errors by
> flushing its cached information about the directory. This seems to be a
> reasonable reaction to the directory being modified.
>
> Can the ufs code ever compact a directory block *without* the
> modification time of the directory changing? Presumably it only ever
> does this as a result of some other operation on the directory.
This is a good question.
I can answer it in terms of existing practice and in terms of POSIX time
update semantics requirements.
For UFS, the compaction can only take place when an entry has failed
lookup during creation and is therefore being created (ie: with the
directory locked).
That is, a directory data modification is involved.
Does this mean that directory times will be updated?
Under POSIX, it does not. The modification time update semantics in
POSIX are file-bound. That is, one is not required to update the
times for directories the same as one is required to update the times
for files. The single exception to this is the directory read
operations which must *mark for update* the access time. Note that
this does not require that it have been updated by the time a subsequent
access has taken place.
We can easily envision compaction in a DOS style directory (after all,
this is what Win95 does in order to support long names, effectively),
where since the file names are attributes of the file rather than real
directory contents, such compaction does *not* cause the directory to
be even marked for update!
That is, depending on this behaviour has existing failure modes for
non-POSIX file systems in any case.
I think it is a mistake to assume that the NFS exporting of file
systems should only work when the NFS export is a client of POSIX
file system services (and even then, it depends on "mark for update"
referring to a change of the in core time stamp rather than a real
marking by flagging the in core and on disk times to be updated at
dirty page discard time -- assuming a directory is implemented as a
file at all instead of being considered a logically seperate entity).
All that said, yes, in UFS, it happens to work. Currently. 8-/.
> > The stat structure passed around internally is larger than the stat
> > structure expected by NFS.
> >
> > Rather than fix the view of things at the time it was exported to
> > NFS, the internal buffer representation for all file system capable
> > of being exported was changed.
> >
> > I can't say I'm not glad that this is coming back to haunt us.
>
> At the time, I was more interested in fixing the completely stupid
> assumption the NFS server was making about the FS implementation which
> only ever worked for UFS. Adding a whole new layer of code between NFS
> and the VFS would have added maintenance problems, consistency problems
> (we would be caching directory information; when is the cache invalid?
> when should stuff be removed from it?) and needless complication.
I think the cache issue is seperate. Specifically, directory caching
should be generalized externally to the file system implementations
themselves. Potentially, it should even be a seperate layer, although
the only thing dictating that would be the lack of a filesystem initiated
cache callback mechanism for ensuring coherency. Even then, that's a
problem with the file system under the cache and should be handled in
the file system implementation rather than being hacked around by adding
function call layering everywhere so that it can be omitted for file
systems that might undergo promiscuous changes (ie: NFS, AFS).
The assumptions that NFS made were, indeed *wrong*. But since the issue
was FS implementation independent metadata presentation, the fact is
that the complication would have been purely NFS's problem -- and at
that, it's caused by the statelessness NFS insists on maintaining.
A presentation layer would have added a single function call overhead to
the NFS based ops -- and avoided the buffer size implications that got
strewn about as a result. The layer itself would have disappeared,
all but the single function call dealing with stat, when the call
graph was collapsed in creating the file system instance.
Admittedly, this would have meant dealing with some of the messier
stackability isses then, rather than later.
The other alternative would have been to put off the stackability
issues until later and to eat two copies in the NFS layer (and some
stack allocated buffer space). This actually wouldn't have been that
big of a hit to take in any case, since the bottleneck is the network
(relative to the extra copy time).
Either way, it's really water under the bridge, although I'm going to
be beating on some of the stackability issues in the near future; in
particular, moving the directory cache up to the vnode rather than the
inode layer and going to a per FS type vnode pool to overcome the
inode space limitations imposed by common inode allocation both need
to happen in the near future. Luckily USL has kindly documented SVR4
DNLC (a vnode based directory name lookup cache) for us, though it
is missing the ability to keep negative cache entries (i'll fix that,
though; it's relatively easy even in the USL code).
The stackability issues must be resolved to support both user space
file system developement and source level debugging, and to allow for
general support of a per block file compression layer that operates
only on files, not directories.
> I added code as part of this fix which would deal with unaligned UFS
> directory reads, more or less on the lines of the approach you suggested.
I noticed (and appreciate!) the code there. It helps the restart stuff
immensely. The code pretty much has to be there for a VM86() based
INT 21 redirector to map UFS volumes as DOS drives under VM86() based
DOS emulation in any case. The lack of an opendir/closedir type paradigm
in the DOS FindFirst/FindNext directory scanning routines makes this
especially necessary, unless we wanted to keep around LRU lists of
some finite number of contexts for DOS searches outstanding (what Novell
does in their DOS redirector).
It also allows a "DOS porting interface" for DOS code that does INT 21
access, if the interface is exported at the FS system call layer by using
a VFS layer specific ioctl() for FindFirst/FindNext.
Wine wants this kind of portability API.
> The FS reads from the aligned address. NFS then finds from the information
> returned by the FS the first entry whose cookie is greater or equal to the
> cookie sent by the client. The only restriction this places on VFS for
> directory cookies is that they increase monotonically in a directory.
This is The Right Way. 8-).
> In the case of a compacted directory block, the client may recieve
> filenames it has already seen or it may miss a few entries. It will
> never recieve corrupt information.
Right. I believe it is the responsibility of the client to deal with
this fact. Otherwise we are screwed at the outset regarding kernel
preemption and SMP kernel reentrancy, both short-term issues in terms
of the need to provide file system multithreading.
So I definitely don't have problems with that code.
> The current v2 server has an adequate strategy for dealing with directory
> compaction for all read sizes, IMHO. The directory verifier is *not*
> optional in NFSv3. The only optional part AFAIK is the use of READDIRPLUS by
> the client to read file attributes with the names. Both READDIR and
> READDIRPLUS *must* implement a verifier strategy.
I'm much less concerned with the client side of things, but the verifier
*does* prevent the server from being a chincy minimal implementation, and
that's the important thing. It remains to be seen if using the date
as the verifier is really a valid thing to do for non-POSIX compliant
file system implementaions -- or POSIX complient implementations where
the directory is not a file (NT, VMS, etc.). I think the answer must be
"no".
> A server *can* choose to return zero for a verifier but only if the
> cookies it generates are *always* valid, e.g. for read-only media. From
> rfc1813, section 3.3.16:
>
> One implementation of the cookie-verifier mechanism might
> be for the server to use the modification time of the
> directory. This might be overly restrictive, however. A
> better approach would be to record the time of the last
> directory modification that changed the directory
> organization in a way that would make it impossible to
> reliably interpret a cookie. Servers in which directory
> cookies are always valid are free to use zero as the
> verifier always.
Yes. This speaks to the organization (or rather the lack of it) in the
VFS framework regarding directory vs. file operations. Specifically,
it should be possible to get even callbacks ala Andrew at the presentation
layer such that file system events that affect NFS exported volumes are
in fact propagated to the NFS layer so it can act appropriately.
Obviously, this code isn't there yet. 8-(.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Mon Jul 24 17:25:06 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id RAA27284
for current-outgoing; Mon, 24 Jul 1995 17:25:06 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id RAA27275
for <current@freefall.cdrom.com>; Mon, 24 Jul 1995 17:24:54 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA27766; Tue, 25 Jul 1995 02:22:05 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id CAA24166 for current@freefall.cdrom.com; Tue, 25 Jul 1995 02:39:18 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id MAA05269 for current@freefall.cdrom.com; Mon, 24 Jul 1995 12:58:00 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507241058.MAA05269@uriah.heep.sax.de>
Subject: Re: Interesting NFS problem with -current
To: current@freefall.cdrom.com
Date: Mon, 24 Jul 1995 12:57:59 +0200 (MET DST)
Reply-To: current@freefall.cdrom.com
In-Reply-To: <199507240605.XAA00457@throck.cdrom.com> from "Jordan K. Hubbard" at Jul 23, 95 11:05:51 pm
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
Content-Length: 1218
Sender: current-owner@FreeBSD.org
Precedence: bulk
As Jordan K. Hubbard wrote:
>
> Scenario: Several hosts with cross-mount privs managed by AMD. Host foo
> exports its cdrom drive to host bar, which can see it in /host/foo/cdrom.
> So far, so good. Now say that foo unmounts the CD in the drive and mounts
> a new one. Host bar now sees:
>
> <some command>: /host/foo/cdrom: Stale NFS file handle
>
> In response to any access to the newly mounted CD. At the
> same time as the access, host foo prints:
>
> fhtovp: file start miss 60 vs 20
>
> On its system console.
>
> I figure this is something to do with NFS v3, but perhaps the data
> is of use to someone working in that area.
The decision of the cd9660 code whether some NFS client is accessing a
stale NFS file handle (i.e. one that's been granted for a previous CD)
is rather a crock. I haven't got a good idea on how to solve this
better.
I suspect the generation of stale NFS file handles for removable
sd-type disks might be as broken as well, but it's not as obvious
there as for CDs. Might become a point with the advent of ZIP drives
however.
--
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 Jul 24 18:38:19 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id SAA00509
for current-outgoing; Mon, 24 Jul 1995 18:38:19 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id SAA00502
for <current@freebsd.org>; Mon, 24 Jul 1995 18:38:13 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id SAA02783 for <current@freebsd.org>; Mon, 24 Jul 1995 18:37:20 -0700
To: current@freebsd.org
Subject: Knobs in /etc/sysconfig
Date: Mon, 24 Jul 1995 18:37:19 -0700
Message-ID: <2781.806636239@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@freebsd.org
Precedence: bulk
I don't know if Rod is still working on this stuff, but given the
amount of time that's elapsed I'd say that the statute of limitations
any developer gets for "locking" things in -current has run out, so
it's open season again in /usr/src/etc/etc.i386! :-)
Persuant to that, I'd like to add knobs in /etc/sysconfig and
/etc/<somefile> for turning on such extra services as SNMP, a web
server, PCNFS, Samba, etc. This may seem superfluous to some, but
believe me - I won't be able to make FreeBSD truly plug-n-pray for
many important tasks without such instrumentation and I think that
it's pretty important to achieve that at some point.
For example (from my own setup):
/etc/sysconfig:
# set to NO if you don't want CMU SNMP services
snmp_flags="public ro"
/etc/netstart:
if [ "x$snmp_flags" != "xNO" -a -x /usr/local/libexec/snmpd ]; then
echo 'snmp daemon: ' /usr/local/libexec/snmpd $snmp_flags &
fi
And so forth. Rather than seeing this bloom out of control, I tend to
suspect more that this will plateau out at around 10-15 additional
services max and give us easy instrumentation of a whole range of
important services. Activation than then be reduced to a simple
pkg_add, a tweak in /etc/sysconfig and the possible setup of a
configuration file (which would also be handled through the auspices
of whatever program did the /etc/sysconfig tweaking, probably).
Comments?
Jordan
From owner-freebsd-current Mon Jul 24 19:51:25 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA03214
for current-outgoing; Mon, 24 Jul 1995 19:51:25 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA03207
for <current@freebsd.org>; Mon, 24 Jul 1995 19:51:21 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA20607; Mon, 24 Jul 1995 19:50:53 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507250250.TAA20607@gndrsh.aac.dev.com>
Subject: Re: Knobs in /etc/sysconfig
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Mon, 24 Jul 1995 19:50:53 -0700 (PDT)
Cc: current@freebsd.org
In-Reply-To: <2781.806636239@time.cdrom.com> from "Jordan K. Hubbard" at Jul 24, 95 06:37:19 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: 3407
Sender: current-owner@freebsd.org
Precedence: bulk
>
> I don't know if Rod is still working on this stuff, but given the
> amount of time that's elapsed I'd say that the statute of limitations
> any developer gets for "locking" things in -current has run out, so
> it's open season again in /usr/src/etc/etc.i386! :-)
I have never locked it, there have been 8 commits to the files I
am working on, I have merger the commit, or tossed it as I had
it solved in another way.
I will say, that last time Jordan had fun in /etc/rc* it was a bloody
mess to clean up. Something like that done again will upset me very
much, though from the looks of what you want to add it does not
go there anyway, and/or would be nothing more than a block add to
what is already there.
Another thing, /etc/rc* is a delacate balancing act as far as just
what you do when, what we have now is functionaly for most people
but has some sequence problems for others. These are non-trival
problems to test and require about 15 different machine configurations
to do regression testing. Since I only have 1 machine to play with
long term on this type of stuff testing goes very very slow.
> Persuant to that, I'd like to add knobs in /etc/sysconfig and
> /etc/<somefile> for turning on such extra services as SNMP, a web
> server, PCNFS, Samba, etc. This may seem superfluous to some, but
> believe me - I won't be able to make FreeBSD truly plug-n-pray for
> many important tasks without such instrumentation and I think that
> it's pretty important to achieve that at some point.
>
> For example (from my own setup):
>
> /etc/sysconfig:
>
> # set to NO if you don't want CMU SNMP services
> snmp_flags="public ro"
>
> /etc/netstart:
>
> if [ "x$snmp_flags" != "xNO" -a -x /usr/local/libexec/snmpd ]; then
> echo 'snmp daemon: ' /usr/local/libexec/snmpd $snmp_flags &
> fi
snmpd should not be started from /etc/netstart. /etc/netstat is only
for bringing the network on line. It took a lot of work initially by
pts to get the crap out of there, and more cleanup by me to make it
work once it was. Do not start daemons in /etc/netstart that are not
network routing daemons [if you notice those are the only network
related daemons in /etc/netstart, and they are there as you need them
to have really made the network start].
Also /usr/local stuff does not really belong in there, a site may very
well have to modify that path (gated is that way now, but that is dead
in my configuration and sysconfig now $gated_bin and $gatedflags, if
gated_bin defaults to /usr/local/sbin/gated, but at least you can
override it without editing netstart.
> And so forth. Rather than seeing this bloom out of control, I tend to
> suspect more that this will plateau out at around 10-15 additional
> services max and give us easy instrumentation of a whole range of
> important services. Activation than then be reduced to a simple
> pkg_add, a tweak in /etc/sysconfig and the possible setup of a
> configuration file (which would also be handled through the auspices
> of whatever program did the /etc/sysconfig tweaking, probably).
>
> Comments?
Why not appended it to /etc/rc.local, and append the variable settings
in /etc/sysconfig.local, have /etc/sysconfig source /etc/sysconfig.local
at the end of it.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
From owner-freebsd-current Mon Jul 24 19:58:47 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA03568
for current-outgoing; Mon, 24 Jul 1995 19:58:47 -0700
Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA03562
for <current@FreeBSD.org>; Mon, 24 Jul 1995 19:58:41 -0700
Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id MAA01538; Tue, 25 Jul 1995 12:46:46 +0930
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Message-Id: <199507250316.MAA01538@genesis.atrad.adelaide.edu.au>
Subject: Re: Knobs in /etc/sysconfig
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Tue, 25 Jul 1995 12:46:46 +0930 (CST)
Cc: current@FreeBSD.org
In-Reply-To: <2781.806636239@time.cdrom.com> from "Jordan K. Hubbard" at Jul 24, 95 06:37:19 pm
Content-Type: text
Content-Length: 1048
Sender: current-owner@FreeBSD.org
Precedence: bulk
Jordan K. Hubbard stands accused of saying:
> /etc/sysconfig:
>
> # set to NO if you don't want CMU SNMP services
> snmp_flags="public ro"
>
> /etc/netstart:
>
> if [ "x$snmp_flags" != "xNO" -a -x /usr/local/libexec/snmpd ]; then
> echo 'snmp daemon: ' /usr/local/libexec/snmpd $snmp_flags &
> fi
(Unless I'm mistraken, the 'x' is a historic wart, and test can now handle
empty arguments...)
> Comments?
Please ensure that the default "yes" values are documented in the comments
preceeding each knob; preferably in some standard format, eg:
# default: <value>
(Yes, I'm tinkering with a sticky editor. No, its nowhere near ready)
> Jordan
--
]] 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 [[
From owner-freebsd-current Mon Jul 24 20:06:51 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id UAA04025
for current-outgoing; Mon, 24 Jul 1995 20:06:51 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id UAA04017
for <freebsd-current@freefall.cdrom.com>; Mon, 24 Jul 1995 20:06:45 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA07991; Tue, 25 Jul 1995 13:06:04 +1000
Date: Tue, 25 Jul 1995 13:06:04 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507250306.NAA07991@godzilla.zeta.org.au>
To: freebsd-current@freefall.cdrom.com, kuku@gilberto.physik.rwth-aachen.de
Subject: Re: panic after fdformat/disklabel
Sender: current-owner@FreeBSD.org
Precedence: bulk
[Redirected from hackers to current]
I just tried the following
>fdformat /dev/rfd0a
><formatted floppy>
>disklabel -w -r fd0d floppy3
>(was not sure if the syntax was correct)
fd0d is bogus, should be fd0.
>*poof*
>Fatal trap 12: page fault while in kernel mode
>...
This is easy to duplicate by reading from /dev/rfd0 using
char buf[8192];
main() { lseek(0, 8192ll, 0); read(0, buf, sizeof buf); }
but for some reason it isn't easy to duplicate by reading using dd.
The lseek is to avoid the magic label sector but doesn't make any
difference.
Bruce
From owner-freebsd-current Mon Jul 24 20:22:03 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id UAA04823
for current-outgoing; Mon, 24 Jul 1995 20:22:03 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id UAA04817
for <current@freebsd.org>; Mon, 24 Jul 1995 20:21:59 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id UAA03091; Mon, 24 Jul 1995 20:21:04 -0700
To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
cc: current@freebsd.org
Subject: Re: Knobs in /etc/sysconfig
In-reply-to: Your message of "Mon, 24 Jul 1995 19:50:53 PDT."
<199507250250.TAA20607@gndrsh.aac.dev.com>
Date: Mon, 24 Jul 1995 20:21:04 -0700
Message-ID: <3089.806642464@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@freebsd.org
Precedence: bulk
> I have never locked it, there have been 8 commits to the files I
> am working on, I have merger the commit, or tossed it as I had
OK, well, the last time this came up I thought you had asserted some
control in that area by flaming someone for making a change. Glad to
know I was wrong.
> I will say, that last time Jordan had fun in /etc/rc* it was a bloody
> mess to clean up. Something like that done again will upset me very
> much, though from the looks of what you want to add it does not
This is a silly thing to say. Everyone here knows exactly why I did
what I did in /etc and "having fun" was hardly at the top of my list
of goals, nor is it something that I'll have to do again since I
accomplished my objective, whcih was breaking free the long-standing
log jam of multiple intertwined crusty files in /etc, and at this
point all I need to do is refine it. I make no apologies whatsoever
for my previous dive into /etc and if you hadn't gone ballistic and
jumped in there immediately then I or someone else would have and we'd
still have something far better than what we had before.
> Another thing, /etc/rc* is a delacate balancing act as far as just
> what you do when, what we have now is functionaly for most people
> but has some sequence problems for others. These are non-trival
> problems to test and require about 15 different machine configurations
> to do regression testing. Since I only have 1 machine to play with
> long term on this type of stuff testing goes very very slow.
I do understand this, and I also understand that two objectives are
NOT obtainable on the first face of any change to the sysconfig knobs:
1. Everyone being happy in all possible scenarios.
2. Us even knowing all possible scenarios.
So this means that any change is going to have to settle for making a
_reasonable_ number of people happy (the set of which may or may not
include yourself, but that's irrelevant if it's still a reasonably
large set) and it's going to have to deal with the possiblity of
evolution as people play with it and report unforseen behavior in
response to unusual, site-specific circumstances.
I can live with this and I don't seem to find this acknowledgement of
reality as painful as you apparently do.
> snmpd should not be started from /etc/netstart. /etc/netstat is only
> for bringing the network on line. It took a lot of work initially by
So put the change in rc.local. Or, better yet, make an rc.locald
directory and organize the various types of startup (networking, i386,
site) into classes, one startup file per class. Then rc.local can go
away (yes! die! die!) and we can have one addition to the bottom of
/etc/rc like this:
# Fill in the types of local startup scripts you have
LOCAL_SCRIPTS= network i386
if [ -d /etc/rc.locald ]; then \
for i in ${LOCAL_SCRIPTS}; do \
if [ -f /etc/rc.locald/$$i ]; then \
sh /etc/rc.locald/$$i; \
fi \
done \
fi
And I'd really rather not hear anybody whining about how this is a bad
idea just because it looks sort of like SYSV. It's a REASONABLE
abstraction and it solves some problems that I personally want to
solve, so what's the problem? I'm happy to hear about other
_solutions_, but I'm not inclined to listen to people just shooting
down this kind of thing on general principle. I'm trying to automate
some things that really need automating for those without prior
FreeBSD admin experience and the fact that a lot of the hackers here
know how to do it by hand with their eyes closed isn't really that
relevant.
> Why not appended it to /etc/rc.local, and append the variable settings
> in /etc/sysconfig.local, have /etc/sysconfig source /etc/sysconfig.local
> at the end of it.
I rather like the /etc/sysconfig.local idea, but I'd still prefer to
couple it with something like the above rather than tossing all the
knob-ends into /etc/rc.local. Sticking them into a subdir means less
things we'll have to contend with overlaying when upgrading.
As you might expect, upgrading is big on my mind right now. It's
Jordan's other personal crusade at the moment, in fact..
Jordan
From owner-freebsd-current Mon Jul 24 20:26:48 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id UAA05123
for current-outgoing; Mon, 24 Jul 1995 20:26:48 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id UAA05117
for <current@FreeBSD.org>; Mon, 24 Jul 1995 20:26:46 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id UAA03131; Mon, 24 Jul 1995 20:25:19 -0700
To: Michael Smith <msmith@atrad.adelaide.edu.au>
cc: current@FreeBSD.org
Subject: Re: Knobs in /etc/sysconfig
In-reply-to: Your message of "Tue, 25 Jul 1995 12:46:46 +0930."
<199507250316.MAA01538@genesis.atrad.adelaide.edu.au>
Date: Mon, 24 Jul 1995 20:25:18 -0700
Message-ID: <3128.806642718@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@FreeBSD.org
Precedence: bulk
> (Unless I'm mistraken, the 'x' is a historic wart, and test can now handle
> empty arguments...)
Sorry, historical habit with the sh code I write.. :-)
> Please ensure that the default "yes" values are documented in the comments
> preceeding each knob; preferably in some standard format, eg:
>
> # default: <value>
Sounds reasonable.. We still need to go through and ethnically clense
our handling of variables in general, actually. It would be nice if
there was a STANDARD NAMING CONVENTION that told one whether or not a
given variable was a Boolean, a list of arguments, a list of things
that had their own sub-variables (like the network_interfaces var),
etc.
Probably the time to do that is now before it gets too big, but I'm
also not going to hold my breath. It's work.
Jordan
From owner-freebsd-current Mon Jul 24 22:16:53 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id WAA09536
for current-outgoing; Mon, 24 Jul 1995 22:16:53 -0700
Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id WAA09524
for <current@FreeBSD.org>; Mon, 24 Jul 1995 22:16:45 -0700
Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id PAA01801; Tue, 25 Jul 1995 15:04:47 +0930
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Message-Id: <199507250534.PAA01801@genesis.atrad.adelaide.edu.au>
Subject: Re: Knobs in /etc/sysconfig
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Tue, 25 Jul 1995 15:04:47 +0930 (CST)
Cc: msmith@atrad.adelaide.edu.au, current@FreeBSD.org
In-Reply-To: <3128.806642718@time.cdrom.com> from "Jordan K. Hubbard" at Jul 24, 95 08:25:18 pm
Content-Type: text
Content-Length: 2803
Sender: current-owner@FreeBSD.org
Precedence: bulk
Jordan K. Hubbard stands accused of saying:
> > Please ensure that the default "yes" values are documented in the comments
> > preceeding each knob; preferably in some standard format, eg:
> >
> > # default: <value>
>
> Sounds reasonable.. We still need to go through and ethnically clense
> our handling of variables in general, actually. It would be nice if
> there was a STANDARD NAMING CONVENTION that told one whether or not a
> given variable was a Boolean, a list of arguments, a list of things
> that had their own sub-variables (like the network_interfaces var),
> etc.
Hmm, configuration files : the bane of my existence 8)
Before I/we get too rampant on this, what's the feeling (in particular
from Rod, of course 8) on imposing some structure on the layout of
/etc/sysconfig?
A first cut would look something like this :
Lines beginning with '#' are comments. Lines beginning with '#*' are
structure comments.
#* Section: Keyboard
...
#* Keyword: KBD_repeat_rate
#* OneOf: "No change"=none,"Fast"=fast,"Medium"=medium,"Slow"=slow
#* Default: none
KBD_repeat_rate = none
...
#* Section: Networking
...
#* Keyword: NET_interface_list
#* String:
#* Default: "ed0 lp0"
NET_interface_list = "ed0 ed1"
...
etc.
It's impossible to embed _all_ of the intelligence required into these
comments, and overdoing it is harmful to your sanity, but minimising the
keyword-specific intelligence required for processing would be nice 8)
Some other proposals : variable name prefixes. I've already proposed
KBD and NET, I'll add PKG_pkgname for package-specific stuff (in a
Packages section).
As far as types are concerned, I see current use of :
Boolean : ON/OFF
OneOf : one of a,b,c,d
ListOf : none or more of a,b,c,d
String : some string value
StringBoolean : some string value or OFF (or NO or something similar).
FQDN : qualified name (dotted address style)
IPADDR : a dotted-quad value.
Pathname : a pathname
I can see possible use for :
Mailaddr : a mail address
Device : a device name
And I'm sure I've missed some.
The alternative to the structure comments is a hints file, but keeping the
two in sync would be a major nuisance, and would really only hit the
limelight if a proposal similar to the above was rejected.
> Probably the time to do that is now before it gets too big, but I'm
> also not going to hold my breath. It's work.
Not as much as some other things. Thoughts?
> Jordan
--
]] 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 [[
From owner-freebsd-current Tue Jul 25 00:14:00 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id AAA13345
for current-outgoing; Tue, 25 Jul 1995 00:14:00 -0700
Received: (from phk@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id AAA13336
; Tue, 25 Jul 1995 00:13:59 -0700
From: Poul-Henning Kamp <phk>
Message-Id: <199507250713.AAA13336@freefall.cdrom.com>
Subject: Re: Knobs in /etc/sysconfig
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Tue, 25 Jul 1995 00:13:59 -0700 (PDT)
Cc: msmith@atrad.adelaide.edu.au, current@FreeBSD.org
In-Reply-To: <3128.806642718@time.cdrom.com> from "Jordan K. Hubbard" at Jul 24, 95 08:25:18 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 616
Sender: current-owner@FreeBSD.org
Precedence: bulk
> > (Unless I'm mistraken, the 'x' is a historic wart, and test can now handle
> > empty arguments...)
>
> Sorry, historical habit with the sh code I write.. :-)
>
It is still a good idea if the string could be something like "-f"
for instance. This is particular likely in /etc/sysconfig, so
I actually think the "x" should be mandatory there.
--
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.
Just that: dried leaves in boiling water ?
From owner-freebsd-current Tue Jul 25 00:54:28 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id AAA14864
for current-outgoing; Tue, 25 Jul 1995 00:54:28 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id AAA14855
for <freebsd-current@freefall.cdrom.com>; Tue, 25 Jul 1995 00:54:18 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA09480; Tue, 25 Jul 1995 09:52:58 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id KAA26003 for freebsd-current@freefall.cdrom.com; Tue, 25 Jul 1995 10:10:13 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id JAA08549 for freebsd-current@freefall.cdrom.com; Tue, 25 Jul 1995 09:12:17 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507250712.JAA08549@uriah.heep.sax.de>
Subject: Re: panic after fdformat/disklabel
To: freebsd-current@freefall.cdrom.com
Date: Tue, 25 Jul 1995 09:12:17 +0200 (MET DST)
Reply-To: freebsd-current@freefall.cdrom.com
In-Reply-To: <199507250306.NAA07991@godzilla.zeta.org.au> from "Bruce Evans" at Jul 25, 95 01:06:04 pm
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
Content-Length: 741
Sender: current-owner@FreeBSD.org
Precedence: bulk
As Bruce Evans wrote:
>
> >Fatal trap 12: page fault while in kernel mode
> >...
>
> This is easy to duplicate by reading from /dev/rfd0 using
>
> char buf[8192];
> main() { lseek(0, 8192ll, 0); read(0, buf, sizeof buf); }
>
> but for some reason it isn't easy to duplicate by reading using dd.
> The lseek is to avoid the magic label sector but doesn't make any
> difference.
I'm remotely logged in and won't see my machine face to face until the
weekend, so i can neither put a floppy in nor am i tempted to crash it
right now. :-)
Can somebody provide me with data from the page fault?
--
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 Tue Jul 25 01:07:46 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id BAA15646
for current-outgoing; Tue, 25 Jul 1995 01:07:46 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id BAA15639
for <current@freebsd.org>; Tue, 25 Jul 1995 01:07:42 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id BAA03432; Tue, 25 Jul 1995 01:07:33 -0700
Date: Tue, 25 Jul 1995 01:07:33 -0700
Message-Id: <199507250807.BAA03432@silvia.HIP.Berkeley.EDU>
To: jkh@time.cdrom.com
CC: rgrimes@gndrsh.aac.dev.com, current@freebsd.org
In-reply-to: <3089.806642464@time.cdrom.com> (jkh@time.cdrom.com)
Subject: Re: Knobs in /etc/sysconfig
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: current-owner@freebsd.org
Precedence: bulk
* So put the change in rc.local. Or, better yet, make an rc.locald
* directory and organize the various types of startup (networking, i386,
* site) into classes, one startup file per class. Then rc.local can go
* away (yes! die! die!) and we can have one addition to the bottom of
* /etc/rc like this:
I'm all for this. In fact, I want it to be "one startup file per
program". I don't want to have to edit any /etc/* file as part of the
"automatically adding itself to startup sequence". Let's face it,
there's no way we can do that from the ports tree without worrying
about accidentally tramping on someone's toes by screwing up the
startup files.
So, we can do something like this:
/etc/rc.locald/S<s><num><name>
being a startup script of sequence <s>. The sequence is like "before
such-and-such daemon starts", "between foo and bar", etc. (I'm no
expert in the startup sequence but there are some stuff that have to
be started in between the system daemons, right?)
At various points of the startup, all the scripts with sequence number
<s> will be called from system rc files. They will be sorted in shell
globbing order (so the <num> comes in here, if we have inter-
dependencies among ports).
Then the job of pkg_add is just to add this file, and pkg_delete to
just delete this file. The porter's job is to write this script so
that the program will be started up with reasonable arguments, and
check other ports to see if there are any dependencies.
The user can edit the content of the file if she wants it come up with
a different set of arguments.
Can't get any simpler than this. :)
Satoshi
From owner-freebsd-current Tue Jul 25 02:32:45 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id CAA18215
for current-outgoing; Tue, 25 Jul 1995 02:32:45 -0700
Received: from minnow.render.com (render.demon.co.uk [158.152.30.118])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id CAA18202
for <freebsd-current@freebsd.org>; Tue, 25 Jul 1995 02:32:35 -0700
Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id KAA01139; Tue, 25 Jul 1995 10:32:16 +0100
Date: Tue, 25 Jul 1995 10:32:15 +0100 (BST)
From: Doug Rabson <dfr@render.com>
To: Terry Lambert <terry@cs.weber.edu>
cc: peter@haywire.dialix.com, freebsd-current@freebsd.org
Subject: Re: what's going on here? (NFSv3 problem?)
In-Reply-To: <9507242136.AA09885@cs.weber.edu>
Message-ID: <Pine.BSF.3.91.950725102458.230B-100000@minnow.render.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
On Mon, 24 Jul 1995, Terry Lambert wrote:
> > The NFSv3 code in -current uses the modification time of the directory as
> > the verifier. This is perhaps a slightly pessimistic solution but it
> > should detect compactions. The client reacts to bad cookie errors by
> > flushing its cached information about the directory. This seems to be a
> > reasonable reaction to the directory being modified.
> >
> > Can the ufs code ever compact a directory block *without* the
> > modification time of the directory changing? Presumably it only ever
> > does this as a result of some other operation on the directory.
>
> This is a good question.
>
> I can answer it in terms of existing practice and in terms of POSIX time
> update semantics requirements.
>
> For UFS, the compaction can only take place when an entry has failed
> lookup during creation and is therefore being created (ie: with the
> directory locked).
>
> That is, a directory data modification is involved.
>
> Does this mean that directory times will be updated?
>
> Under POSIX, it does not. The modification time update semantics in
> POSIX are file-bound. That is, one is not required to update the
> times for directories the same as one is required to update the times
> for files. The single exception to this is the directory read
> operations which must *mark for update* the access time. Note that
> this does not require that it have been updated by the time a subsequent
> access has taken place.
>
> We can easily envision compaction in a DOS style directory (after all,
> this is what Win95 does in order to support long names, effectively),
> where since the file names are attributes of the file rather than real
> directory contents, such compaction does *not* cause the directory to
> be even marked for update!
>
> That is, depending on this behaviour has existing failure modes for
> non-POSIX file systems in any case.
>
> I think it is a mistake to assume that the NFS exporting of file
> systems should only work when the NFS export is a client of POSIX
> file system services (and even then, it depends on "mark for update"
> referring to a change of the in core time stamp rather than a real
> marking by flagging the in core and on disk times to be updated at
> dirty page discard time -- assuming a directory is implemented as a
> file at all instead of being considered a logically seperate entity).
The current code in the NFS server generates the verifier in the
supposedly FS independant server code. This is the part which is wrong.
The VOP_READDIR call should really allow the FS to return a verifier
along with the cookies. Of course, if I suggested another change to
VOP_READDIR, then the flames would really start...
> > At the time, I was more interested in fixing the completely stupid
> > assumption the NFS server was making about the FS implementation which
> > only ever worked for UFS. Adding a whole new layer of code between NFS
> > and the VFS would have added maintenance problems, consistency problems
> > (we would be caching directory information; when is the cache invalid?
> > when should stuff be removed from it?) and needless complication.
>
> I think the cache issue is seperate. Specifically, directory caching
> should be generalized externally to the file system implementations
> themselves. Potentially, it should even be a seperate layer, although
> the only thing dictating that would be the lack of a filesystem initiated
> cache callback mechanism for ensuring coherency. Even then, that's a
> problem with the file system under the cache and should be handled in
> the file system implementation rather than being hacked around by adding
> function call layering everywhere so that it can be omitted for file
> systems that might undergo promiscuous changes (ie: NFS, AFS).
>
> The assumptions that NFS made were, indeed *wrong*. But since the issue
> was FS implementation independent metadata presentation, the fact is
> that the complication would have been purely NFS's problem -- and at
> that, it's caused by the statelessness NFS insists on maintaining.
> A presentation layer would have added a single function call overhead to
> the NFS based ops -- and avoided the buffer size implications that got
> strewn about as a result. The layer itself would have disappeared,
> all but the single function call dealing with stat, when the call
> graph was collapsed in creating the file system instance.
>
> Admittedly, this would have meant dealing with some of the messier
> stackability isses then, rather than later.
>
> The other alternative would have been to put off the stackability
> issues until later and to eat two copies in the NFS layer (and some
> stack allocated buffer space). This actually wouldn't have been that
> big of a hit to take in any case, since the bottleneck is the network
> (relative to the extra copy time).
>
> Either way, it's really water under the bridge, although I'm going to
> be beating on some of the stackability issues in the near future; in
> particular, moving the directory cache up to the vnode rather than the
> inode layer and going to a per FS type vnode pool to overcome the
> inode space limitations imposed by common inode allocation both need
> to happen in the near future. Luckily USL has kindly documented SVR4
> DNLC (a vnode based directory name lookup cache) for us, though it
> is missing the ability to keep negative cache entries (i'll fix that,
> though; it's relatively easy even in the USL code).
Well in the interests of stability and to avoid making FreeBSD 2.0 even
later, I chose the easy solution :-). If you can improve the situation
by reworking the system name cache, then that can only be a good thing.
--
Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com
Phone: +44 171 251 4411
FAX: +44 171 251 0939
From owner-freebsd-current Tue Jul 25 02:47:17 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id CAA18683
for current-outgoing; Tue, 25 Jul 1995 02:47:17 -0700
Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id CAA18677
for <current@freebsd.org>; Tue, 25 Jul 1995 02:47:14 -0700
Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id TAA02359; Tue, 25 Jul 1995 19:31:40 +0930
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Message-Id: <199507251001.TAA02359@genesis.atrad.adelaide.edu.au>
Subject: Re: Knobs in /etc/sysconfig
To: asami@CS.Berkeley.EDU (Satoshi Asami)
Date: Tue, 25 Jul 1995 19:31:39 +0930 (CST)
Cc: jkh@time.cdrom.com, rgrimes@gndrsh.aac.dev.com, current@freebsd.org
In-Reply-To: <199507250807.BAA03432@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Jul 25, 95 01:07:33 am
Content-Type: text
Content-Length: 1915
Sender: current-owner@freebsd.org
Precedence: bulk
Satoshi Asami stands accused of saying:
> At various points of the startup, all the scripts with sequence number
> <s> will be called from system rc files. They will be sorted in shell
> globbing order (so the <num> comes in here, if we have inter-
> dependencies among ports).
This won't work very well, unfortunately. You'd have to give every
port in this category a unique and permanent sequence number, starting
with a huge inter-number spacing to allow for insertions, or some
variation on this idea.
If you can handle keeping a list of 'what goes before/what goes after'
for each port, then a sequentially arranged list in a control file
could be realistically managed, with entries inserted and deleted as
packages come and go.
> Then the job of pkg_add is just to add this file, and pkg_delete to
> just delete this file. The porter's job is to write this script so
> that the program will be started up with reasonable arguments, and
> check other ports to see if there are any dependencies.
This makes automation easier, but increases (substantially) the pain
for work-by-hand. I'm lukewarm, I suspect other will Not Like It Very
Much At All 8)
> Can't get any simpler than this. :)
The current state of the art is pretty simple, just messy.
The real question here I guess is whether there is sufficient support for
an approach favourable to automated interaction. Are we ready for a
'never edit the files, just use the editing tools' approach a 'la Solaris,
or do we want a middle ground solution?
> Satoshi
--
]] 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 [[
From owner-freebsd-current Tue Jul 25 02:53:21 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id CAA18865
for current-outgoing; Tue, 25 Jul 1995 02:53:21 -0700
Received: from who.cdrom.com (who.cdrom.com [192.216.222.3])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id CAA18858
for <current@freefall.cdrom.com>; Tue, 25 Jul 1995 02:53:19 -0700
Received: from minnow.render.com (render.demon.co.uk [158.152.30.118])
by who.cdrom.com (8.6.11/8.6.11) with ESMTP id CAA27120
for <current@freefall.cdrom.com>; Tue, 25 Jul 1995 02:52:41 -0700
Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id KAA01160; Tue, 25 Jul 1995 10:36:43 +0100
Date: Tue, 25 Jul 1995 10:36:42 +0100 (BST)
From: Doug Rabson <dfr@render.com>
To: current@freefall.cdrom.com, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
cc: current@freefall.cdrom.com
Subject: Re: Interesting NFS problem with -current
In-Reply-To: <199507241058.MAA05269@uriah.heep.sax.de>
Message-ID: <Pine.BSF.3.91.950725103308.230C-100000@minnow.render.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@FreeBSD.org
Precedence: bulk
On Mon, 24 Jul 1995, J Wunsch wrote:
> As Jordan K. Hubbard wrote:
> >
> > Scenario: Several hosts with cross-mount privs managed by AMD. Host foo
> > exports its cdrom drive to host bar, which can see it in /host/foo/cdrom.
> > So far, so good. Now say that foo unmounts the CD in the drive and mounts
> > a new one. Host bar now sees:
> >
> > <some command>: /host/foo/cdrom: Stale NFS file handle
> >
> > In response to any access to the newly mounted CD. At the
> > same time as the access, host foo prints:
> >
> > fhtovp: file start miss 60 vs 20
> >
> > On its system console.
> >
> > I figure this is something to do with NFS v3, but perhaps the data
> > is of use to someone working in that area.
>
> The decision of the cd9660 code whether some NFS client is accessing a
> stale NFS file handle (i.e. one that's been granted for a previous CD)
> is rather a crock. I haven't got a good idea on how to solve this
> better.
>
> I suspect the generation of stale NFS file handles for removable
> sd-type disks might be as broken as well, but it's not as obvious
> there as for CDs. Might become a point with the advent of ZIP drives
> however.
The mount-time could be added to the filehandle (someone suggested this
to me as a possible readdir cookie verifier for cd9660). That would
certainly detect disk-changes but it would also invalidate filehandles
for the same disk which was mounted twice.
Hmm. No this wouldn't work because if the server rebooted, then all the
clients would lose. What we need is a unique signature for the disk.
What about an MD5 checksum for the first few hundred blocks?
--
Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com
Phone: +44 171 251 4411
FAX: +44 171 251 0939
From owner-freebsd-current Tue Jul 25 03:00:54 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id DAA19322
for current-outgoing; Tue, 25 Jul 1995 03:00:54 -0700
Received: from sun.leeds.ac.uk (sunserv1_ie0.leeds.ac.uk [129.11.28.1])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id DAA19314
for <freebsd-current@freebsd.org>; Tue, 25 Jul 1995 03:00:47 -0700
Received: (from ecl6ql@localhost) by sun.leeds.ac.uk (8.6.12/8.6.9) id LAA08395 for freebsd-current@freebsd.org; Tue, 25 Jul 1995 11:00:10 +0100
From: Q Li <ecl6ql@sun.leeds.ac.uk>
Message-Id: <199507251000.LAA08395@sun.leeds.ac.uk>
Subject: problem running tcpdump
To: freebsd-current@freebsd.org
Date: Tue, 25 Jul 1995 11:00:09 +0100 (BST)
X-Mailer: ELM [version 2.4 PL13]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 771
Sender: current-owner@freebsd.org
Precedence: bulk
Please let me know if this is not the right list to ask the question.
Just try to run tcpdump a newly installed freebsd machine
(2.0.5-950622-snap) and I got
tcpdump: /dev/bpf0: Device not configured
Can somebody give me a hint as to where to find a fix?
The machine runs on the network without any other problems.
Thanks
Qin
--
Qin Li, Computing Service, University of Leeds, Leeds, UK LS2 9JT
Email: Q.Li@leeds.ac.uk Tel: +44 (0)113 2335379 Fax: +44 (0)113 2335411
#########################################################################
# There is a Leeds University local news group leeds.mail where various #
# Email related matters on campus are discussed. #
#########################################################################
From owner-freebsd-current Tue Jul 25 03:11:14 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id DAA19765
for current-outgoing; Tue, 25 Jul 1995 03:11:14 -0700
Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id DAA19759
for <current@freebsd.org>; Tue, 25 Jul 1995 03:11:11 -0700
Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au
id <01909-0@bunyip.cc.uq.oz.au>; Tue, 25 Jul 1995 20:10:55 +1000
Received: from netfl15a.devetir.qld.gov.au
by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP
id UAA20660 for <current@freebsd.org>;
Tue, 25 Jul 1995 20:15:26 +1000
Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1)
id KAA13423 for <current@freebsd.org>; Tue, 25 Jul 1995 10:11:59 GMT
Message-Id: <199507251011.KAA13423@netfl15a.devetir.qld.gov.au>
X-Mailer: exmh version 1.6 4/21/95
To: current@freebsd.org
Subject: Doom crashes system?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 25 Jul 1995 20:11:58 +1000
From: Stephen Hocking <sysseh@devetir.qld.gov.au>
Sender: current-owner@freebsd.org
Precedence: bulk
Before I go filing a bug report, has anyone noticed that doom seems to crash
the system? I fire it up and whammo, instant reboot. I have been fiddling with
some of the sound ioctl stuff, to get it to be able to work with the Linux
sndserver, but this happens even before sndserver is fired off. Can someone
else whose at src-cur 831 or later check this?
Stephen
I do not speak for the Worker's Compensation Board of Queensland -
They don't pay me enough for that!
From owner-freebsd-current Tue Jul 25 04:11:32 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id EAA21878
for current-outgoing; Tue, 25 Jul 1995 04:11:32 -0700
Received: from ns.dknet.dk (ns.dknet.dk [193.88.44.42])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id EAA21870
for <current@freebsd.org>; Tue, 25 Jul 1995 04:11:27 -0700
Received: from login.dknet.dk by ns.dknet.dk with SMTP id AA14641
(5.65c8/IDA-1.4.4j for <current@freebsd.org>); Tue, 25 Jul 1995 13:11:06 +0200
Received: by login.dknet.dk (4.1/SMI-4.1DKnet00)
id AA25730; Tue, 25 Jul 95 13:09:50 +0200
Message-Id: <9507251109.AA25730@login.dknet.dk>
Subject: Re: Doom crashes system?
To: sysseh@devetir.qld.gov.au (Stephen Hocking)
Date: Tue, 25 Jul 95 13:09:48 MET DST
Cc: current@freebsd.org
In-Reply-To: <199507251011.KAA13423@netfl15a.devetir.qld.gov.au>; from "Stephen Hocking" at Jul 25, 95 8:11 pm
From: sos@freebsd.org
Reply-To: sos@freebsd.org
X-Charset: ASCII
X-Char-Esc: 29
Sender: current-owner@freebsd.org
Precedence: bulk
In reply to Stephen Hocking who wrote:
>
> Before I go filing a bug report, has anyone noticed that doom seems to crash
> the system? I fire it up and whammo, instant reboot. I have been fiddling with
> some of the sound ioctl stuff, to get it to be able to work with the Linux
> sndserver, but this happens even before sndserver is fired off. Can someone
> else whose at src-cur 831 or later check this?
You should not try using the sndserver, it does not work and
produces weird results (granted it shouldn't panic the system)
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team
So much code to hack -- so little time
From owner-freebsd-current Tue Jul 25 07:19:52 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id HAA25778
for current-outgoing; Tue, 25 Jul 1995 07:19:52 -0700
Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id HAA25772
for <current@freebsd.org>; Tue, 25 Jul 1995 07:19:49 -0700
Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA06573; Tue, 25 Jul 1995 10:19:38 -0400
Date: Tue, 25 Jul 1995 10:19:38 -0400
From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
Message-Id: <9507251419.AA06573@halloran-eldar.lcs.mit.edu>
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>, current@freebsd.org
Subject: Re: Knobs in /etc/sysconfig
In-Reply-To: <3089.806642464@time.cdrom.com>
References: <199507250250.TAA20607@gndrsh.aac.dev.com>
<3089.806642464@time.cdrom.com>
Sender: current-owner@freebsd.org
Precedence: bulk
<<On Mon, 24 Jul 1995 20:21:04 -0700, "Jordan K. Hubbard" <jkh@time.cdrom.com> said:
> # Fill in the types of local startup scripts you have
> LOCAL_SCRIPTS= network i386
> if [ -d /etc/rc.locald ]; then \
> for i in ${LOCAL_SCRIPTS}; do \
> if [ -f /etc/rc.locald/$$i ]; then \
> sh /etc/rc.locald/$$i; \
> fi \
> done \
> fi
If you're going to go this far in the SysV direction (and in this one
particular case it's not unreasonable), I would far rather have
something like:
if [ -d /etc/rc.local.d ]; then
for script in /etc/rc.local.d/*.sh; do
[ -x $script ] && $script start
done
fi
if [ -x /etc/rc.local ]; then
/etc/rc.local
fi
The first part is almost like what SysV implementations do, only it's
Emacs-safe. (Obviously, I would expect the scripts to understand
`restart' and `stop' as well as `start'.) I put in the `test -x' part
to make it trivial to turn these things on and off as necessary.
> I rather like the /etc/sysconfig.local idea, but I'd still prefer to
> couple it with something like the above rather than tossing all the
> knob-ends into /etc/rc.local. Sticking them into a subdir means less
> things we'll have to contend with overlaying when upgrading.
I don't like the idea of /etc/sysconfig.local as a dumping-ground for
third-party software configuration options. Either there should be a
third-party section in the real /etc/sysconfig, or there should be a
separate config file for each service (/etc/rc.local.d/$service.cf?).
I lean towards the former.
-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 Tue Jul 25 07:22:38 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id HAA25893
for current-outgoing; Tue, 25 Jul 1995 07:22:38 -0700
Received: from plains.nodak.edu (plains.NoDak.edu [134.129.111.64])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id HAA25887
for <current@freebsd.org>; Tue, 25 Jul 1995 07:22:36 -0700
Received: (from tinguely@localhost) by plains.nodak.edu (8.6.11/8.6.10) id JAA10361; Tue, 25 Jul 1995 09:22:29 -0500
Date: Tue, 25 Jul 1995 09:22:29 -0500
From: Mark Tinguely <tinguely@plains.nodak.edu>
Message-Id: <199507251422.JAA10361@plains.nodak.edu>
To: rgrimes@gndrsh.aac.dev.com
Subject: Re: New options for lastcomm(1)
Cc: current@freebsd.org
Content-Length: 1510
Sender: current-owner@freebsd.org
Precedence: bulk
> > I use accounting as poor man's (k)trace, for debugging and
> > optimization of shell/perl scripts.
>
> Why do that when we have ktrace in FreeBSD???
I think process accounting is important enough and I needed it enough
that I put the original accounting information in the old 386bsd or in
one of the first FreeBSD (back in ot-9 when we ran it on an slide rule:) )
I can't remember.
process accounting is great for after-the-fact security chases, when the
offender is not good at hiding their tracks.
it also give a good indication of computer use because it logs things that
happen outside login sequence (cron, at, mail, httpd, xterm -u, or rsh to a
shell sessions). and it can tell usage of those that are logged on (for example
when people around here log in just to "see and be seen").
On other Unix machine, process accounting has been used here to figure out
what users do the most. This is can be used to plan how many machine are need
and dedicated to what purpose.
it is too bad it cannot tell more about the system the momemt it crashed
(because process accounting happens only after a process terminates). but
it can tell important clues of the few minutes before the crash or hang.
I did not see the original mail article on the changes, nor did I see
anyone answer the later question on how to install (that is in the FAQ).
I still believe that process accounting is important and run it on the
computers that are flakey or are used as general access multi-user machines.
--mark.
From owner-freebsd-current Tue Jul 25 07:53:58 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id HAA27449
for current-outgoing; Tue, 25 Jul 1995 07:53:58 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id HAA27435
for <current@freebsd.org>; Tue, 25 Jul 1995 07:53:54 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id BAA03524; Tue, 25 Jul 1995 01:27:24 -0700
Date: Tue, 25 Jul 1995 01:27:24 -0700
Message-Id: <199507250827.BAA03524@silvia.HIP.Berkeley.EDU>
To: bde@zeta.org.au
CC: ache@astral.msk.su, current@freebsd.org
In-reply-to: <199507241657.CAA25622@godzilla.zeta.org.au> (message from Bruce Evans on Tue, 25 Jul 1995 02:57:57 +1000)
Subject: Re: does xdr_float addition requires minor number bumping or what?
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: current-owner@freebsd.org
Precedence: bulk
* It requires bumping of the minor version number of libc.so but I think
* we intend to only bump it (if necessary) before releases.
I suggest (now, as I did before) we bump it now, and note that fact in
the commit log of the appropriate Makefile. That way we don't have to
worry about
(1) forgetting to bump it, and
(2) the mad rush of version number changes right before the release,
which forced the recompilation of the entire ports tree last time
(What happened to the policy doc that I was supposed to write all this?)
Satoshi :)
From owner-freebsd-current Tue Jul 25 08:46:07 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id IAA29911
for current-outgoing; Tue, 25 Jul 1995 08:46:07 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id IAA29902
for <current@freebsd.org>; Tue, 25 Jul 1995 08:45:59 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA02402; Wed, 26 Jul 1995 01:28:53 +1000
Date: Wed, 26 Jul 1995 01:28:53 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507251528.BAA02402@godzilla.zeta.org.au>
To: asami@cs.berkeley.edu, bde@zeta.org.au
Subject: Re: does xdr_float addition requires minor number bumping or what?
Cc: ache@astral.msk.su, current@freebsd.org
Sender: current-owner@freebsd.org
Precedence: bulk
>I suggest (now, as I did before) we bump it now, and note that fact in
>the commit log of the appropriate Makefile. That way we don't have to
>worry about
>(1) forgetting to bump it, and
>(2) the mad rush of version number changes right before the release,
> which forced the recompilation of the entire ports tree last time
That way we have to worry about newly compiled ports being annoying to
use in 2.0.5R and maybe in 2.1. ld.so will print the confusing message:
warning: libc.so.2.1: minor version < 2 expected; using it anway
Perhaps ld.so meant to say "minor version < 2 UNexpected". I'd prefer
it to say something like "minor version >= 2 expected; using #1 anyway".
OTOH if you don't bump the minor every time it is technically required,
then newly compiled ports will mysteriously fail in 2.0.5R and maybe in
2.1 if they actually use the new features.
I prefer things to fail unmysteriously :-).
Bruce
From owner-freebsd-current Tue Jul 25 10:59:16 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA04499
for current-outgoing; Tue, 25 Jul 1995 10:59:16 -0700
Received: from clark.net (clark.net [168.143.0.7])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id KAA04492
for <freebsd-current@freebsd.org>; Tue, 25 Jul 1995 10:59:15 -0700
Received: (rjw@localhost) by clark.net (8.6.12/8.6.5) id NAA04785; Tue, 25 Jul 1995 13:58:49 -0400
Date: Tue, 25 Jul 1995 13:58:48 -0400 (EDT)
From: Rick Weldon <rjw@clark.net>
To: Q Li <ecl6ql@sun.leeds.ac.uk>
cc: freebsd-current@freebsd.org
Subject: Re: problem running tcpdump
In-Reply-To: <199507251000.LAA08395@sun.leeds.ac.uk>
Message-ID: <Pine.SOL.3.91.950725135258.2224A-100000@clark.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
Put something like
pseudo-device bpfilter 4
in you kernel config file and rebuild your kernel, install it and reboot.
This is not the right list for this question. It should be
freebsd-questions@freebsd.org
---------------------------------------
On Tue, 25 Jul 1995, Q Li wrote:
> Please let me know if this is not the right list to ask the question.
>
> Just try to run tcpdump a newly installed freebsd machine
> (2.0.5-950622-snap) and I got
>
> tcpdump: /dev/bpf0: Device not configured
>
> Can somebody give me a hint as to where to find a fix?
>
> The machine runs on the network without any other problems.
>
> Thanks
> Qin
>
> --
> Qin Li, Computing Service, University of Leeds, Leeds, UK LS2 9JT
> Email: Q.Li@leeds.ac.uk Tel: +44 (0)113 2335379 Fax: +44 (0)113 2335411
> #########################################################################
> # There is a Leeds University local news group leeds.mail where various #
> # Email related matters on campus are discussed. #
> #########################################################################
>
From owner-freebsd-current Tue Jul 25 14:01:03 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id OAA12067
for current-outgoing; Tue, 25 Jul 1995 14:01:03 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id OAA12061
for <current@freefall.cdrom.com>; Tue, 25 Jul 1995 14:01:02 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA17127; Tue, 25 Jul 95 14:53:10 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507252053.AA17127@cs.weber.edu>
Subject: Re: Interesting NFS problem with -current
To: dfr@render.com (Doug Rabson)
Date: Tue, 25 Jul 95 14:53:09 MDT
Cc: current@freefall.cdrom.com, joerg_wunsch@uriah.heep.sax.de
In-Reply-To: <Pine.BSF.3.91.950725103308.230C-100000@minnow.render.com> from "Doug Rabson" at Jul 25, 95 10:36:42 am
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@FreeBSD.org
Precedence: bulk
> The mount-time could be added to the filehandle (someone suggested this
> to me as a possible readdir cookie verifier for cd9660). That would
> certainly detect disk-changes but it would also invalidate filehandles
> for the same disk which was mounted twice.
We're worried about media changes, right? Ones that don't involve
remounting the same media?
> Hmm. No this wouldn't work because if the server rebooted, then all the
> clients would lose. What we need is a unique signature for the disk.
> What about an MD5 checksum for the first few hundred blocks?
There's supposed to be a unique disk ID generated from the manufacturer
and a manufacturer ID for that.
In practice, this almost never happens. Ask Jordan why. 8-).
I think the MD5 checksum is probably the best mechanism.
I'd use the root directory blocks, however, which means generating
it at mount time. There's no guarantee that there will even be data
other than a potentially non-unique header at the front of the disk.
Linux actually doesn't flush the buffer cache for unmounted CDROMs(!)
unless they detect a real media change, as opposed to a media out/in
without a disk change.
Because the cdrom instance is seperate for each cdrom when using a
changer, this give Linux a big advantage on changers.
Something to think about if you're going to be in the code anyway...
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Tue Jul 25 14:17:06 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id OAA12735
for current-outgoing; Tue, 25 Jul 1995 14:17:06 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id OAA12729
for <freebsd-current@freebsd.org>; Tue, 25 Jul 1995 14:17:05 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA17181; Tue, 25 Jul 95 15:05:58 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507252105.AA17181@cs.weber.edu>
Subject: Re: what's going on here? (NFSv3 problem?)
To: dfr@render.com (Doug Rabson)
Date: Tue, 25 Jul 95 15:05:57 MDT
Cc: peter@haywire.dialix.com, freebsd-current@freebsd.org
In-Reply-To: <Pine.BSF.3.91.950725102458.230B-100000@minnow.render.com> from "Doug Rabson" at Jul 25, 95 10:32:15 am
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@freebsd.org
Precedence: bulk
[ ... ]
> The current code in the NFS server generates the verifier in the
> supposedly FS independant server code. This is the part which is wrong.
> The VOP_READDIR call should really allow the FS to return a verifier
> along with the cookies. Of course, if I suggested another change to
> VOP_READDIR, then the flames would really start...
8-). Yes. I'd start by arguing that it should go in stat instead...
> Well in the interests of stability and to avoid making FreeBSD 2.0 even
> later, I chose the easy solution :-). If you can improve the situation
> by reworking the system name cache, then that can only be a good thing.
I realized at the time that it was the expedient soloution, too. And
in all fairness, there are times when you need to make tradeoffs between
correctness and expediency.
Now we can determine the correct soloution and deal with it.
I'm going to be uploading the patches to my home directory on freefall
tomorrow evening to get rid of the root mount frobs outside the
documented interface to VFS.
I have some mount system call changes to get rid of the manifest constants
for file system types, and some user space utilites to clean up to
handle those changes, next.
After that's done, it should free me up to deal with some of the cache
and interface smearing issues in NFS and elsewhere. I need to do the
NFS and CDROM root mount generalizations in any case, and that's in
the area.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Tue Jul 25 15:49:26 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id PAA16475
for current-outgoing; Tue, 25 Jul 1995 15:49:26 -0700
Received: from who.cdrom.com (who.cdrom.com [192.216.222.3])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id PAA16469
for <current@freebsd.org>; Tue, 25 Jul 1995 15:49:25 -0700
Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13])
by who.cdrom.com (8.6.11/8.6.11) with ESMTP id PAA00258
for <current@freebsd.org>; Tue, 25 Jul 1995 15:48:43 -0700
Received: from localhost.cs.tu-berlin.de ([130.149.1.128]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id AAA13657 for <current@freebsd.org>; Wed, 26 Jul 1995 00:28:14 +0200
Received: (from w@localhost) by localhost.cs.tu-berlin.de (8.6.9/8.6.9) id AAA06375; Wed, 26 Jul 1995 00:27:46 +0200
Date: Wed, 26 Jul 1995 00:27:46 +0200
From: Wolfram Schneider <w@cs.tu-berlin.de>
Message-Id: <199507252227.AAA06375@localhost.cs.tu-berlin.de>
To: current@freebsd.org
Subject: Manual page checker
Replyt-to: Wolfram Schneider <wosch@cs.tu-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: current-owner@freebsd.org
Precedence: bulk
$ ./manck.pl /usr/share/man/man2/*
/usr/share/man/man2/execve.2.gz
No entry for `exit' in section 2 (mandir /usr/share/man)
/usr/share/man/cat3/exit.3.gz (source: /usr/share/man/man3/exit.3.gz)
/usr/share/man/man2/fsync.2.gz
No entry for `update' in section 8 (mandir /usr/share/man)
/usr/share/man/man2/getegid.2.gz
No entry for `setgid' in section 3 (mandir /usr/share/man)
/usr/share/man/cat2/setgid.2.gz (source: /usr/share/man/man2/setgid.2.gz)
[...]
/usr/share/man/man2/quotactl.2.gz
ufs/quota.h: include does not exist in: /usr/include /usr/local/include
[...]
$ ./manck.pl /usr/share/man/man1/tic.1.gz
/usr/share/man/man1/tic.1.gz
/usr/lib/terminfo: file does not exist
/usr/lib/terminfo/terminfo.src: file does not exist
No entry for `infocmp' in section 1M (mandir /usr/share/man)
No entry for `term' in section 4 (mandir /usr/share/man)
/usr/share/man/cat5/term.5.gz (source: /usr/share/man/man5/term.5.gz)
No entry for `termcap' in section 4 (mandir /usr/share/man)
/usr/share/man/cat3/termcap.3.gz (source: /usr/share/man/man3/termcap.3.gz)
No entry for `terminfo' in section 4 (mandir /usr/share/man)
/usr/share/man/cat5/terminfo.5.gz (source: /usr/share/man/man5/terminfo.5.gz)
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# manck.pl
# manck.1
#
echo x - manck.pl
sed 's/^X//' >manck.pl << 'END-of-manck.pl'
X:
Xeval "exec perl -S $0 $*"
X if $running_under_some_shell;
X
X#
X# Copyright (c) 1995 Wolfram Schneider <wosch@cs.tu-berlin.de>
X# All rights reserved. Alle Rechte vorbehalten.
X#
X# $Id: manck.pl,v 1.5 1995/07/25 22:21:05 w Exp w $
X#
X# manck - check manual pages
X
Xsub var {
X $ENV{'PATH'} = '/bin:/usr/bin';
X
X $path = '/bin:/sbin:/usr/bin:/usr/sbin';
X @man = ('/usr/bin/man', '-w');
X
X $manpath = '/usr/share/man';
X $incpath = '/usr/include:/usr/local/include';
X
X #$manpath = '/usr/tmp/man';
X
X $ext = '.gz';
X $zcat = 'gzcat';
X
X # 0: only errors 1: some more information 2: verbose
X $debug = 0;
X
X require "stat.pl";
X $| = 1;
X}
X
Xsub usage {
X
X warn <<EOF;
Xusage: manck [-d|-debug] [-d|-debug] [-h|-help] [-bin path]
X [-i|-include includepath] [-M mandir] [manpages ...]
XEOF
X exit 1;
X}
X
Xsub parse {
X local(*argv) = @_;
X
X while ($_ = $argv[0], /^-/) {
X shift @argv;
X last if /^--$/;
X if (/^--?(d|debug)$/) { $debug++ }
X elsif (/^--?(h|help|\?)$/) { &usage }
X elsif (/^--?(b|bin)$/) { exit(&bin($argv[0] || $path)); }
X elsif (/^-M$/) { $manpath = $argv[0]; shift @argv;
X $manpath =~ s=/+$==; }
X elsif (/^-r$/) {
X require "find.pl";
X eval 'sub wanted {
X $name =~ /^$manpath(\/man.*)?\/[^.\/]+\.[^\/]+$/ &&
X &manpage($name);
X }';
X $wanted = 1;
X #&find($manpath);
X }
X elsif (/^-i|-include$/) { $incpath = $argv[0]; shift @argv; }
X
X else { &usage }
X }
X
X @include = split(/:/, $incpath);
X
X # use absolute path
X if ($manpath !~ "^/") {
X $manpath = ($ENV{'PWD'} || `pwd`) . '/' . $manpath;
X $manpath =~ s/\n//g;
X }
X
X &find($manpath) if $wanted;
X}
X
X
X#
X# check if binaries in $path have their own manpages
X# use `man -w program'
X#
Xsub bin {
X local($path) = @_;
X local($dir);
X
X # dup
X open(SAVEOUT, ">&STDOUT");
X open(SAVEERR, ">&STDERR");
X
X # swap stdin and stdout
X # close stdout, redirect stderr to old stdout
X close STDOUT;
X open(STDERR, ">&SAVEOUT");
X
X foreach $dir (split(/:/, $path)) {
X warn "$dir\n";
X opendir(DIR, $dir) || die "opendir: $dir $!\n";
X foreach (readdir(DIR)) {
X next if $_ eq '.';
X next if $_ eq '..';
X
X system @man, $_; # call man(1)
X }
X closedir DIR;
X }
X
X # restore stdout
X open(STDOUT, ">&SAVEOUT");
X open(STDERR, ">&SAVEERR");
X}
X
X
X
X%sh = (
X'AUTHOR', 0,
X'AUTHORS', 0,
X'BUGS', 0,
X'CAVEATS', 0,
X'COMPATIBILITY', 0,
X'DESCRIPTION', 0,
X'DIAGNOSTICS', 0,
X'ENVIRONMENT', 0,
X'ERRORS', 0,
X'EXAMPLE', 0,
X'EXAMPLES', 0,
X'FILES', '&files',
X'HISTORY', 0,
X'NAME', 0,
X'NOTES', 0,
X'OPTIONS', 0,
X'RETURN VALUE', 0,
X'RETURN VALUES', 0,
X'SEE ALSO', '&see_also',
X'STANDARDS', 0,
X'SYNOPSIS', '&synopsis',
X );
X
X#
X# parse single manpage
X# and analyze
X#
Xsub manpage {
X local($file) = @_;
X local(@stat, $do, @list);
X
X # cache
X @stat = stat($file);
X if (defined $cached_file{$stat[$ST_DEV],$stat[$ST_INO]}) {
X &err("$file already visit: " .
X "$cached_file{$stat[$ST_DEV],$stat[$ST_INO]}\n") if $debug > 1;
X return 1;
X }
X $cached_file{$stat[$ST_DEV],$stat[$ST_INO]} = $file;
X
X if ($file =~ /$ext$/o) {
X $file = "$zcat $file |";
X }
X open(MANPAGE, "$file") || do {
X warn "open: $file $!\n";
X return 0;
X };
X
X
X while(<MANPAGE>) {
X next if /^\.\\\"/o; #" comment
X
X if (/^\.S[hH]\s+/o) { # .SH or .Sh
X # start action $do with following lines (until next .SH)
X eval $do;
X
X # reset action and array
X $do = ''; @list = ();
X
X $name = $_;
X $name =~ s/^\.S[hH]\s+\"?//; #"
X $name =~ s/\"?\s*$//; #"
X
X if ($sh{$name}) {
X &err("parse $name\n") if $debug > 0;
X $do = $sh{$name}; # save action
X
X } elsif (defined $sh{$name}) {
X &err("defined $name\n") if $debug > 1;
X } else {
X &err("undef $name\n") if $debug > 0;
X }
X } elsif ($do) {
X # \fBcurs_kernel\fR
X s=\\f[BRPI]==g;
X
X push(@list, $_);
X }
X }
X eval $do; # last .SH in file
X close MANPAGE;
X}
X
X#
X# locate manpage,
X# may be from cache or with stat
X#
Xsub find_manpage {
X local($manpage, $section) = @_;
X
X # failed from cache
X if (defined $cached_mp{$manpage,$section} &&
X !$cached_mp{$manpage,$section}) {
X &err("man $section $manpage failed\n");
X return 0;
X }
X
X # cache
X &err("CACHE $manpage\n")
X if $debug > 2 && $cached_mp{$manpage,$section};
X return 1
X if $cached_mp{$manpage,$section};
X
X $cached_mp{$manpage,$section} = 1;
X
X # test if manpage exist
X if (-e "$manpath/man$section/$manpage.$section" ||
X -e "$manpath/man$section/$manpage.$section$ext") {
X return 1;
X }
X
X # may be wrong section, eg. '3X' instead '3'
X if ($section =~ /^(.).$/ && -d "$manpath/man$1" &&
X (-e "$manpath/man$1/$manpage.$1" ||
X -e "$manpath/man$1/$manpage.$1$ext")) {
X return 1 if $debug < 1;
X &err("manpage `$manpage' is in section `$1' and not $section\n");
X }
X
X # try with man(1)
X print "@man $section $manpage\n" if $debug > 1;
X open(SAVEERR, ">&STDERR"); close STDERR;
X system @man, $section, $manpage; # call man(1) with section
X open(STDERR, ">&SAVEERR");
X return 1 unless $?;
X &err("No entry for `$manpage' in section $section (mandir $manpath)\n");
X
X # second try with man(1), without explicit section
X print "@man $manpage\n" if $debug > 1;
X open(SAVEERR, ">&STDERR"); close STDERR;
X system @man, $manpage; # call man(1) whithout section
X open(STDERR, ">&SAVEERR");
X return 1 unless $?;
X
X # manpage not found
X return 0;
X}
X
X# print error messages
Xsub err {
X if (!$cache_err{$file}) {
X local($f) = $file; $f =~ s/^$zcat\s//; $f =~ s/\s+\|$//;
X print "$f\n";
X $cache_err{$file} = 1;
X }
X print @_;
X}
X
X#
X# .SH SEE ALSO
X# test if manpages exist
X#
Xsub see_also {
X foreach (@list) {
X s/\s+$//; # strip ending blanks
X s/\"//g; # remove '"'
X
X #if (/^$/) {
X # &err("stop SEE ALSO empty line\n") if $debug > 1;
X # return;
X #}
X
X foreach (split(/,/)) {
X s/^\s+//;
X
X # BSD
X if (/^\.(Xr|Fn)\s+(\S+)\s+(\S+)/o) {
X &find_manpage($2, $3) && $debug > 1 &&
X &err("found manpage: $3 $2\n");
X
X }
X # GNU
X elsif (/^(\.[BI]R\s)?\s*(\S+)\s*\(\s*(\S+)\s*\)/o) {
X &find_manpage($2, $3) && $debug > 1 &&
X &err("fond manpage: $3 $2\n");
X }
X # Doku follow, break
X elsif (/^\.(sp|Rs|LP|br|TP|RB|PP|Pp|%)/o ||
X /^RFC/o) {
X &err("stop SEE ALSO: $_\n") if $debug > 1;
X return;
X }
X
X # Hm
X elsif (/^\.(Bl|It)/) {
X &err("skip: `$_'\n") if $debug > 0;
X }
X
X # Garbage
X else {
X &err("unknown: `$_'\n") if $debug > 0;
X }
X }
X }
X}
X
X#
X# .SH FILES
X# test if files exist
X#
Xsub files {
X foreach (@list) {
X next if /^\.(Bl|El|\\\")/;
X
X # .TP \w'/etc/manpath.config'u+2n
X s/\s\\w'([^\']+)'.*/ $1/; #"
X
X if (s=.*\s(\S+)\s*$=$1= && /\//) {
X s/\s+$//;
X s/[\s\'\"].*//; # "
X
X next unless $_;
X next if $debug < 1 && !/^\//;
X
X &err("test -e $_\n") if $debug > 1;
X if (! -e $_) {
X # spool/temp files
X return 1 if $debug < 1 && /[X?*\]\#]$/o;
X return 1 if $debug < 1 && /[\$\[\?]/;
X
X &err("$_: file does not exist\n");
X }
X }
X }
X}
X
X#
X# .SH SYNOPSIS
X# test for include files
X#
Xsub synopsis {
X local($inc);
X
X foreach (@list) {
X if (/\#include\s+[<"](\S+)[>"]/) { #
X if ($cached_file{$1}) {
X &err("CACHED file: $1\n") if $debug > 2;
X next;
X }
X
X $cached_file{$1} = 1;
X
X &err("$1: include does not exist in: @include\n")
X unless &include_test($1);
X }
X }
X}
X
Xsub include_test {
X foreach $inc (@include) {
X &err("test -f $inc/$1\n") if $debug > 1;
X return 1
X if -f "$inc/$1";
X }
X return 0;
X}
X
X
X##
X## Main
X##
X# read enviroment
X&var;
X
X# check /usr/share/man if no arguments given
Xpush(@ARGV, '-M', $manpath) if $#ARGV < 0;
X
X# parse
X&parse(*ARGV);
X&usage if $#ARGV < 0 && !$wanted;
X
X# check single manpages
Xforeach (@ARGV) { &manpage($_); }
X
END-of-manck.pl
echo x - manck.1
sed 's/^X//' >manck.1 << 'END-of-manck.1'
X.\"
X.\" Copyright (c) 1995 Wolfram Schneider <wosch@cs.tu-berlin.de>
X.\" All rights reserved. Alle Rechte vorbehalten.
X.\"
X.\" $Id: manck.1,v 1.2 1995/07/25 22:03:33 w Exp $
X.\"
X.\" manck - check manual pages
X.Dd July 25, 1995
X.Os FreeBSD 2.2
X.Dt MANCK 1
X.Sh NAME
X.Nm manck
X.Nd check manual pages
X.Sh SYNOPSIS
X.Nm manck
X.Op Fl d
X.Op Fl h \&| Ns Fl \&?
X.Op Fl help
X.Op Fl bin Ar path
X.Op Fl i \&| Ns Fl include Ar includepath
X.Op Fl M Ar mandir
X.Op Ar manpages ...
X.Sh DESCRIPTION
X.Nm Manck
Xcheck manual pages. Currently supported section FILES, SEE ALSO, and
XSYNOPSIS.
X
X.Pp
XThe options are as follows:
X
X.Bl -tag -width 10n -offset indent
X.It Fl d \&| Ns Fl debug
XBe more verbose about what will be done. For a single
X.Fl d
Xoption, print more errors and warnings. If the option
X.Fl d
Xhas been specified at least twice, print verbose errors and warnings.
XOne
X.Fl d
Xis recommend for carefully review.
X
X.It Fl h \&| Ns Fl \&?
X.It Fl help
XGive a help on the command usage and exit.
X
X.It Fl i \&| Ns Fl include Ar includepath
XPath where include files located.
XColons in
X.Ar includepath
Xallowed. Default /usr/include:/usr/local/include.
X
X.It Fl M Ar mandir
XUse
X.Ar mandir
Xas directory, where manpages located.
X.It Fl bin Ar path
XLook for binaries in
X.Ar path
Xwhithout manpage. Colons in
X.Ar path
Xallowed. Default /bin:/sbin:/usr/bin:/usr/sbin
X
X.It Fl r
XTraverse recursive mandir (default /usr/share/man).
X.El
X
X.Sh EXAMPLES
X.Pp
X.Dl $ manck -bin
X.Pp
XTest if all binaries in /bin:/sbin:/usr/bin:/usr/sbin have their own
Xmanpages
X
X.Pp
X.Dl $ manck -M /usr/share/man /usr/share/man/man1/z*
X.Pp
XCheck all manpages with leading 'z' in /usr/share/man/man1.
X
X.Pp
X.Dl $ manck -r
X.Pp
XCheck recursive all manpages in /usr/share/man.
X
X.Sh FILES
X.Bl -tag -width /usr/share/man -compact
X.Pa /usr/share/man
Xdirectory for manual pages.
X.El
X
X.Sh ENVIROMENT
X.Bl -tag -width ENVIROMENT
X.Pa MANPATH
Xenviroment variable for man(1).
X
X.El
X
X.Sh SEE ALSO
X.Xr man 1 ,
X.Xr hier 7 .
X
X.Sh HISTORY
X.Nm manck
Xappeared in late July 1995.
X
X.Sh AUTHOR
XWolfram Schneider <wosch@cs.tu-berlin.de>
X
END-of-manck.1
exit
From owner-freebsd-current Tue Jul 25 17:22:22 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id RAA18909
for current-outgoing; Tue, 25 Jul 1995 17:22:22 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id RAA18902
for <freebsd-current@freebsd.org>; Tue, 25 Jul 1995 17:22:09 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA14381; Wed, 26 Jul 1995 02:22:06 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id CAA05404; Wed, 26 Jul 1995 02:22:06 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id PAA11060; Tue, 25 Jul 1995 15:25:23 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507251325.PAA11060@uriah.heep.sax.de>
Subject: Re: problem running tcpdump
To: ecl6ql@sun.leeds.ac.uk (Q Li)
Date: Tue, 25 Jul 1995 15:25:23 +0200 (MET DST)
Cc: freebsd-current@freebsd.org
In-Reply-To: <199507251000.LAA08395@sun.leeds.ac.uk> from "Q Li" at Jul 25, 95 11:00:09 am
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
Content-Length: 616
Sender: current-owner@freebsd.org
Precedence: bulk
As Q Li wrote:
>
> Please let me know if this is not the right list to ask the question.
This would rather belong to questions@freebsd.org.
> Just try to run tcpdump a newly installed freebsd machine
> (2.0.5-950622-snap) and I got
>
> tcpdump: /dev/bpf0: Device not configured
Look into the LINT file for how to configure the bpf devices. You
need to build a custom kernel, they are not included in the GENERIC
kernel. Refer to the FAQ (sect 6) on how to do that.
--
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 Tue Jul 25 17:22:34 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id RAA18941
for current-outgoing; Tue, 25 Jul 1995 17:22:34 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id RAA18903
for <freebsd-current@FreeBSD.org>; Tue, 25 Jul 1995 17:22:20 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA14376; Wed, 26 Jul 1995 02:22:05 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id CAA05399 for freebsd-current@FreeBSD.org; Wed, 26 Jul 1995 02:22:04 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id PAA11039 for freebsd-current@FreeBSD.org; Tue, 25 Jul 1995 15:23:53 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507251323.PAA11039@uriah.heep.sax.de>
Subject: Re: Interesting NFS problem with -current
To: freebsd-current@FreeBSD.org (FreeBSD-current users)
Date: Tue, 25 Jul 1995 15:23:52 +0200 (MET DST)
Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users)
In-Reply-To: <Pine.BSF.3.91.950725103308.230C-100000@minnow.render.com> from "Doug Rabson" at Jul 25, 95 10:36:42 am
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
Content-Length: 650
Sender: current-owner@FreeBSD.org
Precedence: bulk
As Doug Rabson wrote:
>
> Hmm. No this wouldn't work because if the server rebooted, then all the
> clients would lose. What we need is a unique signature for the disk.
> What about an MD5 checksum for the first few hundred blocks?
I'm not sure. The first 0x8000 bytes are usually crap on an iso9660
CD. Perhaps there's some sort of unique ID already provided by the
standard? Does somebody know 9660 better?
Of course, the ZIP drives are in another boat. A checksum might be
a good idea, yes.
--
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 Tue Jul 25 17:36:57 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id RAA19524
for current-outgoing; Tue, 25 Jul 1995 17:36:57 -0700
Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id RAA19513
for <current@FreeBSD.org>; Tue, 25 Jul 1995 17:36:52 -0700
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA28302; Tue, 25 Jul 1995 18:38:55 -0600
Date: Tue, 25 Jul 1995 18:38:55 -0600
Message-Id: <199507260038.SAA28302@rocky.sri.MT.net>
To: current@FreeBSD.org
Subject: Building boot floppies w/out space for two binary trees
Reply-To: nate@sneezy.sri.com (Nate Williams)
From: nate@sneezy.sri.com (Nate Williams)
Sender: current-owner@FreeBSD.org
Precedence: bulk
Is it possible? I don't (yet) have the space for a completely new
distribution, but I'd like to build boot.flp because I can't use the
GENERIC kernel on my laptop. However, if I go into /usr/src/release and
'make boot.flp' it blows up because I don't have all sorts of
environment variables and stuff setup, and after setting up most of them
it appears that it requires a completely filled out distribution tree.
Please tell me I'm confused and point me the way to an easy
boot.flp. :-<
Nate
From owner-freebsd-current Tue Jul 25 19:26:26 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA26658
for current-outgoing; Tue, 25 Jul 1995 19:26:26 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA26647
; Tue, 25 Jul 1995 19:26:22 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id TAA26319; Tue, 25 Jul 1995 19:24:05 -0700
To: Doug Rabson <dfr@render.com>
cc: "Jordan K. Hubbard" <jkh@freebsd.org>, current@freefall.cdrom.com
Subject: Re: Interesting NFS problem with -current
In-reply-to: Your message of "Mon, 24 Jul 1995 12:00:54 BST."
<Pine.BSF.3.91.950724115416.12542C-100000@minnow.render.com>
Date: Tue, 25 Jul 1995 19:24:05 -0700
Message-ID: <26316.806725445@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@freebsd.org
Precedence: bulk
> When a server changes a disk in its CD drive, all the clients should remount
> the filesystem to get a new root filehandle. With AMD, the only thing you
> can do is to reduce the timeout on the client or forcible unmount it using
> something like:
>
> amq -u /host/foo/cdrom
Sorry for the original misdiagnosis. I still think that this is something
that the server should deal with in a little less hostile a fashion
though. Having to reaquire a whole new mount handle just because a CD
swapped out of a drive seems a little.. extreme..
Jordan
From owner-freebsd-current Tue Jul 25 19:27:10 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA26774
for current-outgoing; Tue, 25 Jul 1995 19:27:10 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA26764
; Tue, 25 Jul 1995 19:27:07 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id TAA26487; Tue, 25 Jul 1995 19:24:57 -0700
To: Doug Rabson <dfr@render.com>
cc: "Jordan K. Hubbard" <jkh@freebsd.org>, current@freefall.cdrom.com
Subject: Re: Interesting NFS problem with -current
In-reply-to: Your message of "Mon, 24 Jul 1995 12:00:54 BST."
<Pine.BSF.3.91.950724115416.12542C-100000@minnow.render.com>
Date: Tue, 25 Jul 1995 19:24:56 -0700
Message-ID: <26483.806725496@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@freebsd.org
Precedence: bulk
> When a server changes a disk in its CD drive, all the clients should remount
> the filesystem to get a new root filehandle. With AMD, the only thing you
> can do is to reduce the timeout on the client or forcible unmount it using
> something like:
P.S. Unmounting and remounting the CD from the client doesn't have any
effect - you still get "Stale NFS handle"! Weird, no?
Jordan
From owner-freebsd-current Tue Jul 25 19:34:56 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA27571
for current-outgoing; Tue, 25 Jul 1995 19:34:56 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA27560
for <current@freebsd.org>; Tue, 25 Jul 1995 19:34:53 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id TAA29103; Tue, 25 Jul 1995 19:33:52 -0700
To: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
cc: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>, current@freebsd.org
Subject: Re: Knobs in /etc/sysconfig
In-reply-to: Your message of "Tue, 25 Jul 1995 10:19:38 EDT."
<9507251419.AA06573@halloran-eldar.lcs.mit.edu>
Date: Tue, 25 Jul 1995 19:33:52 -0700
Message-ID: <29101.806726032@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@freebsd.org
Precedence: bulk
> If you're going to go this far in the SysV direction (and in this one
> particular case it's not unreasonable), I would far rather have
> something like:
>
> if [ -d /etc/rc.local.d ]; then
> for script in /etc/rc.local.d/*.sh; do
> [ -x $script ] && $script start
> done
> fi
>
> if [ -x /etc/rc.local ]; then
> /etc/rc.local
> fi
I can live with that.. I read Satoshi's "all singing, all dancing"
proposal and have to say that this mechanism looks more reasonable,
albeit less flexible. I'm usually all for flexibility, but it's
possible to take it too far (like I did with bsd.port.mk :-).
> I don't like the idea of /etc/sysconfig.local as a dumping-ground for
> third-party software configuration options. Either there should be a
> third-party section in the real /etc/sysconfig, or there should be a
> separate config file for each service (/etc/rc.local.d/$service.cf?).
> I lean towards the former.
I can live with this too. Unless I hear some significant argument
to the contrary, I will "make it so" in a day or so..
Jordan
From owner-freebsd-current Tue Jul 25 19:58:34 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA29827
for current-outgoing; Tue, 25 Jul 1995 19:58:34 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA29818
; Tue, 25 Jul 1995 19:58:31 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id TAA12024; Tue, 25 Jul 1995 19:57:43 -0700
To: bde@freefall.cdrom.com
cc: current@freefall.cdrom.com
Subject: recent changes to cpio still breaking my world..
Date: Tue, 25 Jul 1995 19:57:42 -0700
Message-ID: <12010.806727462@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@FreeBSD.org
Precedence: bulk
Now it turns out that cpio doesn't accept the `-H newc' flag in
combination with the `-dump' options used to create floppies in the
release procedure.. In fact, it doesn't seem to accept ANY value for
-H..
This is really hanging me up, so unless a quick fix suggests itself in
the next 12 hours I am going to back out your original changes to cpio
that are causing me all this grief.
This is just a `heads up'.. Thanks!
Jordan
From owner-freebsd-current Tue Jul 25 20:06:22 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id UAA00475
for current-outgoing; Tue, 25 Jul 1995 20:06:22 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id UAA00465
; Tue, 25 Jul 1995 20:06:19 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id UAA16515; Tue, 25 Jul 1995 20:05:32 -0700
To: bde@freefall.cdrom.com
cc: current@freefall.cdrom.com
Subject: Never mind! :-}
Date: Tue, 25 Jul 1995 20:05:32 -0700
Message-ID: <16513.806727932@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@FreeBSD.org
Precedence: bulk
I just looked again and see that any kind of type flag with -dump is
probably silly since it's just doing a tree copy..
Hmmmmmm. Still, things are very broken still in
/usr/src/release/Makefile as a result of the cpio change and I may
STILL back it out to get moving again (since having it refuse to dump
ANY files due to this change is an error in my book for sure) but
please ignore my previous bug report as erroneous..
Jordan
From owner-freebsd-current Tue Jul 25 22:32:27 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id WAA05262
for current-outgoing; Tue, 25 Jul 1995 22:32:27 -0700
Received: from dracos.teton.com (dracos.teton.com [198.68.174.67])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id WAA05245
for <freebsd-current@freebsd.org>; Tue, 25 Jul 1995 22:32:22 -0700
Received: (from dsherwin@localhost) by dracos.teton.com (8.6.11/8.6.9) id WAA00419 for freebsd-current@freebsd.org; Tue, 25 Jul 1995 22:24:36 -0700
From: Dan Sherwin <dsherwin@dracos.teton.com>
Message-Id: <199507260524.WAA00419@dracos.teton.com>
Subject: NFS Probs
To: freebsd-current@freebsd.org
Date: Tue, 25 Jul 1995 22:24:35 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 250
Sender: current-owner@freebsd.org
Precedence: bulk
I am running 2.0.5-RELEASE on two systems on the same Network.
I have nfsd running on both.
On one system's exports file I have:
/usr -maproot=root <host>:root
Whenever I try to mount it, I get /usr: Permission Denied.
What am I doing wrong?
}Dan
From owner-freebsd-current Tue Jul 25 23:55:53 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id XAA08383
for current-outgoing; Tue, 25 Jul 1995 23:55:53 -0700
Received: (from phk@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id XAA08372
; Tue, 25 Jul 1995 23:55:52 -0700
From: Poul-Henning Kamp <phk>
Message-Id: <199507260655.XAA08372@freefall.cdrom.com>
Subject: Re: recent changes to cpio still breaking my world..
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Tue, 25 Jul 1995 23:55:52 -0700 (PDT)
Cc: bde@freefall.cdrom.com, current@freefall.cdrom.com
In-Reply-To: <12010.806727462@time.cdrom.com> from "Jordan K. Hubbard" at Jul 25, 95 07:57:42 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 823
Sender: current-owner@FreeBSD.org
Precedence: bulk
> Now it turns out that cpio doesn't accept the `-H newc' flag in
> combination with the `-dump' options used to create floppies in the
> release procedure.. In fact, it doesn't seem to accept ANY value for
> -H..
>
> This is really hanging me up, so unless a quick fix suggests itself in
> the next 12 hours I am going to back out your original changes to cpio
> that are causing me all this grief.
>
> This is just a `heads up'.. Thanks!
Well, I said so, with "-dump" there shouldn't be any problems with
minors, and -H <foo> should not be needed.
--
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.
Just that: dried leaves in boiling water ?
From owner-freebsd-current Wed Jul 26 02:09:35 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id CAA11985
for current-outgoing; Wed, 26 Jul 1995 02:09:35 -0700
Received: from who.cdrom.com (who.cdrom.com [192.216.222.3])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id CAA11979
for <current@freebsd.org>; Wed, 26 Jul 1995 02:09:33 -0700
Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34])
by who.cdrom.com (8.6.11/8.6.11) with ESMTP id BAA02123
for <current@freebsd.org>; Wed, 26 Jul 1995 01:58:30 -0700
Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id OAA06959; Wed, 26 Jul 1995 14:32:37 +0600
From: "Serge A. Babkin" <babkin@hq.icb.chel.su>
Message-Id: <199507260832.OAA06959@hq.icb.chel.su>
Subject: Re: ep driver
To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes)
Date: Wed, 26 Jul 1995 14:32:37 +0600 (GMT+0600)
Cc: current@freebsd.org
In-Reply-To: <199506221628.JAA06007@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jun 22, 95 09:28:14 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 15514
Sender: current-owner@freebsd.org
Precedence: bulk
> These patches should really be sent to -current now as we are
> no longer in a release code freeze.
Recently I have finally got the 950622-SNAP and found that the ep driver
in it is enough old. Commit please this patch to -current. It does:
- understands 3C509 cards in "plug-n-play" mode
- understands the cards after soft reboot from MS-DOS
- doesn't conflict with ie driver
- has multicast support
------------------------------- cut here -------------------------------
*** if_ep.c.205 Tue Jul 18 09:29:52 1995
--- if_ep.c Wed Jul 26 14:29:44 1995
***************
*** 38,45 ****
*/
/*
- * $Id: if_ep.c,v 1.28 1995/05/30 08:02:07 rgrimes Exp $
- *
* Promiscuous mode added and interrupt logic slightly changed
* to reduce the number of adapter failures. Transceiver select
* logic changed to use value from EEPROM. Autoconfiguration
--- 38,43 ----
***************
*** 100,105 ****
--- 98,104 ----
#include <i386/isa/isa_device.h>
#include <i386/isa/icu.h>
#include <i386/isa/if_epreg.h>
+ #include <i386/isa/elink.h>
static int epprobe __P((struct isa_device *));
static int epattach __P((struct isa_device *));
***************
*** 117,122 ****
--- 116,122 ----
static int send_ID_sequence __P((int));
static int get_eeprom_data __P((int, int));
+ static struct ep_board *ep_look_for_board_at(struct isa_device *);
struct ep_softc ep_softc[NEP];
***************
*** 132,143 ****
};
static struct kern_devconf kdc_ep[NEP] = { {
! 0, 0, 0, /* filled in by dev_attach */
"ep", 0, { MDDT_ISA, 0, "net" },
isa_generic_externalize, 0, 0, ISA_EXTERNALLEN,
! &kdc_isa0, /* parent */
! 0, /* parentdata */
! DC_UNCONFIGURED, /* state */
"3Com 3C509 Ethernet adapter",
DC_CLS_NETIF /* class */
} };
--- 132,143 ----
};
static struct kern_devconf kdc_ep[NEP] = { {
! 0, 0, 0, /* filled in by dev_attach */
"ep", 0, { MDDT_ISA, 0, "net" },
isa_generic_externalize, 0, 0, ISA_EXTERNALLEN,
! &kdc_isa0, /* parent */
! 0, /* parentdata */
! DC_BUSY, /* network interfaces are always ``open'' */
"3Com 3C509 Ethernet adapter",
DC_CLS_NETIF /* class */
} };
***************
*** 154,164 ****
int ep_current_tag = EP_LAST_TAG + 1;
! struct {
! int epb_addr; /* address of this board */
! char epb_used; /* was this entry already used for configuring ? */
! }
! ep_board[EP_MAX_BOARDS + 1];
static int
eeprom_rdy(is)
--- 154,160 ----
int ep_current_tag = EP_LAST_TAG + 1;
! struct ep_board ep_board[EP_MAX_BOARDS + 1];
static int
eeprom_rdy(is)
***************
*** 174,189 ****
return (1);
}
! static int
ep_look_for_board_at(is)
struct isa_device *is;
{
! int data, i, j, io_base, id_port = EP_ID_PORT;
int nisa = 0, neisa = 0;
if (ep_current_tag == (EP_LAST_TAG + 1)) {
/* Come here just one time */
!
/* Look for the EISA boards, leave them activated */
for(j = 1; j < 16; j++) {
io_base = (j * EP_EISA_START) | EP_EISA_W0;
--- 170,185 ----
return (1);
}
! static struct ep_board *
ep_look_for_board_at(is)
struct isa_device *is;
{
! int data, i, j, io_base, id_port = ELINK_ID_PORT;
int nisa = 0, neisa = 0;
if (ep_current_tag == (EP_LAST_TAG + 1)) {
/* Come here just one time */
!
/* Look for the EISA boards, leave them activated */
for(j = 1; j < 16; j++) {
io_base = (j * EP_EISA_START) | EP_EISA_W0;
***************
*** 191,197 ****
continue;
/* we must found 0x1f if the board is EISA configurated */
! if ((inw(io_base + EP_W0_ADDRESS_CFG) & 0x1f) != 0x1f)
continue;
/* Reset and Enable the card */
--- 187,193 ----
continue;
/* we must found 0x1f if the board is EISA configurated */
! if ((inw(io_base + EP_W0_ADDRESS_CFG) & 0x1f) != 0x1f)
continue;
/* Reset and Enable the card */
***************
*** 203,232 ****
* Once activated, all the registers are mapped in the range
* x000 - x00F, where x is the slot number.
*/
ep_board[neisa].epb_used = 0;
ep_board[neisa++].epb_addr = j * EP_EISA_START;
}
ep_current_tag--;
/* Look for the ISA boards. Init and leave them actived */
outb(id_port, 0xc0); /* Global reset */
DELAY(10000);
for (i = 0; i < EP_MAX_BOARDS; i++) {
outb(id_port, 0);
outb(id_port, 0);
send_ID_sequence(id_port);
data = get_eeprom_data(id_port, EEPROM_MFG_ID);
if (data != MFG_ID)
break;
/* resolve contention using the Ethernet address */
for (j = 0; j < 3; j++)
! data = get_eeprom_data(id_port, j);
ep_board[neisa+nisa].epb_used = 0;
ep_board[neisa+nisa++].epb_addr =
! (get_eeprom_data(id_port, EEPROM_ADDR_CFG) & 0x1f) * 0x10 + 0x200;
outb(id_port, ep_current_tag); /* tags board */
outb(id_port, ACTIVATE_ADAPTER_TO_CONFIG);
ep_current_tag--;
--- 199,260 ----
* Once activated, all the registers are mapped in the range
* x000 - x00F, where x is the slot number.
*/
+ ep_board[neisa].epb_isa = 0;
ep_board[neisa].epb_used = 0;
ep_board[neisa++].epb_addr = j * EP_EISA_START;
}
ep_current_tag--;
/* Look for the ISA boards. Init and leave them actived */
+ outb(id_port, 0);
+ outb(id_port, 0);
+
+ #if 0
+ send_ID_sequence(id_port);
+ #else
+ elink_idseq(0xCF);
+ #endif
+
+ #if 0
outb(id_port, 0xc0); /* Global reset */
+ #else
+ elink_reset();
+ #endif
DELAY(10000);
for (i = 0; i < EP_MAX_BOARDS; i++) {
outb(id_port, 0);
outb(id_port, 0);
+ #if 0
send_ID_sequence(id_port);
+ #else
+ elink_idseq(0xCF);
+ #endif
data = get_eeprom_data(id_port, EEPROM_MFG_ID);
if (data != MFG_ID)
break;
/* resolve contention using the Ethernet address */
+
+ for (j = 0; j < 3; j++)
+ get_eeprom_data(id_port, j);
+
+ /* and save this address for later use */
+
for (j = 0; j < 3; j++)
! ep_board[neisa+nisa].eth_addr[j] = get_eeprom_data(id_port, j);
+ ep_board[neisa+nisa].res_cfg =
+ get_eeprom_data(id_port, EEPROM_RESOURCE_CFG);
+
+ ep_board[neisa+nisa].prod_id =
+ get_eeprom_data(id_port, EEPROM_PROD_ID);
+
+ ep_board[neisa].epb_isa = 1;
ep_board[neisa+nisa].epb_used = 0;
ep_board[neisa+nisa++].epb_addr =
! (get_eeprom_data(id_port, EEPROM_ADDR_CFG) & 0x1f) * 0x10 + 0x200;
!
outb(id_port, ep_current_tag); /* tags board */
outb(id_port, ACTIVATE_ADAPTER_TO_CONFIG);
ep_current_tag--;
***************
*** 266,283 ****
IS_BASE=ep_board[i].epb_addr;
ep_board[i].epb_used=1;
! return 1;
} else {
for (i=0; ep_board[i].epb_addr && ep_board[i].epb_addr != IS_BASE; i++);
! if( ep_board[i].epb_used || ep_board[i].epb_addr != IS_BASE)
return 0;
if (inw(IS_BASE + EP_W0_EEPROM_COMMAND) & EEPROM_TST_MODE)
printf("ep%d: 3c5x9 at 0x%x in test mode. Erase pencil mark!\n",
is->id_unit, IS_BASE);
ep_board[i].epb_used=1;
! return 1;
}
}
--- 294,313 ----
IS_BASE=ep_board[i].epb_addr;
ep_board[i].epb_used=1;
!
! return &ep_board[i];
} else {
for (i=0; ep_board[i].epb_addr && ep_board[i].epb_addr != IS_BASE; i++);
! if( ep_board[i].epb_used || ep_board[i].epb_addr != IS_BASE)
return 0;
if (inw(IS_BASE + EP_W0_EEPROM_COMMAND) & EEPROM_TST_MODE)
printf("ep%d: 3c5x9 at 0x%x in test mode. Erase pencil mark!\n",
is->id_unit, IS_BASE);
ep_board[i].epb_used=1;
!
! return &ep_board[i];
}
}
***************
*** 306,327 ****
u_short k;
int i;
! ep_registerdev(is);
!
! if (!ep_look_for_board_at(is))
return (0);
/*
* The iobase was found and MFG_ID was 0x6d50. PROD_ID should be
* 0x9[0-f]50
*/
GO_WINDOW(0);
! k = get_e(is, EEPROM_PROD_ID);
if ((k & 0xf0ff) != (PROD_ID & 0xf0ff)) {
printf("epprobe: ignoring model %04x\n", k);
return (0);
}
! k = get_e(is, EEPROM_RESOURCE_CFG);
k >>= 12;
/* Now we have two cases again:
--- 336,356 ----
u_short k;
int i;
! if(( sc->epb=ep_look_for_board_at(is) )==0)
return (0);
/*
* The iobase was found and MFG_ID was 0x6d50. PROD_ID should be
* 0x9[0-f]50
*/
GO_WINDOW(0);
! k = sc->epb->epb_isa ? sc->epb->prod_id : get_e(is, EEPROM_PROD_ID);
if ((k & 0xf0ff) != (PROD_ID & 0xf0ff)) {
printf("epprobe: ignoring model %04x\n", k);
return (0);
}
! k = sc->epb->epb_isa ? sc->epb->res_cfg : get_e(is, EEPROM_RESOURCE_CFG);
!
k >>= 12;
/* Now we have two cases again:
***************
*** 396,402 ****
p = (u_short *) & sc->arpcom.ac_enaddr;
for (i = 0; i < 3; i++) {
GO_WINDOW(0);
! p[i] = htons(get_e(is, i));
GO_WINDOW(2);
outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i]));
}
--- 425,431 ----
p = (u_short *) & sc->arpcom.ac_enaddr;
for (i = 0; i < 3; i++) {
GO_WINDOW(0);
! p[i] = htons( sc->epb->epb_isa ? sc->epb->eth_addr[i] : get_e(is, i) );
GO_WINDOW(2);
outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i]));
}
***************
*** 423,429 ****
ifp->if_unit = is->id_unit;
ifp->if_name = "ep";
ifp->if_mtu = ETHERMTU;
! ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_NOTRAILERS;
ifp->if_init = epinit;
ifp->if_output = ether_output;
ifp->if_start = epstart;
--- 452,459 ----
ifp->if_unit = is->id_unit;
ifp->if_name = "ep";
ifp->if_mtu = ETHERMTU;
! ifp->if_flags = IFF_BROADCAST | IFF_MULTICAST |
! IFF_SIMPLEX | IFF_NOTRAILERS;
ifp->if_init = epinit;
ifp->if_output = ether_output;
ifp->if_start = epstart;
***************
*** 432,438 ****
ifp->if_timer=1;
if_attach(ifp);
! kdc_ep[is->id_unit].kdc_state = DC_BUSY;
/*
* Fill the hardware address into ifa_addr if we find an AF_LINK entry.
--- 462,468 ----
ifp->if_timer=1;
if_attach(ifp);
! ep_registerdev(is);
/*
* Fill the hardware address into ifa_addr if we find an AF_LINK entry.
***************
*** 455,464 ****
sc->rx_avg_pkt = 128;
/*
! * NOTE: In all this I multiply everything by 64.
! * W_s = the speed the CPU is able to write to the TX FIFO.
* T_s = the speed the board sends the info to the Ether.
! * W_s/T_s = 16 (represents 16/64) => W_s = 25 % of T_s.
* This will give us for a packet of 1500 bytes
* tx_start_thresh=1125 and for a pkt of 64 bytes tx_start_threshold=48.
* We prefer to start thinking the CPU is much slower than the Ethernet
--- 485,494 ----
sc->rx_avg_pkt = 128;
/*
! * NOTE: In all this I multiply everything by 64.
! * W_s = the speed the CPU is able to write to the TX FIFO.
* T_s = the speed the board sends the info to the Ether.
! * W_s/T_s = 16 (represents 16/64) => W_s = 25 % of T_s.
* This will give us for a packet of 1500 bytes
* tx_start_thresh=1125 and for a pkt of 64 bytes tx_start_threshold=48.
* We prefer to start thinking the CPU is much slower than the Ethernet
***************
*** 536,547 ****
outw(BASE + EP_COMMAND, SET_INTR_MASK | S_5_INTS);
! if(ifp->if_flags & IFF_PROMISC)
! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL |
! FIL_GROUP | FIL_BRDCST | FIL_ALL);
! else
! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL |
! FIL_GROUP | FIL_BRDCST);
/*
* S.B.
--- 566,577 ----
outw(BASE + EP_COMMAND, SET_INTR_MASK | S_5_INTS);
! if(ifp->if_flags & IFF_PROMISC)
! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL |
! FIL_GROUP | FIL_BRDCST | FIL_ALL);
! else
! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL |
! FIL_GROUP | FIL_BRDCST);
/*
* S.B.
***************
*** 814,820 ****
sc->rx_no_first, sc->rx_no_mbuf, sc->rx_bpf_disc, sc->rx_overrunf,
sc->rx_overrunl, sc->tx_underrun);
#else
! printf("ep%d: Status: %x\n", unit, status);
#endif
epinit(unit);
splx(x);
--- 844,850 ----
sc->rx_no_first, sc->rx_no_mbuf, sc->rx_bpf_disc, sc->rx_overrunf,
sc->rx_overrunl, sc->tx_underrun);
#else
! printf("ep%d: Status: %x\n", unit, status);
#endif
epinit(unit);
splx(x);
***************
*** 865,871 ****
outw(BASE + EP_COMMAND, C_INTR_LATCH); /* ACK int Latch */
! if ((status = inw(BASE + EP_STATUS)) & S_5_INTS)
goto rescan;
/* re-enable Ints */
--- 895,901 ----
outw(BASE + EP_COMMAND, C_INTR_LATCH); /* ACK int Latch */
! if ((status = inw(BASE + EP_STATUS)) & S_5_INTS)
goto rescan;
/* re-enable Ints */
***************
*** 1175,1180 ****
--- 1205,1211 ----
}
/* NOTREACHED */
+ #if 0
if (ifp->if_flags & IFF_UP && (ifp->if_flags & IFF_RUNNING) == 0)
epinit(ifp->if_unit);
***************
*** 1187,1192 ****
--- 1218,1224 ----
ep_frst(F_PROMISC);
epinit(ifp->if_unit);
}
+ #endif
break;
#ifdef notdef
***************
*** 1195,1212 ****
sizeof(sc->sc_addr));
break;
#endif
! case SIOCSIFMTU:
/*
* Set the interface MTU.
*/
! if (ifr->ifr_mtu > ETHERMTU) {
! error = EINVAL;
} else {
! ifp->if_mtu = ifr->ifr_mtu;
}
! break;
default:
error = EINVAL;
}
--- 1227,1255 ----
sizeof(sc->sc_addr));
break;
#endif
! case SIOCSIFMTU:
/*
* Set the interface MTU.
*/
! if (ifr->ifr_mtu > ETHERMTU) {
! error = EINVAL;
} else {
! ifp->if_mtu = ifr->ifr_mtu;
}
! break;
! case SIOCADDMULTI:
! case SIOCDELMULTI:
! error= (cmd==SIOCADDMULTI) ?
! ether_addmulti(ifr, &sc->arpcom) :
! ether_delmulti(ifr, &sc->arpcom);
+ if(error=ENETRESET) {
+ epinit(ifp->if_unit);
+ error=0;
+ }
+
+ break;
default:
error = EINVAL;
}
*** if_epreg.h.205 Tue Jul 18 09:29:43 1995
--- if_epreg.h Wed Jul 26 14:19:14 1995
***************
*** 31,37 ****
*/
/*
- * $Id: if_epreg.h,v 1.8 1995/05/30 08:02:09 rgrimes Exp $
*
* Promiscuous mode added and interrupt logic slightly changed
* to reduce the number of adapter failures. Transceiver select
--- 31,36 ----
***************
*** 71,76 ****
--- 70,77 ----
#define F_ACCESS_32_BITS 0x100
+ struct ep_board *epb;
+
#ifdef EP_LOCAL_STATS
short tx_underrun;
short rx_no_first;
***************
*** 80,85 ****
--- 81,97 ----
short rx_overrunl;
#endif
};
+
+ struct ep_board {
+ int epb_addr; /* address of this board */
+ char epb_used; /* was this entry already used for configuring ? */
+ /* data from EEPROM for later use */
+ char epb_isa; /* flag: this is an ISA card */
+ u_short eth_addr[3]; /* Ethernet address */
+ u_short prod_id; /* product ID */
+ u_short res_cfg; /* resource configuration */
+ };
+
/*
* Some global constants
------------------------------- cut here -------------------------------
Serge Babkin
! (babkin@hq.icb.chel.su)
! Headquarter of Joint Stock Commercial Bank "Chelindbank"
! Chelyabinsk, Russia
From owner-freebsd-current Wed Jul 26 02:20:07 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id CAA12352
for current-outgoing; Wed, 26 Jul 1995 02:20:07 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id CAA12345
for <current@freebsd.org>; Wed, 26 Jul 1995 02:20:03 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id CAA09648; Wed, 26 Jul 1995 02:18:04 -0700
Date: Wed, 26 Jul 1995 02:18:04 -0700
Message-Id: <199507260918.CAA09648@silvia.HIP.Berkeley.EDU>
To: bde@zeta.org.au
CC: current@freebsd.org
In-reply-to: <199507251528.BAA02402@godzilla.zeta.org.au> (message from Bruce Evans on Wed, 26 Jul 1995 01:28:53 +1000)
Subject: Re: does xdr_float addition requires minor number bumping or what?
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: current-owner@freebsd.org
Precedence: bulk
* That way we have to worry about newly compiled ports being annoying to
* use in 2.0.5R and maybe in 2.1. ld.so will print the confusing message:
Well, "newly compiled ports" are only guaranteed to work with
-current. :) Also, "annoying" users in this sense is GOOD, if they
are running packages not from packages-2.0.5, they should be warned.
* warning: libc.so.2.1: minor version < 2 expected; using it anway
*
* Perhaps ld.so meant to say "minor version < 2 UNexpected". I'd prefer
* it to say something like "minor version >= 2 expected; using #1 anyway".
If so, that's a bug in ld.so, and has to be fixed.
* OTOH if you don't bump the minor every time it is technically required,
* then newly compiled ports will mysteriously fail in 2.0.5R and maybe in
* 2.1 if they actually use the new features.
*
* I prefer things to fail unmysteriously :-).
So you agree with me, right, Bruce? :)
Satoshi
From owner-freebsd-current Wed Jul 26 02:20:15 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id CAA12372
for current-outgoing; Wed, 26 Jul 1995 02:20:15 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id CAA12361
for <current@freebsd.org>; Wed, 26 Jul 1995 02:20:13 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id CAA24712; Wed, 26 Jul 1995 02:19:26 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507260919.CAA24712@gndrsh.aac.dev.com>
Subject: Re: ep driver
To: babkin@hq.icb.chel.su (Serge A. Babkin)
Date: Wed, 26 Jul 1995 02:19:26 -0700 (PDT)
Cc: current@freebsd.org
In-Reply-To: <199507260832.OAA06959@hq.icb.chel.su> from "Serge A. Babkin" at Jul 26, 95 02:32:37 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: 1084
Sender: current-owner@freebsd.org
Precedence: bulk
>
> > These patches should really be sent to -current now as we are
> > no longer in a release code freeze.
>
> Recently I have finally got the 950622-SNAP and found that the ep driver
> in it is enough old. Commit please this patch to -current. It does:
>
> - understands 3C509 cards in "plug-n-play" mode
>
> - understands the cards after soft reboot from MS-DOS
>
> - doesn't conflict with ie driver
>
> - has multicast support
>
> ------------------------------- cut here -------------------------------
> *** if_ep.c.205 Tue Jul 18 09:29:52 1995
> --- if_ep.c Wed Jul 26 14:29:44 1995
> ***************
> *** 38,45 ****
> */
>
> /*
> - * $Id: if_ep.c,v 1.28 1995/05/30 08:02:07 rgrimes Exp $
> - *
> * Promiscuous mode added and interrupt logic slightly changed
Please, do _not_ submit patches that remove the $Id$ lines from files,
this makes it very hard to track down just what it is someone has!
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
From owner-freebsd-current Wed Jul 26 02:21:29 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id CAA12428
for current-outgoing; Wed, 26 Jul 1995 02:21:29 -0700
Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id CAA12421
for <current@freebsd.org>; Wed, 26 Jul 1995 02:21:23 -0700
Received: by FileServ1.MI.Uni-Koeln.DE id AA17878
(5.67b/IDA-1.5 for current@freebsd.org); Wed, 26 Jul 1995 11:19:41 +0200
Message-Id: <199507260919.AA17878@FileServ1.MI.Uni-Koeln.DE>
From: esser@zpr.uni-koeln.de (Stefan Esser)
Date: Wed, 26 Jul 1995 11:19:41 +0200
In-Reply-To: nate@sneezy.sri.com (Nate Williams)
"Building boot floppies w/out space for two binary trees" (Jul 25, 18:38)
X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95)
To: nate@sneezy.sri.com (Nate Williams)
Subject: Re: Building boot floppies w/out space for two binary trees
Cc: current@freebsd.org
Sender: current-owner@freebsd.org
Precedence: bulk
On Jul 25, 18:38, Nate Williams wrote:
} Subject: Building boot floppies w/out space for two binary trees
}
} Is it possible? I don't (yet) have the space for a completely new
} distribution, but I'd like to build boot.flp because I can't use the
} GENERIC kernel on my laptop. However, if I go into /usr/src/release and
} 'make boot.flp' it blows up because I don't have all sorts of
} environment variables and stuff setup, and after setting up most of them
} it appears that it requires a completely filled out distribution tree.
}
} Please tell me I'm confused and point me the way to an easy
} boot.flp. :-<
Same here ...
I wanted to send a modified boot.flp to someone to
evaluate some of PCI code changes, but stopped the
build process, when I found it wouldn't finish the
same day anyway :)
I've rebuild the world and have everything in place.
STefan
--
Stefan Esser Internet: <se@ZPR.Uni-Koeln.DE>
Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021
Universitaet zu Koeln FAX: +49 221 4705160
Weyertal 80
50931 Koeln
From owner-freebsd-current Wed Jul 26 04:57:51 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id EAA17097
for current-outgoing; Wed, 26 Jul 1995 04:57:51 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id EAA17090
for <current@freebsd.org>; Wed, 26 Jul 1995 04:57:49 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id EAA10190; Wed, 26 Jul 1995 04:57:37 -0700
Date: Wed, 26 Jul 1995 04:57:37 -0700
Message-Id: <199507261157.EAA10190@silvia.HIP.Berkeley.EDU>
To: jkh@time.cdrom.com
CC: wollman@halloran-eldar.lcs.mit.edu, rgrimes@gndrsh.aac.dev.com,
current@freebsd.org
In-reply-to: <29101.806726032@time.cdrom.com> (jkh@time.cdrom.com)
Subject: Re: Knobs in /etc/sysconfig
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: current-owner@freebsd.org
Precedence: bulk
* > if [ -d /etc/rc.local.d ]; then
* > for script in /etc/rc.local.d/*.sh; do
* > [ -x $script ] && $script start
* > done
* > fi
* I can live with that.. I read Satoshi's "all singing, all dancing"
* proposal and have to say that this mechanism looks more reasonable,
* albeit less flexible. I'm usually all for flexibility, but it's
* possible to take it too far (like I did with bsd.port.mk :-).
This isn't any different from my proposal as far as I can tell, except
that everything gets started in one chunk. If there is one place in
the bootup sequence that we can reliably start all the ports stuff,
that's all fine for me.
Satoshi
From owner-freebsd-current Wed Jul 26 05:05:14 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id FAA17451
for current-outgoing; Wed, 26 Jul 1995 05:05:14 -0700
Received: from eikon.regent.e-technik.tu-muenchen.de (eikon.regent.e-technik.tu-muenchen.de [129.187.42.3])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id FAA17443
for <current@freebsd.org>; Wed, 26 Jul 1995 05:05:07 -0700
Received: from vector.eikon.e-technik.tu-muenchen.de ([129.187.142.36]) by eikon.regent.e-technik.tu-muenchen.de with SMTP id <55305>; Wed, 26 Jul 1995 14:02:12 +0200
Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.11/8.6.9) with SMTP id MAA02858; Wed, 26 Jul 1995 12:04:25 +0200
Message-Id: <199507261004.MAA02858@vector.eikon.e-technik.tu-muenchen.de>
X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol
To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
cc: jkh@time.cdrom.com (Jordan K. Hubbard), current@freebsd.org
Subject: Re: Knobs in /etc/sysconfig
In-reply-to: Your message of "Tue, 25 Jul 1995 04:50:53 +0200."
<199507250250.TAA20607@gndrsh.aac.dev.com>
Date: Wed, 26 Jul 1995 12:04:24 +0200
From: "Julian Stacey <jhs@freebsd.org>" <jhs@vector.eikon.e-technik.tu-muenchen.de>
Sender: current-owner@freebsd.org
Precedence: bulk
> Why not appended it to /etc/rc.local
The purist in me cries for rc.local to be shipped empty !
The pragmatist in me admits rc.local was never really local ;-)
Julian S
From owner-freebsd-current Wed Jul 26 05:33:58 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id FAA18080
for current-outgoing; Wed, 26 Jul 1995 05:33:58 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id FAA18073
for <current@freebsd.org>; Wed, 26 Jul 1995 05:33:56 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id FAA25209; Wed, 26 Jul 1995 05:32:42 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507261232.FAA25209@gndrsh.aac.dev.com>
Subject: Re: Knobs in /etc/sysconfig
To: jhs@vector.eikon.e-technik.tu-muenchen.de (Julian Stacey)
Date: Wed, 26 Jul 1995 05:32:42 -0700 (PDT)
Cc: jkh@time.cdrom.com, current@freebsd.org
In-Reply-To: <199507261004.MAA02858@vector.eikon.e-technik.tu-muenchen.de> from "Julian Stacey" at Jul 26, 95 12:04:24 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: 518
Sender: current-owner@freebsd.org
Precedence: bulk
>
>
> > Why not appended it to /etc/rc.local
> The purist in me cries for rc.local to be shipped empty !
And some day it will be. Actually, some day it won't even ship
more than likely.
> The pragmatist in me admits rc.local was never really local ;-)
True, but that does not mean we can't give it back to the rightful
owner like we did with /usr/local.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
From owner-freebsd-current Wed Jul 26 05:52:17 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id FAA18576
for current-outgoing; Wed, 26 Jul 1995 05:52:17 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id FAA18552
for <freebsd-current@FreeBSD.org>; Wed, 26 Jul 1995 05:52:12 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA09845; Wed, 26 Jul 1995 14:51:57 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id OAA09069 for freebsd-current@FreeBSD.org; Wed, 26 Jul 1995 14:51:56 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id MAA13589 for freebsd-current@FreeBSD.org; Wed, 26 Jul 1995 12:46:50 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507261046.MAA13589@uriah.heep.sax.de>
Subject: Re: New options for lastcomm(1)
To: freebsd-current@FreeBSD.org (FreeBSD-current users)
Date: Wed, 26 Jul 1995 12:46:49 +0200 (MET DST)
Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users)
In-Reply-To: <199507251422.JAA10361@plains.nodak.edu> from "Mark Tinguely" at Jul 25, 95 09:22:29 am
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
Content-Length: 444
Sender: current-owner@FreeBSD.org
Precedence: bulk
As Mark Tinguely wrote:
>
> I did not see the original mail article on the changes, nor did I see
> anyone answer the later question on how to install (that is in the FAQ).
I've got an answer to my question on how to turn it on, and have it
running now. Expect me commiting Wolfram's changes RSN.
--
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 Wed Jul 26 05:52:51 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id FAA18705
for current-outgoing; Wed, 26 Jul 1995 05:52:51 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id FAA18629
for <freebsd-current@FreeBSD.org>; Wed, 26 Jul 1995 05:52:29 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA09870; Wed, 26 Jul 1995 14:52:11 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id OAA09080 for freebsd-current@FreeBSD.org; Wed, 26 Jul 1995 14:52:06 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id NAA13745 for freebsd-current@FreeBSD.org; Wed, 26 Jul 1995 13:12:39 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507261112.NAA13745@uriah.heep.sax.de>
Subject: Re: Interesting NFS problem with -current
To: freebsd-current@FreeBSD.org (FreeBSD-current users)
Date: Wed, 26 Jul 1995 13:12:38 +0200 (MET DST)
Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users)
In-Reply-To: <9507252053.AA17127@cs.weber.edu> from "Terry Lambert" at Jul 25, 95 02:53:09 pm
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
Content-Length: 1140
Sender: current-owner@FreeBSD.org
Precedence: bulk
As Terry Lambert wrote:
>
> We're worried about media changes, right? Ones that don't involve
> remounting the same media?
Yup.
> There's supposed to be a unique disk ID generated from the manufacturer
> and a manufacturer ID for that.
>
> In practice, this almost never happens. Ask Jordan why. 8-).
:-/ It won't help for other removable media either (e.g. ZIP drives),
and i guess (without looking into it) that the current sd driver
doesn't handle this case very gracefully at all.
> I think the MD5 checksum is probably the best mechanism.
Yup. Or some other CRC mechanism, does somebody know whether there's
already something available in the kernel?
> I'd use the root directory blocks, however, which means generating
> it at mount time. There's no guarantee that there will even be data
> other than a potentially non-unique header at the front of the disk.
The root directory, or the media descriptor (or whatever it is
actually named; i mean the bytes starting at 0x8000).
--
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 Wed Jul 26 05:52:51 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id FAA18707
for current-outgoing; Wed, 26 Jul 1995 05:52:51 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id FAA18652
for <freebsd-current@FreeBSD.org>; Wed, 26 Jul 1995 05:52:31 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA09873; Wed, 26 Jul 1995 14:52:13 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id OAA09083 for freebsd-current@FreeBSD.org; Wed, 26 Jul 1995 14:52:07 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id NAA13799 for freebsd-current@FreeBSD.org; Wed, 26 Jul 1995 13:17:13 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507261117.NAA13799@uriah.heep.sax.de>
Subject: Re: Building boot floppies w/out space for two binary trees
To: freebsd-current@FreeBSD.org (FreeBSD-current users)
Date: Wed, 26 Jul 1995 13:17:13 +0200 (MET DST)
Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users)
In-Reply-To: <199507260038.SAA28302@rocky.sri.MT.net> from "Nate Williams" at Jul 25, 95 06:38:55 pm
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
Content-Length: 704
Sender: current-owner@FreeBSD.org
Precedence: bulk
As Nate Williams wrote:
>
>
> Is it possible? I don't (yet) have the space for a completely new
> distribution, but I'd like to build boot.flp because I can't use the
> GENERIC kernel on my laptop. However, if I go into /usr/src/release and
> 'make boot.flp' it blows up because I don't have all sorts of
> environment variables and stuff setup, and after setting up most of them
> it appears that it requires a completely filled out distribution tree.
Chris Kukulies ran into the same sort of problems yesterday when
attempting to build a fixit.flp. :-(
--
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 Wed Jul 26 06:40:45 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id GAA19838
for current-outgoing; Wed, 26 Jul 1995 06:40:45 -0700
Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id GAA19832
for <current@FREEBSD.ORG>; Wed, 26 Jul 1995 06:40:43 -0700
Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id XAA05059; Wed, 26 Jul 1995 23:29:11 +0930
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Message-Id: <199507261359.XAA05059@genesis.atrad.adelaide.edu.au>
Subject: Re: Knobs in /etc/sysconfig
To: asami@cs.berkeley.edu (Satoshi Asami)
Date: Wed, 26 Jul 1995 23:29:10 +0930 (CST)
Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com,
rgrimes@gndrsh.aac.dev.com, current@FREEBSD.ORG
In-Reply-To: <199507261206.FAA10240@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Jul 26, 95 05:06:47 am
Content-Type: text
Content-Length: 3089
Sender: current-owner@FREEBSD.ORG
Precedence: bulk
Satoshi Asami stands accused of saying:
> I'm not sure why you say so. My guess is that for most of the ports,
> it doesn't matter in which order it's started (relative to the other
> ports daemons). Only a few of them would actually depend on another
> port, and we'll have to be sure we assign numbers to them in correct
> order.
>
> And the numbers don't have to be unique. In fact, I think most ports
> can have the same sequence number, the canonical "50" or something
> like that.
Until you find yourself in the situation where A & B are independant of
one another had have the same number, but the new port C has to
fit between them. The solution is close, but not adequate.
> * If you can handle keeping a list of 'what goes before/what goes after'
> * for each port, then a sequentially arranged list in a control file
> * could be realistically managed, with entries inserted and deleted as
> * packages come and go.
>
> You make it sound so easy. How are you going to go about that?
> Please write a sed script for me. :)
I'm not a sed guru, so I'm not going to humiliate myself 8) It'd be
relatively simple to implement with a linked list in any structured
language.
> Also, unless we add another program to the system that handles this,
> we'll have to let the porters write sed scripts. Even if we have a
> template, this is bad, as someone can make a mistake and totally screw
> up the system.
It would fit into the dependency concept that we already have; you list
for a given port anything that must preceed or follow it, nothing else.
Then, when something gets added to the file, you skip lines in the file
until you pass everything that you must follow, meet something you must
preceed, or hit the end of the file, and insert it there.
(Then you scan the rest of the file to make sure that its consistent with
your view of the world. There's scope here for the A,B,C situation
described above to cause grief, but if the preceed/follow lists for
all the ports are available the reshuffle can either be resolved or you
have an inconsistency in the ordering.)
> Making automation easier is the whole point of the ports/packages. :)
> Also, I don't understand why this would increase the pain of work by
> hand.
If the files are plaintext (as would probably be the case), you open
yourself up to a much greater risk of inadvertent damage as you increase
their structuredness (8)).
> Satoshi
The question remains; how carried away do we want to get about this?
I'm generally fond of doing things "properly", but that's as much a
matter of perception as anything.
How is this likely to relate to the assumedly imminent restructuring of
the package management tools?
--
]] 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 [[
From owner-freebsd-current Wed Jul 26 06:40:51 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id GAA19867
for current-outgoing; Wed, 26 Jul 1995 06:40:51 -0700
Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id GAA19860
for <freebsd-current@freebsd.org>; Wed, 26 Jul 1995 06:40:50 -0700
Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA08157; Wed, 26 Jul 1995 09:40:46 -0400
Date: Wed, 26 Jul 1995 09:40:46 -0400
From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
Message-Id: <9507261340.AA08157@halloran-eldar.lcs.mit.edu>
To: terry@cs.weber.edu (Terry Lambert)
Cc: freebsd-current@freebsd.org
Subject: Re: what's going on here? (NFSv3 problem?)
In-Reply-To: <9507252105.AA17181@cs.weber.edu>
References: <Pine.BSF.3.91.950725102458.230B-100000@minnow.render.com>
<9507252105.AA17181@cs.weber.edu>
Sender: current-owner@freebsd.org
Precedence: bulk
<<On Tue, 25 Jul 95 15:05:57 MDT, terry@cs.weber.edu (Terry Lambert) said:
> I have some mount system call changes to get rid of the manifest constants
> for file system types, and some user space utilites to clean up to
> handle those changes, next.
This will, of course, use the defined getvfsbyname() interface, right?
-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 Jul 26 07:08:48 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id HAA20689
for current-outgoing; Wed, 26 Jul 1995 07:08:48 -0700
Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id HAA20683
for <current@freebsd.org>; Wed, 26 Jul 1995 07:08:44 -0700
Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA08195; Wed, 26 Jul 1995 10:06:57 -0400
Date: Wed, 26 Jul 1995 10:06:57 -0400
From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
Message-Id: <9507261406.AA08195@halloran-eldar.lcs.mit.edu>
To: "Serge A. Babkin" <babkin@hq.icb.chel.su>
Cc: current@freebsd.org
Subject: Re: ep driver
In-Reply-To: <199507260832.OAA06959@hq.icb.chel.su>
References: <199506221628.JAA06007@gndrsh.aac.dev.com>
<199507260832.OAA06959@hq.icb.chel.su>
Sender: current-owner@freebsd.org
Precedence: bulk
DO NOT COMMIT THIS PATCH!
<<On Wed, 26 Jul 1995 14:32:37 +0600 (GMT+0600), "Serge A. Babkin" <babkin@hq.icb.chel.su> said:
> ! DC_UNCONFIGURED, /* state */
> --- 132,143 ----
> ! DC_BUSY, /* network interfaces are always ``open'' */
Serge, please fix your patch to correctly track the device state.
-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 Jul 26 08:16:20 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id IAA23150
for current-outgoing; Wed, 26 Jul 1995 08:16:20 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id IAA23140
; Wed, 26 Jul 1995 08:16:10 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA12501; Thu, 27 Jul 1995 01:09:25 +1000
Date: Thu, 27 Jul 1995 01:09:25 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507261509.BAA12501@godzilla.zeta.org.au>
To: bde@freefall.cdrom.com, jkh@time.cdrom.com
Subject: Re: recent changes to cpio still breaking my world..
Cc: current@freefall.cdrom.com
Sender: current-owner@FreeBSD.org
Precedence: bulk
>Now it turns out that cpio doesn't accept the `-H newc' flag in
>combination with the `-dump' options used to create floppies in the
>release procedure.. In fact, it doesn't seem to accept ANY value for
>-H..
That's because copy-pass mode doesn't involve an archive so the original
bug, my fixes and -H are irrelevant for it. I thought you only need -H
in the one place where it is already used.
Bruce
From owner-freebsd-current Wed Jul 26 08:30:46 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id IAA24093
for current-outgoing; Wed, 26 Jul 1995 08:30:46 -0700
Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id IAA24060
for <current@freebsd.org>; Wed, 26 Jul 1995 08:30:25 -0700
Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id QAA16201; Wed, 26 Jul 1995 16:28:24 +0100
From: Paul Richards <paul@netcraft.co.uk>
Message-Id: <199507261528.QAA16201@server.netcraft.co.uk>
Subject: Re: Knobs in /etc/sysconfig
To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman)
Date: Wed, 26 Jul 1995 16:28:23 +0100 (BST)
Cc: jkh@time.cdrom.com, rgrimes@gndrsh.aac.dev.com, current@freebsd.org
In-Reply-To: <9507251419.AA06573@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 25, 95 10:19: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: 729
Sender: current-owner@freebsd.org
Precedence: bulk
In reply to Garrett Wollman who said
>
> <<On Mon, 24 Jul 1995 20:21:04 -0700, "Jordan K. Hubbard" <jkh@time.cdrom.com> said:
>
> I don't like the idea of /etc/sysconfig.local as a dumping-ground for
> third-party software configuration options. Either there should be a
> third-party section in the real /etc/sysconfig, or there should be a
> separate config file for each service (/etc/rc.local.d/$service.cf?).
> I lean towards the former.
Anything wrong with /usr/local/etc ? I don't like third party
packages touching /etc period.
--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
From owner-freebsd-current Wed Jul 26 08:33:19 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id IAA24292
for current-outgoing; Wed, 26 Jul 1995 08:33:19 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id IAA24245
; Wed, 26 Jul 1995 08:32:47 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA13030; Thu, 27 Jul 1995 01:28:30 +1000
Date: Thu, 27 Jul 1995 01:28:30 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507261528.BAA13030@godzilla.zeta.org.au>
To: bde@freefall.cdrom.com, jkh@time.cdrom.com
Subject: Re: Never mind! :-}
Cc: current@freefall.cdrom.com
Sender: current-owner@FreeBSD.org
Precedence: bulk
>Hmmmmmm. Still, things are very broken still in
>/usr/src/release/Makefile as a result of the cpio change and I may
>STILL back it out to get moving again (since having it refuse to dump
>ANY files due to this change is an error in my book for sure) but
>please ignore my previous bug report as erroneous..
:-( Why not fix the actual bug(s):
1) stat() returns garbage for st_rdev for regular files (perhaps for all
non-device files). st_rdev is an implementation-define extension of
POSIX.
2) cpio attempts to write garbage for st_rdev if stat() returns garbage.
POSIX specifies what is to be written only for character and block-
special files.
tar avoids the problem by only checking the garbage for character and block
special files. I think it gets truncated otherwise.
pax avoids the problem by zeroing st_rdev except for character and block
special files before checking it.
I think the pax approach is correct.
Why not use pax instead of cpio? It seems to do some things better, but
it seems to be little used so the bugs in it aren't known.
Bruce
From owner-freebsd-current Wed Jul 26 10:23:44 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA29431
for current-outgoing; Wed, 26 Jul 1995 10:23:44 -0700
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id KAA29425
for <current@freebsd.org>; Wed, 26 Jul 1995 10:23:43 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14645(2)>; Wed, 26 Jul 1995 10:22:55 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Wed, 26 Jul 1995 10:22:39 -0700
To: "Serge A. Babkin" <babkin@hq.icb.chel.su>
cc: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes), current@freebsd.org
Subject: Re: ep driver
In-reply-to: Your message of "Wed, 26 Jul 95 01:32:37 PDT."
<199507260832.OAA06959@hq.icb.chel.su>
Date: Wed, 26 Jul 1995 10:22:28 PDT
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <95Jul26.102239pdt.177475@crevenia.parc.xerox.com>
Sender: current-owner@freebsd.org
Precedence: bulk
In message <199507260832.OAA06959@hq.icb.chel.su> you write:
>- has multicast support
If nobody is going to figure out how to program the multicast filters,
then this diff might as well be something like
>! case SIOCADDMULTI:
>! case SIOCDELMULTI:
>! error=0;
>! break;
and you can save the overhead of calling epinit().
Bill
From owner-freebsd-current Wed Jul 26 11:04:29 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id LAA03143
for current-outgoing; Wed, 26 Jul 1995 11:04:29 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id LAA03131
; Wed, 26 Jul 1995 11:04:26 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id LAA25920; Wed, 26 Jul 1995 11:04:17 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507261804.LAA25920@gndrsh.aac.dev.com>
Subject: Re: Knobs in /etc/sysconfig
To: paul@freebsd.org
Date: Wed, 26 Jul 1995 11:04:17 -0700 (PDT)
Cc: wollman@halloran-eldar.lcs.mit.edu, jkh@time.cdrom.com,
current@freebsd.org
In-Reply-To: <199507261528.QAA16201@server.netcraft.co.uk> from "Paul Richards" at Jul 26, 95 04:28: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: 1074
Sender: current-owner@freebsd.org
Precedence: bulk
>
> In reply to Garrett Wollman who said
> >
> > <<On Mon, 24 Jul 1995 20:21:04 -0700, "Jordan K. Hubbard" <jkh@time.cdrom.com> said:
> >
> > I don't like the idea of /etc/sysconfig.local as a dumping-ground for
> > third-party software configuration options. Either there should be a
> > third-party section in the real /etc/sysconfig, or there should be a
> > separate config file for each service (/etc/rc.local.d/$service.cf?).
> > I lean towards the former.
>
> Anything wrong with /usr/local/etc ? I don't like third party
> packages touching /etc period.
Yes, there is something wrong with /usr/local/etc, that would be imposing
a structure on one place (/usr/local) we said we would absolutely not do
that to in the base system.
I don't like third party packages touching _anything_ in the base system,
and we have gone to a lot of work to minimize it. Now we just need to
cross the last few hurdles.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
From owner-freebsd-current Wed Jul 26 11:18:18 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id LAA04488
for current-outgoing; Wed, 26 Jul 1995 11:18:18 -0700
Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id LAA04471
; Wed, 26 Jul 1995 11:18:11 -0700
Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id TAA29188; Wed, 26 Jul 1995 19:17:17 +0100
From: Paul Richards <paul@netcraft.co.uk>
Message-Id: <199507261817.TAA29188@server.netcraft.co.uk>
Subject: Re: Knobs in /etc/sysconfig
To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes)
Date: Wed, 26 Jul 1995 19:17:17 +0100 (BST)
Cc: paul@freebsd.org, wollman@halloran-eldar.lcs.mit.edu, jkh@time.cdrom.com,
current@freebsd.org
In-Reply-To: <199507261804.LAA25920@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 26, 95 11:04:17 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: 642
Sender: current-owner@freebsd.org
Precedence: bulk
In reply to Rodney W. Grimes who said
>
>
> Yes, there is something wrong with /usr/local/etc, that would be imposing
> a structure on one place (/usr/local) we said we would absolutely not do
> that to in the base system.
>
Yeah but we're talking about *our* packages here and allowing them
to install hooks to start themselves up. Our packages already place
a structure on /usr/local so they might as well include their startup
files there too.
--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
From owner-freebsd-current Wed Jul 26 11:34:01 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id LAA07173
for current-outgoing; Wed, 26 Jul 1995 11:34:01 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id LAA07165
for <current@freebsd.org>; Wed, 26 Jul 1995 11:33:59 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id LAA20174; Wed, 26 Jul 1995 11:32:58 -0700
To: asami@cs.berkeley.edu (Satoshi Asami)
cc: wollman@halloran-eldar.lcs.mit.edu, rgrimes@gndrsh.aac.dev.com,
current@freebsd.org
Subject: Re: Knobs in /etc/sysconfig
In-reply-to: Your message of "Wed, 26 Jul 1995 04:57:37 PDT."
<199507261157.EAA10190@silvia.HIP.Berkeley.EDU>
Date: Wed, 26 Jul 1995 11:32:58 -0700
Message-ID: <20172.806783578@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@freebsd.org
Precedence: bulk
> This isn't any different from my proposal as far as I can tell, except
> that everything gets started in one chunk. If there is one place in
> the bootup sequence that we can reliably start all the ports stuff,
> that's all fine for me.
Well, it's also different in that a port will be required to add itself
to the appropriate category startup rather than creating its own file.
I'm not sure what happens if the startup file isn't there yet - maybe
it gets created and added to the list in sysconfig? Hmmmm. Bleah..
I think I would prefer a fixed number of categories and some prototype
files that essentially do nothing out of the box. That would at least
narrow the number of things needing to be changed to one file.
Jordan
From owner-freebsd-current Wed Jul 26 11:56:33 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id LAA11238
for current-outgoing; Wed, 26 Jul 1995 11:56:33 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id LAA11226
; Wed, 26 Jul 1995 11:56:29 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id LAA20274; Wed, 26 Jul 1995 11:55:21 -0700
To: Bruce Evans <bde@zeta.org.au>
cc: bde@freefall.cdrom.com, current@freefall.cdrom.com
Subject: Re: Never mind! :-}
In-reply-to: Your message of "Thu, 27 Jul 1995 01:28:30 +1000."
<199507261528.BAA13030@godzilla.zeta.org.au>
Date: Wed, 26 Jul 1995 11:55:20 -0700
Message-ID: <20271.806784920@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@FreeBSD.org
Precedence: bulk
> tar avoids the problem by only checking the garbage for character and block
> special files. I think it gets truncated otherwise.
>
> pax avoids the problem by zeroing st_rdev except for character and block
> special files before checking it.
I'm all for fixing bugs at their source, but why not make cpio do the
same thing for the time being? I'm loath to switch horses right now
due to unforseen problems. Maybe I'll revisit the whole "which
archiver we use" issue shortly, but I just wanted to get working
again. I seem to have done so in any case and will be releasing a
SNAP shortly..
Jordan
From owner-freebsd-current Wed Jul 26 12:02:04 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id MAA12127
for current-outgoing; Wed, 26 Jul 1995 12:02:04 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id MAA12110
; Wed, 26 Jul 1995 12:01:57 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id MAA26634; Wed, 26 Jul 1995 12:01:48 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507261901.MAA26634@gndrsh.aac.dev.com>
Subject: Re: Knobs in /etc/sysconfig
To: paul@freebsd.org
Date: Wed, 26 Jul 1995 12:01:48 -0700 (PDT)
Cc: wollman@halloran-eldar.lcs.mit.edu, jkh@time.cdrom.com,
current@freebsd.org
In-Reply-To: <199507261817.TAA29188@server.netcraft.co.uk> from "Paul Richards" at Jul 26, 95 07:17:17 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: 894
Sender: current-owner@freebsd.org
Precedence: bulk
>
> In reply to Rodney W. Grimes who said
> >
> >
> > Yes, there is something wrong with /usr/local/etc, that would be imposing
> > a structure on one place (/usr/local) we said we would absolutely not do
> > that to in the base system.
> >
>
> Yeah but we're talking about *our* packages here and allowing them
> to install hooks to start themselves up. Our packages already place
> a structure on /usr/local so they might as well include their startup
> files there too.
The package mechanism went to great pains to allow other locations than
/usr/local for this stuff, fixing that location in an /etc file would
be counter productive to this effort.
I can install all (or almost all) of the packages in /opt if I so choose
to.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
From owner-freebsd-current Wed Jul 26 12:08:10 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id MAA13231
for current-outgoing; Wed, 26 Jul 1995 12:08:10 -0700
Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id MAA13215
; Wed, 26 Jul 1995 12:08:07 -0700
Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id UAA29590; Wed, 26 Jul 1995 20:07:13 +0100
From: Paul Richards <paul@netcraft.co.uk>
Message-Id: <199507261907.UAA29590@server.netcraft.co.uk>
Subject: Re: Knobs in /etc/sysconfig
To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes)
Date: Wed, 26 Jul 1995 20:07:12 +0100 (BST)
Cc: paul@freebsd.org, wollman@halloran-eldar.lcs.mit.edu, jkh@time.cdrom.com,
current@freebsd.org
In-Reply-To: <199507261901.MAA26634@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 26, 95 12:01:48 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: 1244
Sender: current-owner@freebsd.org
Precedence: bulk
In reply to Rodney W. Grimes who said
>
> The package mechanism went to great pains to allow other locations than
> /usr/local for this stuff, fixing that location in an /etc file would
> be counter productive to this effort.
>
> I can install all (or almost all) of the packages in /opt if I so choose
> to.
Ok, the use /opt/etc :-)
Seriously, what I'd suggest is that a knob be added to /etc/sysconfig
such as
packages_startup= /usr/local/etc
and then the package installation code honour that flag and use it to
place their startup files. We just need one hook in /etc then that calls
something in packages_startup. If Satoshi thinks up a simple registration
system, such as just adding a line to packages_startup/startme, then
this will all work with little effort and we avoid lots of little files
getting added to /etc for each installed package.
Installing a package is then a process of, checking /etc/sysconfig to
see where package startup files go, installing them there and doing
any other mess with startup files there instead of /etc.
--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
From owner-freebsd-current Wed Jul 26 12:10:25 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id MAA13677
for current-outgoing; Wed, 26 Jul 1995 12:10:25 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id MAA13659
; Wed, 26 Jul 1995 12:10:22 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id MAA26721; Wed, 26 Jul 1995 12:10:13 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507261910.MAA26721@gndrsh.aac.dev.com>
Subject: Re: Knobs in /etc/sysconfig
To: paul@freebsd.org
Date: Wed, 26 Jul 1995 12:10:13 -0700 (PDT)
Cc: wollman@halloran-eldar.lcs.mit.edu, jkh@time.cdrom.com,
current@freebsd.org
In-Reply-To: <199507261907.UAA29590@server.netcraft.co.uk> from "Paul Richards" at Jul 26, 95 08:07: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: 1609
Sender: current-owner@freebsd.org
Precedence: bulk
>
> In reply to Rodney W. Grimes who said
> >
> > The package mechanism went to great pains to allow other locations than
> > /usr/local for this stuff, fixing that location in an /etc file would
> > be counter productive to this effort.
> >
> > I can install all (or almost all) of the packages in /opt if I so choose
> > to.
>
> Ok, the use /opt/etc :-)
>
> Seriously, what I'd suggest is that a knob be added to /etc/sysconfig
> such as
>
> packages_startup= /usr/local/etc
>
> and then the package installation code honour that flag and use it to
> place their startup files. We just need one hook in /etc then that calls
> something in packages_startup. If Satoshi thinks up a simple registration
> system, such as just adding a line to packages_startup/startme, then
> this will all work with little effort and we avoid lots of little files
> getting added to /etc for each installed package.
Now that I can live with, infact that is the best solution I have seen
to this problem yet!
> Installing a package is then a process of, checking /etc/sysconfig to
> see where package startup files go, installing them there and doing
> any other mess with startup files there instead of /etc.
Maybe even make that slightly more global:
/etc/sysconfig: package_root= /usr/local
Then pkg_install has a better place to pick up the default for all
of its work. And saves those who use something other than /usr/local
a few command line arguments.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
From owner-freebsd-current Wed Jul 26 12:13:37 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id MAA14235
for current-outgoing; Wed, 26 Jul 1995 12:13:37 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id MAA14218
for <freebsd-current@freebsd.org>; Wed, 26 Jul 1995 12:13:33 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA22866; Wed, 26 Jul 95 13:06:15 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507261906.AA22866@cs.weber.edu>
Subject: Re: what's going on here? (NFSv3 problem?)
To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman)
Date: Wed, 26 Jul 95 13:06:14 MDT
Cc: freebsd-current@freebsd.org
In-Reply-To: <9507261340.AA08157@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 26, 95 09:40:46 am
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@freebsd.org
Precedence: bulk
> <<On Tue, 25 Jul 95 15:05:57 MDT, terry@cs.weber.edu (Terry Lambert) said:
>
> > I have some mount system call changes to get rid of the manifest constants
> > for file system types, and some user space utilites to clean up to
> > handle those changes, next.
>
> This will, of course, use the defined getvfsbyname() interface, right?
Yes. It will also replace the user space mount utility and other
per file system utilties with a file system independent and a file
system dependent piece.
I was thinking of /sbin/fs/<fsname>/<utility name> for the per file
system utilities.
The agregate of the changes will be such that by adding a kernel
module and a directory to /sbin/fs/, you will have a new file system
type available without changing, for instance, the enumerated type
fields in sys/mount.h.
Clearly, I don't have modified mount code yet -- or at least not
that is suitable for patches.
The intent here is to modularize the installable filesystem interface.
The patches (which I have promised to upload today) to do away with
XXX_mountroot frobs should mean that any new file system type
which exists in the kernel at the time root is to be mounted can
be used as a root file system.
I expect to have to use this for OSF/1 UFS and AIX JFS.
I haven't hacked on the NFS code, and some of the CD9660 code is
actually very broken, IMO, so I haven't fully modified kern/init_main.c
or i386/i386/autoconf.c to remove the per FS type frobbing which is
being done there. I figure that code cleanup will have to wait
until it has been pounded out a bit.
The CD9660 code is unhappy because it screws around with options
on the mount rather than the mount auto-detecting format (the
Sun HFS support is the only one that's really self-imposing).
The MSDOSFS root mount code isn't entirely broken, unless you consider
the MSDOSFS code itself to be broken (which it is), so I'm torn
between hacking it out and saving the DOSFS root mount code until
someone can do a decent long name support mechanism, hopefully ala
Windows95.
I have added a vfs_mountroot routine to kern/vfs_conf.c that takes
as its argument a pointer to the FS specific vfsops vector.
I was in vfs_init.c the other day, and it is pretty obvious where
the Heidemann code was pounded on to jam it into the BSD mountable
file system paradigm.
A cleanup of that code will have to wait until I'm willing to take
about a week for it, since it will mean changing the lkm code as
well. This would be a change for the better, since it would mean
a common interface for file system registration. I really don't
want to clean up the pardigm -- the Heidemann code *says* that it
is bogus to supply an opvector without supplying an entry vector,
but I'm not totoally sure I agree with that. For instance, there
should probably be a disction between block and directory management
code and the bottom end of FFS wants to be unaware of the system
interface as much as possible... to the point of being able to be
stacked on something other than UFS, in fact.
That's really only a possible future direction for the code.
Some of the use of linker set code is garbage and really ought to go.
The set assembly is predicated on the existance of a manifest constant
being declared (ie: "MFS"), and so is just as suitably done using
the manifest constant instead.
Or the manifest constant should go (the mountroot work means that
the problem is really being tackled from both ends).
While on that topic, didn't anyone notice that the PCI code is the
only code that actually uses the linker set length field? Everything
else looks for the NULL record at the end of the set. Does anyone
want to clean up the PCI code to do the same, and get rid of the
length field altogether?
More later,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Wed Jul 26 12:36:18 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id MAA17866
for current-outgoing; Wed, 26 Jul 1995 12:36:18 -0700
Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id MAA17852
for <freebsd-current@freebsd.org>; Wed, 26 Jul 1995 12:36:16 -0700
Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA08840; Wed, 26 Jul 1995 15:36:05 -0400
Date: Wed, 26 Jul 1995 15:36:05 -0400
From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
Message-Id: <9507261936.AA08840@halloran-eldar.lcs.mit.edu>
To: terry@cs.weber.edu (Terry Lambert)
Cc: freebsd-current@freebsd.org
Subject: ls_length in struct linker_set
In-Reply-To: <9507261906.AA22866@cs.weber.edu>
References: <9507261340.AA08157@halloran-eldar.lcs.mit.edu>
<9507261906.AA22866@cs.weber.edu>
Sender: current-owner@freebsd.org
Precedence: bulk
<<On Wed, 26 Jul 95 13:06:14 MDT, terry@cs.weber.edu (Terry Lambert) said:
> While on that topic, didn't anyone notice that the PCI code is the
> only code that actually uses the linker set length field? Everything
> else looks for the NULL record at the end of the set. Does anyone
> want to clean up the PCI code to do the same, and get rid of the
> length field altogether?
The layout of the structure is defined by GNU ld, so I would not want
to touch it since other GNUware may depend on it for correct
operation. See gnu/usr.bin/ld/ld.h, as I recall, near where it
defines N_SETT etc.
-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 Jul 26 13:49:55 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id NAA21773
for current-outgoing; Wed, 26 Jul 1995 13:49:55 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id NAA21766
for <freebsd-current@freebsd.org>; Wed, 26 Jul 1995 13:49:51 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA23200; Wed, 26 Jul 95 14:41:37 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507262041.AA23200@cs.weber.edu>
Subject: Re: ls_length in struct linker_set
To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman)
Date: Wed, 26 Jul 95 14:41:36 MDT
Cc: freebsd-current@freebsd.org
In-Reply-To: <9507261936.AA08840@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 26, 95 03:36:05 pm
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@freebsd.org
Precedence: bulk
> > While on that topic, didn't anyone notice that the PCI code is the
> > only code that actually uses the linker set length field? Everything
> > else looks for the NULL record at the end of the set. Does anyone
> > want to clean up the PCI code to do the same, and get rid of the
> > length field altogether?
>
> The layout of the structure is defined by GNU ld, so I would not want
> to touch it since other GNUware may depend on it for correct
> operation. See gnu/usr.bin/ld/ld.h, as I recall, near where it
> defines N_SETT etc.
I mean the PCI code change to not depend on it. 8-).
The difference between static and non-static allocation of a data
structure which is a list of non-NULL (caddr_t)'s terminated by a
NULL (caddr_t). Non-static being the GNU ld stuff.
I'd like to move away from depending on non-portable magic as
much as possible.
I didn't mean we should change the linker (far be it for us to have
any say on how that's coded). I think our current use is abuse of a
facility that was put there to support FORTRAN common blocks, actually.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Wed Jul 26 19:43:17 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA02545
for current-outgoing; Wed, 26 Jul 1995 19:43:17 -0700
Received: from who.cdrom.com (who.cdrom.com [192.216.222.3])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA02537
for <current@freebsd.org>; Wed, 26 Jul 1995 19:43:15 -0700
Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34])
by who.cdrom.com (8.6.11/8.6.11) with ESMTP id TAA06221
for <current@freebsd.org>; Wed, 26 Jul 1995 19:40:05 -0700
Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id IAA23362; Thu, 27 Jul 1995 08:34:29 +0600
From: "Serge A. Babkin" <babkin@hq.icb.chel.su>
Message-Id: <199507270234.IAA23362@hq.icb.chel.su>
Subject: Re: ep driver
To: fenner@parc.xerox.com (Bill Fenner)
Date: Thu, 27 Jul 1995 08:34:29 +0600 (GMT+0600)
Cc: rgrimes@gndrsh.aac.dev.com, current@freebsd.org
In-Reply-To: <95Jul26.102239pdt.177475@crevenia.parc.xerox.com> from "Bill Fenner" at Jul 26, 95 10:22:28 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 690
Sender: current-owner@freebsd.org
Precedence: bulk
>
> In message <199507260832.OAA06959@hq.icb.chel.su> you write:
> >- has multicast support
>
> If nobody is going to figure out how to program the multicast filters,
> then this diff might as well be something like
>
> >! case SIOCADDMULTI:
> >! case SIOCDELMULTI:
> >! error=0;
> >! break;
>
> and you can save the overhead of calling epinit().
Agreed. But are you sure that we can drop the calls of ether_addmulti()
and ether_delmulti() too ? I think we can't because it does the mapping
between IP and Ethernet multicast addresses. Or doesn't ?
Serge Babkin
! (babkin@hq.icb.chel.su)
! Headquarter of Joint Stock Commercial Bank "Chelindbank"
! Chelyabinsk, Russia
From owner-freebsd-current Wed Jul 26 19:46:38 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA02753
for current-outgoing; Wed, 26 Jul 1995 19:46:38 -0700
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id TAA02742
for <current@freebsd.org>; Wed, 26 Jul 1995 19:46:36 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14686(5)>; Wed, 26 Jul 1995 19:45:48 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Wed, 26 Jul 1995 19:45:41 -0700
To: "Serge A. Babkin" <babkin@hq.icb.chel.su>
cc: fenner@parc.xerox.com (Bill Fenner), rgrimes@gndrsh.aac.dev.com,
current@freebsd.org
Subject: Re: ep driver
In-reply-to: Your message of "Wed, 26 Jul 95 19:34:29 PDT."
<199507270234.IAA23362@hq.icb.chel.su>
Date: Wed, 26 Jul 1995 19:45:38 PDT
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <95Jul26.194541pdt.177475@crevenia.parc.xerox.com>
Sender: current-owner@freebsd.org
Precedence: bulk
In message <199507270234.IAA23362@hq.icb.chel.su> you write:
>are you sure that we can drop the calls of ether_addmulti()
>and ether_delmulti() too ? I think we can't because it does the mapping
>between IP and Ethernet multicast addresses. Or doesn't ?
All that ether_*multi() do is maintain the list of ethernet group addresses
to set up the filter. Since the driver doesn't use the filter and the card
is just in promiscuous multicast mode, there is no point in maintaining the
lists.
Someone should probably put in a comment about needing to maintain the
lists if the driver ever does gain programmable multicast filters...
Bill
From owner-freebsd-current Wed Jul 26 21:07:12 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id VAA05014
for current-outgoing; Wed, 26 Jul 1995 21:07:12 -0700
Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id VAA05001
for <current@freebsd.org>; Wed, 26 Jul 1995 21:06:43 -0700
Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id KAA25440; Thu, 27 Jul 1995 10:07:39 +0600
From: "Serge A. Babkin" <babkin@hq.icb.chel.su>
Message-Id: <199507270407.KAA25440@hq.icb.chel.su>
Subject: Re: ep driver
To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman)
Date: Thu, 27 Jul 1995 10:07:39 +0600 (GMT+0600)
Cc: current@freebsd.org
In-Reply-To: <9507261406.AA08195@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 26, 95 10:06:57 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 13455
Sender: current-owner@freebsd.org
Precedence: bulk
>
> DO NOT COMMIT THIS PATCH!
>
> <<On Wed, 26 Jul 1995 14:32:37 +0600 (GMT+0600), "Serge A. Babkin" <babkin@hq.icb.chel.su> said:
>
> > ! DC_UNCONFIGURED, /* state */
> > --- 132,143 ----
> > ! DC_BUSY, /* network interfaces are always ``open'' */
>
> Serge, please fix your patch to correctly track the device state.
OK (and SIOCxMULTI is reduced too):
------------------------------ cut here ---------------------------------
*** if_ep.c.205 Thu Jul 27 09:12:42 1995
--- if_ep.c Thu Jul 27 10:04:46 1995
***************
*** 100,105 ****
--- 98,104 ----
#include <i386/isa/isa_device.h>
#include <i386/isa/icu.h>
#include <i386/isa/if_epreg.h>
+ #include <i386/isa/elink.h>
static int epprobe __P((struct isa_device *));
static int epattach __P((struct isa_device *));
***************
*** 117,122 ****
--- 116,122 ----
static int send_ID_sequence __P((int));
static int get_eeprom_data __P((int, int));
+ static struct ep_board *ep_look_for_board_at(struct isa_device *);
struct ep_softc ep_softc[NEP];
***************
*** 132,145 ****
};
static struct kern_devconf kdc_ep[NEP] = { {
! 0, 0, 0, /* filled in by dev_attach */
"ep", 0, { MDDT_ISA, 0, "net" },
isa_generic_externalize, 0, 0, ISA_EXTERNALLEN,
! &kdc_isa0, /* parent */
! 0, /* parentdata */
! DC_UNCONFIGURED, /* state */
"3Com 3C509 Ethernet adapter",
! DC_CLS_NETIF /* class */
} };
static inline void
--- 132,145 ----
};
static struct kern_devconf kdc_ep[NEP] = { {
! 0, 0, 0, /* filled in by dev_attach */
"ep", 0, { MDDT_ISA, 0, "net" },
isa_generic_externalize, 0, 0, ISA_EXTERNALLEN,
! &kdc_isa0, /* parent */
! 0, /* parentdata */
! DC_UNCONFIGURED, /* state */
"3Com 3C509 Ethernet adapter",
! DC_CLS_NETIF /* class */
} };
static inline void
***************
*** 154,164 ****
int ep_current_tag = EP_LAST_TAG + 1;
! struct {
! int epb_addr; /* address of this board */
! char epb_used; /* was this entry already used for configuring ? */
! }
! ep_board[EP_MAX_BOARDS + 1];
static int
eeprom_rdy(is)
--- 154,160 ----
int ep_current_tag = EP_LAST_TAG + 1;
! struct ep_board ep_board[EP_MAX_BOARDS + 1];
static int
eeprom_rdy(is)
***************
*** 174,184 ****
return (1);
}
! static int
ep_look_for_board_at(is)
struct isa_device *is;
{
! int data, i, j, io_base, id_port = EP_ID_PORT;
int nisa = 0, neisa = 0;
if (ep_current_tag == (EP_LAST_TAG + 1)) {
--- 170,180 ----
return (1);
}
! static struct ep_board *
ep_look_for_board_at(is)
struct isa_device *is;
{
! int data, i, j, io_base, id_port = ELINK_ID_PORT;
int nisa = 0, neisa = 0;
if (ep_current_tag == (EP_LAST_TAG + 1)) {
***************
*** 203,232 ****
* Once activated, all the registers are mapped in the range
* x000 - x00F, where x is the slot number.
*/
ep_board[neisa].epb_used = 0;
ep_board[neisa++].epb_addr = j * EP_EISA_START;
}
ep_current_tag--;
/* Look for the ISA boards. Init and leave them actived */
outb(id_port, 0xc0); /* Global reset */
DELAY(10000);
for (i = 0; i < EP_MAX_BOARDS; i++) {
outb(id_port, 0);
outb(id_port, 0);
send_ID_sequence(id_port);
data = get_eeprom_data(id_port, EEPROM_MFG_ID);
if (data != MFG_ID)
break;
/* resolve contention using the Ethernet address */
for (j = 0; j < 3; j++)
! data = get_eeprom_data(id_port, j);
ep_board[neisa+nisa].epb_used = 0;
ep_board[neisa+nisa++].epb_addr =
! (get_eeprom_data(id_port, EEPROM_ADDR_CFG) & 0x1f) * 0x10 + 0x200;
outb(id_port, ep_current_tag); /* tags board */
outb(id_port, ACTIVATE_ADAPTER_TO_CONFIG);
ep_current_tag--;
--- 199,260 ----
* Once activated, all the registers are mapped in the range
* x000 - x00F, where x is the slot number.
*/
+ ep_board[neisa].epb_isa = 0;
ep_board[neisa].epb_used = 0;
ep_board[neisa++].epb_addr = j * EP_EISA_START;
}
ep_current_tag--;
/* Look for the ISA boards. Init and leave them actived */
+ outb(id_port, 0);
+ outb(id_port, 0);
+
+ #if 0
+ send_ID_sequence(id_port);
+ #else
+ elink_idseq(0xCF);
+ #endif
+
+ #if 0
outb(id_port, 0xc0); /* Global reset */
+ #else
+ elink_reset();
+ #endif
DELAY(10000);
for (i = 0; i < EP_MAX_BOARDS; i++) {
outb(id_port, 0);
outb(id_port, 0);
+ #if 0
send_ID_sequence(id_port);
+ #else
+ elink_idseq(0xCF);
+ #endif
data = get_eeprom_data(id_port, EEPROM_MFG_ID);
if (data != MFG_ID)
break;
/* resolve contention using the Ethernet address */
+
for (j = 0; j < 3; j++)
! get_eeprom_data(id_port, j);
!
! /* and save this address for later use */
!
! for (j = 0; j < 3; j++)
! ep_board[neisa+nisa].eth_addr[j] = get_eeprom_data(id_port, j);
!
! ep_board[neisa+nisa].res_cfg =
! get_eeprom_data(id_port, EEPROM_RESOURCE_CFG);
+ ep_board[neisa+nisa].prod_id =
+ get_eeprom_data(id_port, EEPROM_PROD_ID);
+
+ ep_board[neisa].epb_isa = 1;
ep_board[neisa+nisa].epb_used = 0;
ep_board[neisa+nisa++].epb_addr =
! (get_eeprom_data(id_port, EEPROM_ADDR_CFG) & 0x1f) * 0x10 + 0x200;
!
outb(id_port, ep_current_tag); /* tags board */
outb(id_port, ACTIVATE_ADAPTER_TO_CONFIG);
ep_current_tag--;
***************
*** 266,283 ****
IS_BASE=ep_board[i].epb_addr;
ep_board[i].epb_used=1;
! return 1;
} else {
for (i=0; ep_board[i].epb_addr && ep_board[i].epb_addr != IS_BASE; i++);
! if( ep_board[i].epb_used || ep_board[i].epb_addr != IS_BASE)
return 0;
if (inw(IS_BASE + EP_W0_EEPROM_COMMAND) & EEPROM_TST_MODE)
printf("ep%d: 3c5x9 at 0x%x in test mode. Erase pencil mark!\n",
is->id_unit, IS_BASE);
ep_board[i].epb_used=1;
! return 1;
}
}
--- 294,313 ----
IS_BASE=ep_board[i].epb_addr;
ep_board[i].epb_used=1;
!
! return &ep_board[i];
} else {
for (i=0; ep_board[i].epb_addr && ep_board[i].epb_addr != IS_BASE; i++);
! if( ep_board[i].epb_used || ep_board[i].epb_addr != IS_BASE)
return 0;
if (inw(IS_BASE + EP_W0_EEPROM_COMMAND) & EEPROM_TST_MODE)
printf("ep%d: 3c5x9 at 0x%x in test mode. Erase pencil mark!\n",
is->id_unit, IS_BASE);
ep_board[i].epb_used=1;
!
! return &ep_board[i];
}
}
***************
*** 308,327 ****
ep_registerdev(is);
! if (!ep_look_for_board_at(is))
return (0);
/*
* The iobase was found and MFG_ID was 0x6d50. PROD_ID should be
* 0x9[0-f]50
*/
GO_WINDOW(0);
! k = get_e(is, EEPROM_PROD_ID);
if ((k & 0xf0ff) != (PROD_ID & 0xf0ff)) {
printf("epprobe: ignoring model %04x\n", k);
return (0);
}
! k = get_e(is, EEPROM_RESOURCE_CFG);
k >>= 12;
/* Now we have two cases again:
--- 338,358 ----
ep_registerdev(is);
! if(( sc->epb=ep_look_for_board_at(is) )==0)
return (0);
/*
* The iobase was found and MFG_ID was 0x6d50. PROD_ID should be
* 0x9[0-f]50
*/
GO_WINDOW(0);
! k = sc->epb->epb_isa ? sc->epb->prod_id : get_e(is, EEPROM_PROD_ID);
if ((k & 0xf0ff) != (PROD_ID & 0xf0ff)) {
printf("epprobe: ignoring model %04x\n", k);
return (0);
}
! k = sc->epb->epb_isa ? sc->epb->res_cfg : get_e(is, EEPROM_RESOURCE_CFG);
!
k >>= 12;
/* Now we have two cases again:
***************
*** 396,402 ****
p = (u_short *) & sc->arpcom.ac_enaddr;
for (i = 0; i < 3; i++) {
GO_WINDOW(0);
! p[i] = htons(get_e(is, i));
GO_WINDOW(2);
outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i]));
}
--- 427,433 ----
p = (u_short *) & sc->arpcom.ac_enaddr;
for (i = 0; i < 3; i++) {
GO_WINDOW(0);
! p[i] = htons( sc->epb->epb_isa ? sc->epb->eth_addr[i] : get_e(is, i) );
GO_WINDOW(2);
outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i]));
}
***************
*** 423,429 ****
ifp->if_unit = is->id_unit;
ifp->if_name = "ep";
ifp->if_mtu = ETHERMTU;
! ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_NOTRAILERS;
ifp->if_init = epinit;
ifp->if_output = ether_output;
ifp->if_start = epstart;
--- 454,461 ----
ifp->if_unit = is->id_unit;
ifp->if_name = "ep";
ifp->if_mtu = ETHERMTU;
! ifp->if_flags = IFF_BROADCAST | IFF_MULTICAST |
! IFF_SIMPLEX | IFF_NOTRAILERS;
ifp->if_init = epinit;
ifp->if_output = ether_output;
ifp->if_start = epstart;
***************
*** 432,438 ****
ifp->if_timer=1;
if_attach(ifp);
! kdc_ep[is->id_unit].kdc_state = DC_BUSY;
/*
* Fill the hardware address into ifa_addr if we find an AF_LINK entry.
--- 464,472 ----
ifp->if_timer=1;
if_attach(ifp);
!
! /* device attach does transition from UNCONFIGURED to IDLE state */
! kdc_ep[is->id_unit].kdc_state=DC_IDLE;
/*
* Fill the hardware address into ifa_addr if we find an AF_LINK entry.
***************
*** 475,481 ****
#endif
ep_fset(F_RX_FIRST);
sc->top = sc->mcur = 0;
!
#if NBPFILTER > 0
bpfattach(&sc->bpf, ifp, DLT_EN10MB, sizeof(struct ether_header));
#endif
--- 509,515 ----
#endif
ep_fset(F_RX_FIRST);
sc->top = sc->mcur = 0;
!
#if NBPFILTER > 0
bpfattach(&sc->bpf, ifp, DLT_EN10MB, sizeof(struct ether_header));
#endif
***************
*** 536,547 ****
outw(BASE + EP_COMMAND, SET_INTR_MASK | S_5_INTS);
! if(ifp->if_flags & IFF_PROMISC)
! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL |
! FIL_GROUP | FIL_BRDCST | FIL_ALL);
! else
! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL |
! FIL_GROUP | FIL_BRDCST);
/*
* S.B.
--- 570,581 ----
outw(BASE + EP_COMMAND, SET_INTR_MASK | S_5_INTS);
! if(ifp->if_flags & IFF_PROMISC)
! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL |
! FIL_GROUP | FIL_BRDCST | FIL_ALL);
! else
! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL |
! FIL_GROUP | FIL_BRDCST);
/*
* S.B.
***************
*** 814,820 ****
sc->rx_no_first, sc->rx_no_mbuf, sc->rx_bpf_disc, sc->rx_overrunf,
sc->rx_overrunl, sc->tx_underrun);
#else
! printf("ep%d: Status: %x\n", unit, status);
#endif
epinit(unit);
splx(x);
--- 848,854 ----
sc->rx_no_first, sc->rx_no_mbuf, sc->rx_bpf_disc, sc->rx_overrunf,
sc->rx_overrunl, sc->tx_underrun);
#else
! printf("ep%d: Status: %x (input buffer overflow)\n", unit, status);
#endif
epinit(unit);
splx(x);
***************
*** 1132,1137 ****
--- 1166,1175 ----
switch (cmd) {
case SIOCSIFADDR:
ifp->if_flags |= IFF_UP;
+
+ /* netifs are BUSY when UP */
+ kdc_ep[ifp->if_unit].kdc_state=DC_BUSY;
+
switch (ifa->ifa_addr->sa_family) {
#ifdef INET
case AF_INET:
***************
*** 1163,1168 ****
--- 1201,1211 ----
}
break;
case SIOCSIFFLAGS:
+ /* UP controls BUSY/IDLE */
+ kdc_ep[ifp->if_unit].kdc_state= ( (ifp->if_flags & IFF_UP)
+ ? DC_BUSY
+ : DC_IDLE );
+
if ((ifp->if_flags & IFF_UP) == 0 && ifp->if_flags & IFF_RUNNING) {
ifp->if_flags &= ~IFF_RUNNING;
epstop(ifp->if_unit);
***************
*** 1175,1180 ****
--- 1218,1224 ----
}
/* NOTREACHED */
+ #if 0
if (ifp->if_flags & IFF_UP && (ifp->if_flags & IFF_RUNNING) == 0)
epinit(ifp->if_unit);
***************
*** 1187,1192 ****
--- 1231,1237 ----
ep_frst(F_PROMISC);
epinit(ifp->if_unit);
}
+ #endif
break;
#ifdef notdef
***************
*** 1205,1212 ****
} else {
ifp->if_mtu = ifr->ifr_mtu;
}
! break;
!
default:
error = EINVAL;
}
--- 1250,1264 ----
} else {
ifp->if_mtu = ifr->ifr_mtu;
}
! break;
! case SIOCADDMULTI:
! case SIOCDELMULTI:
! /* Now this driver has no support for programmable
! * multicast filters. If some day it will gain this
! * support this part of code must be extended.
! */
! error=0;
! break;
default:
error = EINVAL;
}
*** if_epreg.h.205 Tue Jul 18 09:29:43 1995
--- if_epreg.h Wed Jul 26 14:19:14 1995
***************
*** 71,76 ****
--- 70,77 ----
#define F_ACCESS_32_BITS 0x100
+ struct ep_board *epb;
+
#ifdef EP_LOCAL_STATS
short tx_underrun;
short rx_no_first;
***************
*** 80,85 ****
--- 81,97 ----
short rx_overrunl;
#endif
};
+
+ struct ep_board {
+ int epb_addr; /* address of this board */
+ char epb_used; /* was this entry already used for configuring ? */
+ /* data from EEPROM for later use */
+ char epb_isa; /* flag: this is an ISA card */
+ u_short eth_addr[3]; /* Ethernet address */
+ u_short prod_id; /* product ID */
+ u_short res_cfg; /* resource configuration */
+ };
+
/*
* Some global constants
------------------------------ cut here ---------------------------------
Serge Babkin
! (babkin@hq.icb.chel.su)
! Headquarter of Joint Stock Commercial Bank "Chelindbank"
! Chelyabinsk, Russia
From owner-freebsd-current Thu Jul 27 03:07:54 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id DAA16935
for current-outgoing; Thu, 27 Jul 1995 03:07:54 -0700
Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id DAA16929
for <current@freebsd.org>; Thu, 27 Jul 1995 03:07:50 -0700
Received: by FileServ1.MI.Uni-Koeln.DE id AA12119
(5.67b/IDA-1.5 for current@freebsd.org); Thu, 27 Jul 1995 12:06:55 +0200
Message-Id: <199507271006.AA12119@FileServ1.MI.Uni-Koeln.DE>
From: esser@zpr.uni-koeln.de (Stefan Esser)
Date: Thu, 27 Jul 1995 12:06:55 +0200
In-Reply-To: terry@cs.weber.edu (Terry Lambert)
"Re: ls_length in struct linker_set" (Jul 26, 14:41)
X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95)
To: terry@cs.weber.edu (Terry Lambert)
Subject: Re: ls_length in struct linker_set
Cc: current@freebsd.org
Sender: current-owner@freebsd.org
Precedence: bulk
I'll change the code to use a value of NULL as the end marker.
(Though I've got to admit, that I don't understand, why that is
better than using the length field. Is there something special
with GNU ld, and the length field shouldn't be relied on ???)
Regards, STefan
On Jul 26, 14:41, Terry Lambert wrote:
} Subject: Re: ls_length in struct linker_set
} > > While on that topic, didn't anyone notice that the PCI code is the
} > > only code that actually uses the linker set length field? Everything
} > > else looks for the NULL record at the end of the set. Does anyone
} > > want to clean up the PCI code to do the same, and get rid of the
} > > length field altogether?
} >
} > The layout of the structure is defined by GNU ld, so I would not want
} > to touch it since other GNUware may depend on it for correct
} > operation. See gnu/usr.bin/ld/ld.h, as I recall, near where it
} > defines N_SETT etc.
}
} I mean the PCI code change to not depend on it. 8-).
}
} The difference between static and non-static allocation of a data
} structure which is a list of non-NULL (caddr_t)'s terminated by a
} NULL (caddr_t). Non-static being the GNU ld stuff.
}
} I'd like to move away from depending on non-portable magic as
} much as possible.
}
} I didn't mean we should change the linker (far be it for us to have
} any say on how that's coded). I think our current use is abuse of a
} facility that was put there to support FORTRAN common blocks, actually.
--
Stefan Esser Internet: <se@ZPR.Uni-Koeln.DE>
Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021
Universitaet zu Koeln FAX: +49 221 4705160
Weyertal 80
50931 Koeln
From owner-freebsd-current Thu Jul 27 03:22:58 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id DAA17474
for current-outgoing; Thu, 27 Jul 1995 03:22:58 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id DAA17463
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 03:22:51 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA19339; Thu, 27 Jul 1995 12:22:34 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id MAA01843; Thu, 27 Jul 1995 12:22:28 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA18256; Thu, 27 Jul 1995 08:09:38 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507270609.IAA18256@uriah.heep.sax.de>
Subject: Re: NFS Probs
To: dsherwin@dracos.teton.com (Dan Sherwin)
Date: Thu, 27 Jul 1995 08:09:38 +0200 (MET DST)
Cc: freebsd-current@freebsd.org
In-Reply-To: <199507260524.WAA00419@dracos.teton.com> from "Dan Sherwin" at Jul 25, 95 10:24:35 pm
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
Content-Length: 476
Sender: current-owner@freebsd.org
Precedence: bulk
As Dan Sherwin wrote:
>
> On one system's exports file I have:
>
> /usr -maproot=root <host>:root
>
> Whenever I try to mount it, I get /usr: Permission Denied.
> What am I doing wrong?
Reading the exports(5) man page. :)
The trailing ``:root'' is bogus (and i don't even understand what's
your intention with it). Remove 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 Thu Jul 27 06:22:01 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id GAA20945
for current-outgoing; Thu, 27 Jul 1995 06:22:01 -0700
Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id GAA20939
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 06:21:59 -0700
Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA09949; Thu, 27 Jul 1995 09:21:56 -0400
Date: Thu, 27 Jul 1995 09:21:56 -0400
From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
Message-Id: <9507271321.AA09949@halloran-eldar.lcs.mit.edu>
To: terry@cs.weber.edu (Terry Lambert)
Cc: freebsd-current@freebsd.org
Subject: Re: ls_length in struct linker_set
In-Reply-To: <9507262041.AA23200@cs.weber.edu>
References: <9507261936.AA08840@halloran-eldar.lcs.mit.edu>
<9507262041.AA23200@cs.weber.edu>
Sender: current-owner@freebsd.org
Precedence: bulk
<<On Wed, 26 Jul 95 14:41:36 MDT, terry@cs.weber.edu (Terry Lambert) said:
> I didn't mean we should change the linker (far be it for us to have
> any say on how that's coded). I think our current use is abuse of a
> facility that was put there to support FORTRAN common blocks, actually.
Sorry, you're wrong. It's a facility that was put there to support
C++ global constructors and destructors, actually, and then extended
because it turned out to be a generally useful thing. We Will Not Go
Back To The Old Way(tm).
-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 Thu Jul 27 07:22:37 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id HAA22686
for current-outgoing; Thu, 27 Jul 1995 07:22:37 -0700
Received: from ns1.win.net (ns1.win.net [204.215.209.3])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id HAA22680
for <current@freebsd.org>; Thu, 27 Jul 1995 07:22:34 -0700
Received: (from bugs@localhost) by ns1.win.net (8.6.11/8.6.9) id KAA09846 for current@freebsd.org; Thu, 27 Jul 1995 10:31:17 -0400
From: Mark Hittinger <bugs@ns1.win.net>
Message-Id: <199507271431.KAA09846@ns1.win.net>
Subject: 2.2 share/doc/10.exref
To: current@freebsd.org
Date: Thu, 27 Jul 1995 10:31:16 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 148
Sender: current-owner@freebsd.org
Precedence: bulk
Syntax error: end of file unexpected
looks like /usr/src/usr.bin/vi/USD.doc/exref/ex.summary is truncated?
Regards,
Mark Hittinger
bugs@win.net
From owner-freebsd-current Thu Jul 27 07:56:25 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id HAA23713
for current-outgoing; Thu, 27 Jul 1995 07:56:25 -0700
Received: from minnow.render.com (render.demon.co.uk [158.152.30.118])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id HAA23697
for <current@freebsd.org>; Thu, 27 Jul 1995 07:56:16 -0700
Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id PAA14829; Thu, 27 Jul 1995 15:08:44 +0100
Date: Thu, 27 Jul 1995 15:08:43 +0100 (BST)
From: Doug Rabson <dfr@render.com>
To: current@freebsd.org
Subject: diskless swapping
Message-ID: <Pine.BSF.3.91.950727150311.230Q-100000@minnow.render.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
I was just attempting to find out why an NFS diskless machine running
-current spontaneously reboots when it starts swapping. What appears to
happen is that on the first swap read, the machine just reboots. No
panics, no faults, nothing. The wierd part is that if I single step
through that swap read, it works fine.
Apart from that, it always seems to be using synchronous i/o. Is that
intended? Performance for NFS swapping will be horrible...
--
Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com
Phone: +44 171 251 4411
FAX: +44 171 251 0939
From owner-freebsd-current Thu Jul 27 10:32:42 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA29888
for current-outgoing; Thu, 27 Jul 1995 10:32:42 -0700
Received: from macs.mxim.com (macs.mxim.com [204.17.143.130])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id KAA29882
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 10:32:38 -0700
Received: (from michaele@localhost) by macs.mxim.com (8.6.11/8.6.9) id KAA04884; Thu, 27 Jul 1995 10:23:08 -0700
Date: Thu, 27 Jul 1995 10:23:08 -0700 (PDT)
From: Michael Enkelis <michaele@mxim.com>
To: freebsd-current@freebsd.org
Subject: question on 2.1-STABLE
Message-ID: <Pine.SUN.3.90a.950727100646.14804A-100000@macs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
I upgraded from 2.0R to 2.1-STABLE (used sup to get from -stable branch)
and now i am seeing two problems
#1 Hang on startup.
The message " probing for ISA " shows on startup, then the system hangs.
If i press any key, then i get a
"scprobe: keyboard won't accept RESET command"
and the system continues on correctly.
#2 System crash in pppd.
I use the kernel pppd driver to connect to my ISP, and I have had three
crash's with the new kernel (last 24 hours).
The message is "ppp0: no carrier".
This fills the screen, then the whole system locks up. The only way out
is to "hit the reset switch".
_ _ _ __ michaele@mxim.com
' ) ) ) / /) / ` / /) Michael Enkelis
/ / / o _. /_ __. _ // /-- __ /_ _ // o _ (503) 641 - 3737 x2245
/ ' (_(_(__/ /_(_(_(<_(/_ (___, /) )_/ <_(<_(/_(_/_)_
From owner-freebsd-current Thu Jul 27 10:41:06 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA00403
for current-outgoing; Thu, 27 Jul 1995 10:41:06 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id KAA00396
for <current@freebsd.org>; Thu, 27 Jul 1995 10:41:04 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA02033; Thu, 27 Jul 95 11:33:19 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507271733.AA02033@cs.weber.edu>
Subject: Re: ls_length in struct linker_set
To: esser@zpr.uni-koeln.de (Stefan Esser)
Date: Thu, 27 Jul 95 11:33:19 MDT
Cc: current@freebsd.org
In-Reply-To: <199507271006.AA12119@FileServ1.MI.Uni-Koeln.DE> from "Stefan Esser" at Jul 27, 95 12:06:55 pm
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@freebsd.org
Precedence: bulk
> I'll change the code to use a value of NULL as the end marker.
>
> (Though I've got to admit, that I don't understand, why that is
> better than using the length field. Is there something special
> with GNU ld, and the length field shouldn't be relied on ???)
Because you might want to statically declare all sets rather than
having a linker make it for you.
Consider that most of the items that get "linker sets" have manifest
constant kernel options to get them in in the first place. Then
consider that you might have a non-self-hosted porting environment
that doesn't support linker sets. 8-).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Thu Jul 27 10:54:50 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA00922
for current-outgoing; Thu, 27 Jul 1995 10:54:50 -0700
Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id KAA00910
for <current@freebsd.org>; Thu, 27 Jul 1995 10:54:32 -0700
Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA10540; Thu, 27 Jul 1995 13:54:03 -0400
Date: Thu, 27 Jul 1995 13:54:03 -0400
From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
Message-Id: <9507271754.AA10540@halloran-eldar.lcs.mit.edu>
To: terry@cs.weber.edu (Terry Lambert)
Cc: esser@zpr.uni-koeln.de (Stefan Esser), current@freebsd.org
Subject: Re: ls_length in struct linker_set
In-Reply-To: <9507271733.AA02033@cs.weber.edu>
References: <199507271006.AA12119@FileServ1.MI.Uni-Koeln.DE>
<9507271733.AA02033@cs.weber.edu>
Sender: current-owner@freebsd.org
Precedence: bulk
<<On Thu, 27 Jul 95 11:33:19 MDT, terry@cs.weber.edu (Terry Lambert) said:
> Consider that most of the items that get "linker sets" have manifest
> constant kernel options to get them in in the first place.
The entire intent of my work in this area was to ELIMINATE the
manifest constants in the first place. It should be possible to add a
new static filesystem to a kernel simply by dropping in an object
module, with no recompilation necessary.
> Then consider that you might have a non-self-hosted porting environment
> that doesn't support linker sets. 8-).
Using whose linker? I considered this question for all of five
minutes, and concluded that it was not worth any more thought, since
anything that we do with these things can be trivially implemented
using C++ constructors, and any reasonable build environment will
provide some facility for making C++ work.
-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 Thu Jul 27 11:42:44 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id LAA02193
for current-outgoing; Thu, 27 Jul 1995 11:42:44 -0700
Received: from intercore.com (num1sun.intercore.com [205.198.76.1])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id LAA02181
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 11:42:39 -0700
Received: (robin@localhost) by intercore.com (8.6.9/8.6.4) id OAA21637 for freebsd-current@freebsd.org; Thu, 27 Jul 1995 14:38:48 -0400
From: Robin Cutshaw <robin@intercore.com>
Message-Id: <199507271838.OAA21637@intercore.com>
Subject: SMC Ultra interrupt problem
To: freebsd-current@freebsd.org
Date: Thu, 27 Jul 1995 14:38:47 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 337
Sender: current-owner@freebsd.org
Precedence: bulk
I just tried to boot/install from the 2.0.5-950622-SNAP distribution and
there is a problem with the interrupt probe for the SMC Ultra isa card.
I've got the interrupt set to 7 (no LPT1 there) and the driver reports 5.
I then reports spurrious int 7's.
The interrupt is at 7 because I ran out of the other interrupts.
Just FYI,
robin
From owner-freebsd-current Thu Jul 27 12:54:20 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id MAA04101
for current-outgoing; Thu, 27 Jul 1995 12:54:20 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id MAA04090
for <current@freebsd.org>; Thu, 27 Jul 1995 12:54:18 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA13760; Thu, 27 Jul 95 13:46:03 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507271946.AA13760@cs.weber.edu>
Subject: Re: ls_length in struct linker_set
To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman)
Date: Thu, 27 Jul 95 13:46:03 MDT
Cc: esser@zpr.uni-koeln.de, current@freebsd.org
In-Reply-To: <9507271754.AA10540@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 27, 95 01:54:03 pm
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@freebsd.org
Precedence: bulk
> > Consider that most of the items that get "linker sets" have manifest
> > constant kernel options to get them in in the first place.
>
> The entire intent of my work in this area was to ELIMINATE the
> manifest constants in the first place. It should be possible to add a
> new static filesystem to a kernel simply by dropping in an object
> module, with no recompilation necessary.
Then you need to fix i386/i386/autoconf.c; I've made a healthy
start in this direction.
> > Then consider that you might have a non-self-hosted porting environment
> > that doesn't support linker sets. 8-).
>
> Using whose linker? I considered this question for all of five
> minutes, and concluded that it was not worth any more thought, since
> anything that we do with these things can be trivially implemented
> using C++ constructors, and any reasonable build environment will
> provide some facility for making C++ work.
IBM's AIX linker on the Motorolla Ultra PPC 604.
And without C++, a linker that supports C++ mechanisms is relatively
useless (unless you happen to know the magic incantations for it).
Or the DEC OSF/1 linker on the Alpha 21066 box.
Because even with a GNU build environment, the GNU linker fails to
operate correctly.
It's a porting issue.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Thu Jul 27 13:53:48 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id NAA06011
for current-outgoing; Thu, 27 Jul 1995 13:53:48 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id NAA06002
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 13:53:45 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id NAA02217; Thu, 27 Jul 1995 13:52:19 -0700
To: Michael Enkelis <michaele@mxim.com>
cc: freebsd-current@freebsd.org
Subject: Re: question on 2.1-STABLE
In-reply-to: Your message of "Thu, 27 Jul 1995 10:23:08 PDT."
<Pine.SUN.3.90a.950727100646.14804A-100000@macs>
Date: Thu, 27 Jul 1995 13:52:19 -0700
Message-ID: <2215.806878339@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: current-owner@freebsd.org
Precedence: bulk
> #1 Hang on startup.
> ...
> #2 System crash in pppd.
> ...
Hmmm! I'm using pppd right now and don't see either of these problems!
Could you tell us a little bit more about your configuration?
Jordan
From owner-freebsd-current Thu Jul 27 14:49:42 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id OAA08225
for current-outgoing; Thu, 27 Jul 1995 14:49:42 -0700
Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id OAA08189
for <current@freebsd.org>; Thu, 27 Jul 1995 14:48:56 -0700
Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA10797; Thu, 27 Jul 1995 17:48:19 -0400
Date: Thu, 27 Jul 1995 17:48:19 -0400
From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
Message-Id: <9507272148.AA10797@halloran-eldar.lcs.mit.edu>
To: terry@cs.weber.edu (Terry Lambert)
Cc: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman),
esser@zpr.uni-koeln.de, current@freebsd.org
Subject: Re: ls_length in struct linker_set
In-Reply-To: <9507271946.AA13760@cs.weber.edu>
References: <9507271754.AA10540@halloran-eldar.lcs.mit.edu>
<9507271946.AA13760@cs.weber.edu>
Sender: current-owner@freebsd.org
Precedence: bulk
<<On Thu, 27 Jul 95 13:46:03 MDT, terry@cs.weber.edu (Terry Lambert) said:
>> Using whose linker? I considered this question for all of five
>> minutes, and concluded that it was not worth any more thought, since
>> anything that we do with these things can be trivially implemented
>> using C++ constructors, and any reasonable build environment will
>> provide some facility for making C++ work.
> IBM's AIX linker on the Motorolla Ultra PPC 604.
> And without C++, a linker that supports C++ mechanisms is relatively
> useless (unless you happen to know the magic incantations for it).
Think `collect2' and then answer again.
-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 Thu Jul 27 15:06:13 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id PAA09295
for current-outgoing; Thu, 27 Jul 1995 15:06:13 -0700
Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id PAA09258
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 15:05:58 -0700
Received: by haven.uniserve.com id <32622>; Thu, 27 Jul 1995 15:06:37 +0100
Date: Thu, 27 Jul 1995 15:06:25 -0700 (PDT)
From: Tom Samplonius <tom@uniserve.com>
To: Robin Cutshaw <robin@intercore.com>
cc: freebsd-current@freebsd.org
Subject: Re: SMC Ultra interrupt problem
In-Reply-To: <199507271838.OAA21637@intercore.com>
Message-ID: <Pine.BSF.3.91.950727150528.8820A-100000@haven.uniserve.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
On Thu, 27 Jul 1995, Robin Cutshaw wrote:
> I just tried to boot/install from the 2.0.5-950622-SNAP distribution and
> there is a problem with the interrupt probe for the SMC Ultra isa card.
> I've got the interrupt set to 7 (no LPT1 there) and the driver reports 5.
> I then reports spurrious int 7's.
>
> The interrupt is at 7 because I ran out of the other interrupts.
If you want to use your SMC at irq 7, you must tell FreeBSD too. Type
"-c" at the boot prompt and change the irq for the appropiated edX device.
Tom
From owner-freebsd-current Thu Jul 27 17:24:44 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id RAA15552
for current-outgoing; Thu, 27 Jul 1995 17:24:44 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id RAA15500
for <current@freebsd.org>; Thu, 27 Jul 1995 17:24:28 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA16543; Fri, 28 Jul 1995 02:23:47 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id CAA09380 for current@freebsd.org; Fri, 28 Jul 1995 02:23:46 +0200
Received: (from uucp@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) with UUCP id OAA19476 for current@freebsd.org; Thu, 27 Jul 1995 14:28:10 +0200
Received: by bonnie.tcd-dresden.de (8.6.8/8.6.6)
id OAA28170; Thu, 27 Jul 1995 14:08:07 +0200
From: j@bonnie.heep.sax.de (J Wunsch)
Message-Id: <199507271208.OAA28170@bonnie.tcd-dresden.de>
Subject: 2.0.5R not getting off the ground
To: current@freebsd.org
Date: Thu, 27 Jul 1995 14:08:07 +0200 (MET DST)
Reply-To: current@freebsd.org
X-Phone: +49-351-2012 669
Reply-To: joerg_wunsch@uriah.heep.sax.de
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: 2847
Sender: current-owner@freebsd.org
Precedence: bulk
Hi
I've got a spam^H^H^H^Hexperimental box, a two-year old Data General
PC. It's been returned from a customer from a leasing deal, so i
thought its best use here would be to serve as an experimental box for
FreeBSD 2.0.5 (while our main server is still running 1.1.5.1).
The BIOS announces the CPU as a 486SX, even though FreeBSD would find
npx0. The box comes with 4 MB RAM on-board (and i don't have some
spare SIMMs to add memory), as well as an on-board VGA and AHA-1520.
Any attempts to install 2.0.5R on it jam right after starting
sysinstall. VT1 is displaying a rock solid cursor block in the
lower left corner, VT2 containst just
DEBUG: ioctl(3, TIOCCONS, NULL) = 0 (success)
VT2 is accepting keystrokes, but the whole box is totally stuck.
Booting with -c -v -h (nice to get it to a serial console this way,
but sysinstall is unwilling to do use it, and switches back to the sc0
driver). After a long time, a message
sd0(aic0:0:0): Timed out
would appear on VT2, but that's just all.
Here's the boot stuff (minus the ``foo0: disabled, not probed.''
messages):
Booting the kernel
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 2.0.5-RELEASE #0: Sat Jun 10 10:28:28 1995
jkh@westhill.cdrom.com:/usr/src/sys/compile/BOOTMFS
CPU: i486DX (486-class CPU)
... (UserConfig output deleted)
real memory = 4194304 (1024 pages)
avail memory = 1818624 (444 pages)
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
ed1 at 0x300-0x30f irq 5 maddr 0xc8000 msize 8192 on isa
ed1: address 02:60:8c:43:3c:dd, type 3c503 (8 bit)
sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16450
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16450
lpt0 at 0x3bc-0x3c3 irq 7 on isa
lpt0: Interrupt-driven port
lp0: TCP/IP capable interface
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: NEC 765
fd0: 1.44MB 3.5in
fd1: 1.2MB 5.25in
aic0 at 0x340-0x35f irq 11 on isa
aic0 waiting for scsi devices to settle
(aic0:0:0): "FUJITSU M2623S7512 GP DG02" type 0 fixed SCSI 1
sd0(aic0:0:0): Direct-Access 323MB (663476 512 byte sectors)
sd0(aic0:0:0): with 1780 cyls, 7 heads, and an average 53 sectors/track
npx0 on motherboard
npx0: INT 16 interface
rootfs is 1075 Kbyte compiled in MFS
BIOS Geometries:
0:01423f20 322 cyl, 63 heads, 32 sects
0 accounted for
Does anybody have any clues?
Well, one final datapoint: disabling aic0 gets me to the sysinstall
menu. But how the hell install it now? (I've already zero'ed out the
MBR to fake a fresh disk. I've also double-cheked for address
conflicts.)
--
cheers, J"org private: 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 Jul 27 19:33:01 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA20749
for current-outgoing; Thu, 27 Jul 1995 19:33:01 -0700
Received: from intercore.com (num1sun.intercore.com [205.198.76.1])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA20740
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 19:32:58 -0700
Received: (robin@localhost) by intercore.com (8.6.9/8.6.4) id WAA00588; Thu, 27 Jul 1995 22:28:47 -0400
From: Robin Cutshaw <robin@intercore.com>
Message-Id: <199507280228.WAA00588@intercore.com>
Subject: Re: SMC Ultra interrupt problem
To: tom@uniserve.com (Tom Samplonius)
Date: Thu, 27 Jul 1995 22:28:46 -0400 (EDT)
Cc: freebsd-current@freebsd.org
In-Reply-To: <Pine.BSF.3.91.950727150528.8820A-100000@haven.uniserve.com> from "Tom Samplonius" at Jul 27, 95 03:06:25 pm
X-Mailer: ELM [version 2.4 PL21]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 664
Sender: current-owner@freebsd.org
Precedence: bulk
> On Thu, 27 Jul 1995, Robin Cutshaw wrote:
>
> > I just tried to boot/install from the 2.0.5-950622-SNAP distribution and
> > there is a problem with the interrupt probe for the SMC Ultra isa card.
> > I've got the interrupt set to 7 (no LPT1 there) and the driver reports 5.
> > I then reports spurrious int 7's.
> >
> > The interrupt is at 7 because I ran out of the other interrupts.
>
> If you want to use your SMC at irq 7, you must tell FreeBSD too. Type
> "-c" at the boot prompt and change the irq for the appropiated edX device.
>
> Tom
>
But why would it use irq 5? This seems like a bug to me.
FWIW, linux used irq 7 with no mods...
robin
From owner-freebsd-current Thu Jul 27 19:40:46 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA21017
for current-outgoing; Thu, 27 Jul 1995 19:40:46 -0700
Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA21010
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 19:40:34 -0700
Received: by haven.uniserve.com id <32785>; Thu, 27 Jul 1995 19:41:44 +0100
Date: Thu, 27 Jul 1995 19:41:35 -0700 (PDT)
From: Tom Samplonius <tom@uniserve.com>
To: Robin Cutshaw <robin@intercore.com>
cc: freebsd-current@freebsd.org
Subject: Re: SMC Ultra interrupt problem
In-Reply-To: <199507280228.WAA00588@intercore.com>
Message-ID: <Pine.BSF.3.91.950727193513.14297F-100000@haven.uniserve.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: current-owner@freebsd.org
Precedence: bulk
On Thu, 27 Jul 1995, Robin Cutshaw wrote:
> But why would it use irq 5? This seems like a bug to me.
It has to use something. Since you haven't told it otherwise, it just
uses the default of irq 5.
Tom
From owner-freebsd-current Thu Jul 27 19:45:31 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA21228
for current-outgoing; Thu, 27 Jul 1995 19:45:31 -0700
Received: from intercore.com (num1sun.intercore.com [205.198.76.1])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA21222
for <freebsd-current@freebsd.org>; Thu, 27 Jul 1995 19:45:28 -0700
Received: (robin@localhost) by intercore.com (8.6.9/8.6.4) id WAA00685; Thu, 27 Jul 1995 22:41:19 -0400
From: Robin Cutshaw <robin@intercore.com>
Message-Id: <199507280241.WAA00685@intercore.com>
Subject: Re: SMC Ultra interrupt problem
To: tom@uniserve.com (Tom Samplonius)
Date: Thu, 27 Jul 1995 22:41:17 -0400 (EDT)
Cc: freebsd-current@freebsd.org
In-Reply-To: <Pine.BSF.3.91.950727193513.14297F-100000@haven.uniserve.com> from "Tom Samplonius" at Jul 27, 95 07:41:35 pm
X-Mailer: ELM [version 2.4 PL21]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 449
Sender: current-owner@freebsd.org
Precedence: bulk
>
>
> On Thu, 27 Jul 1995, Robin Cutshaw wrote:
>
> > But why would it use irq 5? This seems like a bug to me.
>
> It has to use something. Since you haven't told it otherwise, it just
> uses the default of irq 5.
>
What's the point in probing the card for it's config info if your not
going to use it? This is one of my big problems with the commercial
unix o/s's, you have to tell them config info that they can get
themselves.
robin
From owner-freebsd-current Fri Jul 28 01:32:35 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id BAA00955
for current-outgoing; Fri, 28 Jul 1995 01:32:35 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id BAA00948
for <current@freefall.cdrom.com>; Fri, 28 Jul 1995 01:32:32 -0700
Received: (from jkh@localhost) by time.cdrom.com (8.6.11/8.6.9) id BAA06732 for current@freefall; Fri, 28 Jul 1995 01:20:37 -0700
Date: Fri, 28 Jul 1995 01:20:37 -0700
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Message-Id: <199507280820.BAA06732@time.cdrom.com>
To: current@freefall.cdrom.com
Subject: ijppp experiencing problems in -current?
Sender: current-owner@FreeBSD.org
Precedence: bulk
This is weird, but after almost a year of flawless operation, ijppp
has gone south on me. It stays up for about 10-15 minutes at a time,
max, and then sig 10's on me.. This started occurring only recently.
Have we done something recently in -current to kill it?
Anyone else seeing this?
Jordan
From owner-freebsd-current Fri Jul 28 05:39:05 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id FAA07773
for current-outgoing; Fri, 28 Jul 1995 05:39:05 -0700
Received: from merlin.nando.net (merlin.nando.net [152.52.2.2])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id FAA07767
for <current@freebsd.org>; Fri, 28 Jul 1995 05:39:04 -0700
Received: from nando.net.nando.net (parsifal.nando.net) by merlin.nando.net (4.1/davel-nando/dec93)
id AA03865; Fri, 28 Jul 95 08:38:47 EDT
Received: by nando.net.nando.net (4.1/SMI-4.1)
id AA04974; Fri, 28 Jul 95 08:38:38 EDT
From: kmitch@nando.net (kmitch)
Message-Id: <9507281238.AA04974@nando.net.nando.net>
Subject: Re: ijppp experiencing problems in -current?
To: current@freebsd.org
Date: Fri, 28 Jul 1995 08:38:37 -0400 (EDT)
In-Reply-To: <199507280820.BAA06732@time.cdrom.com> from "Jordan K. Hubbard" at Jul 28, 95 01:20:37 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 594
Sender: current-owner@freebsd.org
Precedence: bulk
>
> This is weird, but after almost a year of flawless operation, ijppp
> has gone south on me. It stays up for about 10-15 minutes at a time,
> max, and then sig 10's on me.. This started occurring only recently.
I've seen something similar, but I can't narrow it down enough to see if it is
my internet provider or ppp. What I am seeing is ppp will stay up fairly
reliable until I start a web browser (Netscape or Mosaic), and then the
connection dies. I am running a tree from around the 18th. I don't think
it sig 10s though when it does this, so this may be completely different.
From owner-freebsd-current Fri Jul 28 07:14:36 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id HAA10334
for current-outgoing; Fri, 28 Jul 1995 07:14:36 -0700
Received: from asstdc.scgt.oz.au (asstdc.scgt.oz.au [202.14.234.65])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id HAA10325
for <current@freebsd.org>; Fri, 28 Jul 1995 07:14:28 -0700
Received: (from imb@localhost)
by asstdc.scgt.oz.au (8.6.12/BSD4.4)
id AAA09923; Sat, 29 Jul 1995 00:12:56 +1000
From: michael butler <imb@scgt.oz.au>
Message-Id: <199507281412.AAA09923@asstdc.scgt.oz.au>
Subject: Re: ijppp experiencing problems in -current?
To: kmitch@nando.net (kmitch)
Date: Sat, 29 Jul 1995 00:12:55 +1000 (EST)
Cc: current@freebsd.org
In-Reply-To: <9507281238.AA04974@nando.net.nando.net> from "kmitch" at Jul 28, 95 08:38:37 am
X-Mailer: ELM [version 2.4 PL24beta]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1001
Sender: current-owner@freebsd.org
Precedence: bulk
kmitch@nando.net writes:
> > This is weird, but after almost a year of flawless operation, ijppp
> > has gone south on me. It stays up for about 10-15 minutes at a time,
> > max, and then sig 10's on me.. This started occurring only recently.
> I've seen something similar, but I can't narrow it down enough to see if it is
> my internet provider or ppp. What I am seeing is ppp will stay up fairly
> reliable until I start a web browser (Netscape or Mosaic), and then the
> connection dies. I am running a tree from around the 18th. I don't think
> it sig 10s though when it does this, so this may be completely different.
I noted this when running on a 14k4 link prior to replacing it with ISDN. If
the link was saturated, LQR echos were lost in sufficient quantity to cause
PPP to think the link was down. If LQR is disabled or denied, an excess of
missed LCP echos ends up causing the same thing. Things improved marginally
by dropping MTU to 576. I never noted any exceptions,
michael
From owner-freebsd-current Fri Jul 28 08:19:46 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id IAA12532
for current-outgoing; Fri, 28 Jul 1995 08:19:46 -0700
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id IAA12524
; Fri, 28 Jul 1995 08:19:43 -0700
Message-Id: <199507281519.IAA12524@freefall.cdrom.com>
X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
cc: current@freefall.cdrom.com
Subject: Re: ijppp experiencing problems in -current?
In-reply-to: Your message of "Fri, 28 Jul 95 01:20:37 PDT."
<199507280820.BAA06732@time.cdrom.com>
Date: Fri, 28 Jul 1995 08:19:43 -0700
From: "Justin T. Gibbs" <gibbs@freefall.cdrom.com>
Sender: current-owner@FreeBSD.org
Precedence: bulk
>This is weird, but after almost a year of flawless operation, ijppp
>has gone south on me. It stays up for about 10-15 minutes at a time,
>max, and then sig 10's on me.. This started occurring only recently.
>
>Have we done something recently in -current to kill it?
>
>Anyone else seeing this?
>
> Jordan
I got a tech support call from someone seeing the exact same thing under
2.0.5R, so it may not be a recent change to ijppp, but some other
configuration change on your system.
--
Justin T. Gibbs
===========================================
Software Developer - Walnut Creek CDROM
FreeBSD: Turning PCs into workstations
===========================================
From owner-freebsd-current Fri Jul 28 10:37:14 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id KAA20402
for current-outgoing; Fri, 28 Jul 1995 10:37:14 -0700
Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id KAA20386
for <current@FreeBSD.ORG>; Fri, 28 Jul 1995 10:37:03 -0700
Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.6) id TAA13104 for current@FreeBSD.ORG; Fri, 28 Jul 1995 19:39:10 +0200
From: John Hay <jhay@mikom.csir.co.za>
Message-Id: <199507281739.TAA13104@zibbi.mikom.csir.co.za>
Subject: Top panics system
To: current@FreeBSD.ORG (FreeBSD-current)
Date: Fri, 28 Jul 1995 19:39:09 +0200 (SAT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1479
Sender: current-owner@FreeBSD.ORG
Precedence: bulk
Hi,
I had top in one window and had a telnet in another window and when I exited
the telnet session my machine paniced. The telnet session had been going
for a long time (a day or so) and I did a few local compiles so I think most
of the shell from where I started telnet was swapped out.
The system is fairly current and the kernel is 3-4 days old. This is not the first time it has happened, but it doesn't happen very often.
It looks like fill_eproc is trying to access something invalid. Maybe the
info about the telnet that had just stopped?
The panic message is:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xf010c7fa
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 187 (top)
> interrupt mask =
> panic: page fault
> syncing disks... 5 5 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
The functions around the panic address is:
> f010c440 T _sysctl_rdstring
> f010c4a0 T _sysctl_struct
> f010c504 T _sysctl_rdstruct
> f010c54c T _sysctl_file
> f010c5f8 T _sysctl_doproc
> f010c7c4 T _fill_eproc
> f010c958 T _ogetkerninfo
> f010cc40 F kern_time.o
> f010cc40 T _gettimeofday
> f010cc88 T _settimeofday
> f010cdd0 T _adjtime
--
John Hay -- jhay@mikom.csir.co.za
From owner-freebsd-current Fri Jul 28 11:06:09 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id LAA22517
for current-outgoing; Fri, 28 Jul 1995 11:06:09 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id LAA22509
for <current@freebsd.org>; Fri, 28 Jul 1995 11:06:05 -0700
Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id LAA11503; Fri, 28 Jul 1995 11:05:24 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id LAA00278; Fri, 28 Jul 1995 11:06:44 -0700
Message-Id: <199507281806.LAA00278@corbin.Root.COM>
To: John Hay <jhay@mikom.csir.co.za>
cc: current@freebsd.org (FreeBSD-current)
Subject: Re: Top panics system
In-reply-to: Your message of "Sat, 28 Jul 95 19:39:09 +0200."
<199507281739.TAA13104@zibbi.mikom.csir.co.za>
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Fri, 28 Jul 1995 11:06:43 -0700
Sender: current-owner@freebsd.org
Precedence: bulk
>I had top in one window and had a telnet in another window and when I exited
>the telnet session my machine paniced. The telnet session had been going
>for a long time (a day or so) and I did a few local compiles so I think most
>of the shell from where I started telnet was swapped out.
>
>The system is fairly current and the kernel is 3-4 days old. This is not the
>first time it has happened, but it doesn't happen very often.
Thanks for the bug report. I just fixed the bug in 2.2-current and will be
bringing the change into 2.1-stable shortly.
-DG
From owner-freebsd-current Fri Jul 28 17:31:03 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id RAA16436
for current-outgoing; Fri, 28 Jul 1995 17:31:03 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id RAA16423
; Fri, 28 Jul 1995 17:30:53 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA27121; Sat, 29 Jul 1995 02:22:22 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id CAA19249; Sat, 29 Jul 1995 02:22:11 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id OAA23160; Fri, 28 Jul 1995 14:35:31 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507281235.OAA23160@uriah.heep.sax.de>
Subject: Update on my aic driver problems
To: freebsd-current@FreeBSD.org (FreeBSD-current users)
Date: Fri, 28 Jul 1995 14:35:30 +0200 (MET DST)
Cc: babb@FreeBSD.org
Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users)
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
Content-Length: 679
Sender: current-owner@FreeBSD.org
Precedence: bulk
Well, i've finally disassembled that box. :)
(Strange enough, the BIOS announces the CPU properly as a 486*DX*
now. :-)
The aic chip is actually an AIC 6260, and the `aic' driver isn't very
clear about this, but it looks like it would only support AIC 6360's. :-(
Does anybody know what's the difference, and if it would be allot of
work to hack it? By now, all i get is ``sd0(aic0:0:0) timed out''
when sysinstall tries to find the drive(s), even though the driver has
been properly probing the chip and announced the disk drive.
--
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 Jul 28 17:32:19 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id RAA16567
for current-outgoing; Fri, 28 Jul 1995 17:32:19 -0700
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id RAA16559
for <current@freefall.cdrom.com>; Fri, 28 Jul 1995 17:32:18 -0700
Message-Id: <199507290032.RAA16559@freefall.cdrom.com>
X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol
To: current@freefall.cdrom.com
Subject: GUS 3.4 and /dev/audio
Date: Fri, 28 Jul 1995 17:32:18 -0700
From: "Justin T. Gibbs" <gibbs@freefall.cdrom.com>
Sender: current-owner@FreeBSD.org
Precedence: bulk
Even with Jordan's commit of Voxware 30.5, I get garbage from sending
any .au files to /dev/audio. Anyone else seeing this? Xanim has no
problem playing Quicktime audio to my GUS, so its not totally broken.
__
Justin T. Gibbs
===========================================
Software Developer - Walnut Creek CDROM
FreeBSD: Turning PCs into workstations
===========================================
From owner-freebsd-current Fri Jul 28 19:57:01 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA19812
for current-outgoing; Fri, 28 Jul 1995 19:57:01 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id TAA19806
; Fri, 28 Jul 1995 19:56:57 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA01665; Fri, 28 Jul 95 20:49:54 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9507290249.AA01665@cs.weber.edu>
Subject: Re: Update on my aic driver problems
To: freebsd-current@FreeBSD.org
Date: Fri, 28 Jul 95 20:49:53 MDT
Cc: babb@FreeBSD.org
In-Reply-To: <199507281235.OAA23160@uriah.heep.sax.de> from "J Wunsch" at Jul 28, 95 02:35:30 pm
X-Mailer: ELM [version 2.4dev PL52]
Sender: current-owner@FreeBSD.org
Precedence: bulk
> The aic chip is actually an AIC 6260, and the `aic' driver isn't very
> clear about this, but it looks like it would only support AIC 6360's. :-(
The 6260 doesn't support scatter/gather, I believe.
> Does anybody know what's the difference, and if it would be allot of
> work to hack it? By now, all i get is ``sd0(aic0:0:0) timed out''
> when sysinstall tries to find the drive(s), even though the driver has
> been properly probing the chip and announced the disk drive.
I don't know how you'd hack it onto a chip that doesn't support it.
8-).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-current Sat Jul 29 01:40:42 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id BAA00824
for current-outgoing; Sat, 29 Jul 1995 01:40:42 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id BAA00753
for <freebsd-current@freefall.cdrom.com>; Sat, 29 Jul 1995 01:39:01 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA24386; Sat, 29 Jul 1995 18:36:36 +1000
Date: Sat, 29 Jul 1995 18:36:36 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507290836.SAA24386@godzilla.zeta.org.au>
To: freebsd-current@freefall.cdrom.com, kuku@gilberto.physik.rwth-aachen.de
Subject: Re: panic after fdformat/disklabel
Sender: current-owner@FreeBSD.org
Precedence: bulk
>fdformat /dev/rfd0a
><formatted floppy>
>disklabel -w -r fd0d floppy3
>(was not sure if the syntax was correct)
>*poof*
>Fatal trap 12: page fault while in kernel mode
The bug was in -current. It is now fixed.
Bruce
From owner-freebsd-current Sat Jul 29 04:01:53 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id EAA06994
for current-outgoing; Sat, 29 Jul 1995 04:01:53 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id EAA06977
for <current@freefall.cdrom.com>; Sat, 29 Jul 1995 04:01:50 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id DAA02036; Sat, 29 Jul 1995 03:59:13 -0700
Date: Sat, 29 Jul 1995 03:59:13 -0700
Message-Id: <199507291059.DAA02036@silvia.HIP.Berkeley.EDU>
To: jkh@time.cdrom.com
CC: current@freefall.cdrom.com
In-reply-to: <199507280820.BAA06732@time.cdrom.com> (jkh@time.cdrom.com)
Subject: Re: ijppp experiencing problems in -current?
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: current-owner@FreeBSD.org
Precedence: bulk
* This is weird, but after almost a year of flawless operation, ijppp
* has gone south on me. It stays up for about 10-15 minutes at a time,
* max, and then sig 10's on me.. This started occurring only recently.
*
* Have we done something recently in -current to kill it?
*
* Anyone else seeing this?
Yes. I noticed this right after some big changes went in to ppp (in
July 8). I had been using ijppp fine (for about three days ;) prior
to the make world that included that change. It started dying
frequently with sig 10's, although it wasn't as bad as "max 10-15
minutes".
I also did a measurement (time rcp bigfile.gz, ping somehost) and
found that slip is 20-30% better both in throughput and latency. So I
gave up on ijppp and haven't tried it since.
Satoshi
From owner-freebsd-current Sat Jul 29 08:47:48 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id IAA29074
for current-outgoing; Sat, 29 Jul 1995 08:47:48 -0700
Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id IAA29067
for <FreeBSD-current@FreeBSD.org>; Sat, 29 Jul 1995 08:47:44 -0700
Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id QAA06439 for FreeBSD-current@FreeBSD.org; Sat, 29 Jul 1995 16:47:33 +0100
From: Paul Richards <paul@netcraft.co.uk>
Message-Id: <199507291547.QAA06439@server.netcraft.co.uk>
Subject: Gnats
To: FreeBSD-current@FreeBSD.org (FreeBSD current mailing list)
Date: Sat, 29 Jul 1995 16:47:33 +0100 (BST)
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: 626
Sender: current-owner@FreeBSD.org
Precedence: bulk
Freefall's now running a beta release of gnats, if you experience
any problems send me some mail. I don't expect any problems with
the existing tools.
Also included in the new release is a client/server remote access
system so you will be able to query AND edit PR's from your
own machine. There are problems with these new tools so I'm not
making them available yet but I'm letting you now so you have
something to look forward to :-)
--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
From owner-freebsd-current Sat Jul 29 15:44:19 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id PAA01963
for current-outgoing; Sat, 29 Jul 1995 15:44:19 -0700
Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id PAA01939
for <current@FreeBSD.org>; Sat, 29 Jul 1995 15:44:16 -0700
Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id NAA18324 for <current@freebsd.org>; Sat, 29 Jul 1995 13:46:48 -0700
Received: from localhost.cs.tu-berlin.de ([130.149.1.128]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id WAA05929 for <current@freebsd.org>; Sat, 29 Jul 1995 22:36:43 +0200
Received: (from w@localhost) by localhost (8.6.9/8.6.9) id WAA01243; Sat, 29 Jul 1995 22:25:08 +0200
Date: Sat, 29 Jul 1995 22:25:08 +0200
From: Wolfram Schneider <w@cs.tu-berlin.de>
Message-Id: <199507292025.WAA01243@localhost>
To: current@FreeBSD.org
Subject: german words file
Reply-to: Wolfram Schneider <wosch@cs.tu-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: current-owner@FreeBSD.org
Precedence: bulk
What about a german words file (e.g /usr/share/dict/de_DE.ISO8859-1/words)?
The contents can be extract from various dictionaries.
Wolfram
From owner-freebsd-current Sat Jul 29 15:48:42 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id PAA02611
for current-outgoing; Sat, 29 Jul 1995 15:48:42 -0700
Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id PAA02604
for <current@FreeBSD.org>; Sat, 29 Jul 1995 15:48:40 -0700
Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id MAA18000 for <current@FreeBSD.ORG>; Sat, 29 Jul 1995 12:31:11 -0700
Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.6) id VAA07073 for current@FreeBSD.ORG; Sat, 29 Jul 1995 21:31:31 +0200
From: John Hay <jhay@mikom.csir.co.za>
Message-Id: <199507291931.VAA07073@zibbi.mikom.csir.co.za>
Subject: Problem with Makefile in src/share/doc/usd/10.exref
To: current@FreeBSD.org (FreeBSD-current)
Date: Sat, 29 Jul 1995 21:31:30 +0200 (SAT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 764
Sender: current-owner@FreeBSD.org
Precedence: bulk
Hi,
It seems as if there is a typo in the Makefile. It use ${GZIP} which is not
defined. I think it should be GZIPCMD which is defined in bsd.doc.mk
--
John Hay -- jhay@mikom.csir.co.za
*** src/share/doc/usd/10.exref/Makefile.org Wed Jul 26 18:31:43 1995
--- src/share/doc/usd/10.exref/Makefile Sat Jul 29 21:18:25 1995
***************
*** 19,25 ****
all: ${DFILE} ${SFILE}
${SFILE}: ex.summary
! (cd ${SRCDIR}; ${ROFF} ${.ALLSRC}) | ${GZIP} > ${.TARGET}
afterinstall:
${INSTALL} ${COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
--- 19,25 ----
all: ${DFILE} ${SFILE}
${SFILE}: ex.summary
! (cd ${SRCDIR}; ${ROFF} ${.ALLSRC}) | ${GZIPCMD} > ${.TARGET}
afterinstall:
${INSTALL} ${COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
From owner-freebsd-current Sat Jul 29 15:48:40 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id PAA02597
for current-outgoing; Sat, 29 Jul 1995 15:48:40 -0700
Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id PAA02591
for <current@FreeBSD.org>; Sat, 29 Jul 1995 15:48:39 -0700
Received: from crash.cts.com (crash.cts.com [192.188.72.17]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with SMTP id MAA18065 for <current@freebsd.org>; Sat, 29 Jul 1995 12:40:33 -0700
Received: from io.cts.com by crash.cts.com with smtp
(Smail3.1.29.1 #5) id m0scHk7-0000GoC; Sat, 29 Jul 95 12:40 PDT
Received: (from root@localhost) by io.cts.com (8.6.11/8.6.9) id MAA15177 for current@freebsd.org; Sat, 29 Jul 1995 12:40:13 -0700
From: Morgan Davis <root@io.cts.com>
Message-Id: <199507291940.MAA15177@io.cts.com>
Subject: Clunky telnet/rlogin performance
To: current@FreeBSD.org
Date: Sat, 29 Jul 1995 12:40:13 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 626
Sender: current-owner@FreeBSD.org
Precedence: bulk
Using either telnet or rlogin from FreeBSD 2.2-current to BSD/OS 2.0
results in extremely bursty I/O, with lags in typing echo of up to 10
seconds over a completely unused line:
FreeBSD -> [ISP] -> BSD/OS
It's like some kind of protocol compatibility problem, and it never gets
better.
If an intermediate system is used, e.g.:
FreeBSD -> [ISP] -> SCO Unix -> BSD/OS
performance is excellent. Take the intermediate site out and it's
back to sluggish response.
The FreeBSD machine is running on a 28.8 V.FC modem with PPP. The ISP
system is series of terminal servers connecting to the main network
machines with T1s.
From owner-freebsd-current Sat Jul 29 16:00:00 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id QAA03212
for current-outgoing; Sat, 29 Jul 1995 16:00:00 -0700
Received: from Root.COM ([198.145.90.1])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id PAA03206
for <current@freebsd.org>; Sat, 29 Jul 1995 15:59:59 -0700
Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id PAA13314; Sat, 29 Jul 1995 15:59:20 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id QAA00609; Sat, 29 Jul 1995 16:00:42 -0700
Message-Id: <199507292300.QAA00609@corbin.Root.COM>
To: Morgan Davis <root@io.cts.com>
cc: current@freebsd.org
Subject: Re: Clunky telnet/rlogin performance
In-reply-to: Your message of "Sat, 29 Jul 95 12:40:13 PDT."
<199507291940.MAA15177@io.cts.com>
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Sat, 29 Jul 1995 16:00:42 -0700
Sender: current-owner@freebsd.org
Precedence: bulk
>Using either telnet or rlogin from FreeBSD 2.2-current to BSD/OS 2.0
>results in extremely bursty I/O, with lags in typing echo of up to 10
>seconds over a completely unused line:
Try changing "tcp_extensions" to "NO" in /etc/sysconfig.
-DG
From owner-freebsd-current Sat Jul 29 19:19:33 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id TAA10162
for current-outgoing; Sat, 29 Jul 1995 19:19:33 -0700
Received: from asstdc.scgt.oz.au (asstdc.scgt.oz.au [202.14.234.65])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id TAA10156
for <current@freebsd.org>; Sat, 29 Jul 1995 19:19:27 -0700
Received: (from imb@localhost)
by asstdc.scgt.oz.au (8.6.12/BSD4.4)
id MAA02828 for current@freebsd.org; Sun, 30 Jul 1995 12:19:19 +1000
From: michael butler <imb@scgt.oz.au>
Message-Id: <199507300219.MAA02828@asstdc.scgt.oz.au>
Subject: 950726-SNAP installation problems - WD1007 ESDI
To: current@freebsd.org
Date: Sun, 30 Jul 1995 12:19:19 +1000 (EST)
X-Mailer: ELM [version 2.4 PL24beta]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2159
Sender: current-owner@freebsd.org
Precedence: bulk
This is a friend of mine (600+ miles south of here) trying to install the
current SNAP ..
Any ideas would be much appreciated .. the panic is a worry ..
============================================================
From: David Nugent <davidn@blaze.net.au>
Message-Id: <199507291939.FAA05569@server.blaze.net.au>
Subject: FreeBSD
Date: Sun, 30 Jul 1995 05:39:36 +1000 (EST)
Well, I tried an install and it's gotten even worse.
The install seems slicker now with the "Express" option, and I tried both
that an the usual installation. I get through making the partitions (the
drive etc. is correctly detected and so forth) get through disklabel ok,
then all of the other setup garbage. I get to Proceed, and go - partition
information is written correctly, and bad144 starts up. At that time the
kernel panics with the message "buffer already in use".
The system is a 386/20M (DX) with 6 meg of RAM, drive is a
Micropolos ESDI 1224 x 15 x 35 using a WD1007 controller.
Previous attempts to install FreeBSD 2.0 and 2.0.5 had been "successful",
although as i said, I was unable to boot from the drive after the
installation. Yes, my root partition *is* in a small partition at the start
of the drive, and I also tried using 'translated' geometries as well which
lowered the number if cylinders < 1024 (in case this confused the BIOS).
Same result in each case - installed fine, but booting not. I tried both the
'standard' MBR and 'boot manager', even attempted converting from one to the
other. If the boot manager is installed, it does indeed fire up, but
pressing F1 tickles the drive then prompts for the function key again (ie.
it can't seem to boot from that point).
MFM drives work on this motherboard, btw, and I've actually had it running
on that machine (albiet with hardly any disk space available and a less than
useful installation, which is the problem :-)).
Oh well, looks like I might have to opt for Linux after all. :( I'll see if
the latest Slackware release works on this drive. Here's hoping.
David
============================================================
Of course, I'd MUCH prefer that he be able to run FreeBSD ..
michael
From owner-freebsd-current Sat Jul 29 21:04:00 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id VAA14385
for current-outgoing; Sat, 29 Jul 1995 21:04:00 -0700
Received: from specgw.spec.co.jp (specgw.spec.co.jp [202.32.13.1])
by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id VAA14379
; Sat, 29 Jul 1995 21:03:56 -0700
Received: from tama3.spec.co.jp (tama3 [202.32.13.252]) by specgw.spec.co.jp (8.6.5/3.3Wb-SPEC) with SMTP id MAA25318; Sun, 30 Jul 1995 12:58:41 +0900
Message-Id: <9507300409.AA00110@tama3.spec.co.jp.spec.co.jp>
Date: Sun, 30 Jul 1995 13:09:04 +0900
From: Atsushi Murai <amurai@spec.co.jp>
To: gibbs@freefall.cdrom.com
Cc: jkh@time.cdrom.com, current@freefall.cdrom.com
Subject: Re: ijppp experiencing problems in -current?
In-Reply-To: <199507281519.IAA12524@freefall.cdrom.com>
X-Mailer: AL-Mail 0.94Beta
Sender: current-owner@FreeBSD.org
Precedence: bulk
"Justin T. Gibbs" <gibbs@freefall.cdrom.com> wrote:
:>This is weird, but after almost a year of flawless operation, ijppp
:>has gone south on me. It stays up for about 10-15 minutes at a time,
:>max, and then sig 10's on me.. This started occurring only recently.
:>
:>Have we done something recently in -current to kill it?
:>
:>Anyone else seeing this?
:>
:> Jordan
:
:I got a tech support call from someone seeing the exact same thing under
:2.0.5R, so it may not be a recent change to ijppp, but some other
:configuration change on your system.
Sorry I should've reply this issue immediatly but not my current jobs keep
me busy even weekend.... Well I am usually use iijppp between home and office
daily as user but never had a such symtom at this poin. Of course befor
committing(July 8) to freefall, it's done reliable testing a week...
Anyway whenever I get a time to do, I will try to investgate your issue.
(Hopely next weekend.)
:--
:Justin T. Gibbs
:===========================================
: Software Developer - Walnut Creek CDROM
: FreeBSD: Turning PCs into workstations
:===========================================
Atsushi.
--
Atsushi Murai E-Mail: amurai@spec.co.jp
SPEC Voice : +81-3-3833-5341
System Planning and Engineering Corp.
From owner-freebsd-current Sat Jul 29 21:33:30 1995
Return-Path: current-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.11/8.6.6) id VAA15622
for current-outgoing; Sat, 29 Jul 1995 21:33:30 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id VAA15609
for <freebsd-current@FreeBSD.org>; Sat, 29 Jul 1995 21:33:27 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA03735; Sun, 30 Jul 1995 06:32:51 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id GAA29674 for freebsd-current@FreeBSD.org; Sun, 30 Jul 1995 06:32:50 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id GAA00644 for freebsd-current@FreeBSD.org; Sun, 30 Jul 1995 06:29:19 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507300429.GAA00644@uriah.heep.sax.de>
Subject: Re: german words file
To: freebsd-current@FreeBSD.org (FreeBSD-current users)
Date: Sun, 30 Jul 1995 06:29:18 +0200 (MET DST)
Reply-To: current@FreeBSD.org
In-Reply-To: <199507292025.WAA01243@localhost> from "Wolfram Schneider" at Jul 29, 95 10:25:08 pm
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
Content-Length: 441
Sender: current-owner@FreeBSD.org
Precedence: bulk
As Wolfram Schneider wrote:
>
>
> What about a german words file (e.g /usr/share/dict/de_DE.ISO8859-1/words)?
> The contents can be extract from various dictionaries.
Without copyright problems?
I think the web files are only available since their copyright has
been expired after many years.
--
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. ;-)