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 ; 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: 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 ; 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: 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" 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 ; 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 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 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 ; 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" 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 ; 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 ; Sun, 23 Jul 1995 23:16:32 -0400 (EDT) Received: from unix19.andrew.cmu.edu via qmail ID ; 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: Date: Sun, 23 Jul 1995 23:16:29 -0400 (EDT) From: Tao Jiang 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 ; 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" 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: : /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 To: "Jordan K. Hubbard" cc: current@freefall.cdrom.com Subject: Re: Interesting NFS problem with -current In-Reply-To: <199507240605.XAA00457@throck.cdrom.com> Message-ID: 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: > > : /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 ; 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 To: Terry Lambert 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: 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 ; 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 ; 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 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" 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 ; 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 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" Reply-To: cg@fimp01.fim.uni-linz.ac.at To: FreeBSD Current , FreeBSD Hackers Subject: panic: vm_page_free with -current Message-Id: 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 ; 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 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 ; 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 ; 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" 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 ; 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: 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 ; 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 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: > > : /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 ; 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 ; 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" 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/ 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 ; 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" 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/ 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 ; 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 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: (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 ; 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 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 > >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 ; 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" 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" 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 ; 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 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" 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: 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 ; 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 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: > > 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 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 ; 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 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 ; 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 being a startup script of sequence . 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 will be called from system rc files. They will be sorted in shell globbing order (so the 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 ; 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 To: Terry Lambert 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: 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 ; 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 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 > will be called from system rc files. They will be sorted in shell > globbing order (so the 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 ; 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 ; 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 To: current@freefall.cdrom.com, Joerg Wunsch cc: current@freefall.cdrom.com Subject: Re: Interesting NFS problem with -current In-Reply-To: <199507241058.MAA05269@uriah.heep.sax.de> Message-ID: 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: > > > > : /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 ; 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 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 ; 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 ; 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 ; 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 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 ; 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 ); 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 ; 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 Message-Id: <9507251419.AA06573@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: "Rodney W. Grimes" , 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 < 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 ; 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 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 ; 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 ; 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 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 ; 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 To: Q Li cc: freebsd-current@freebsd.org Subject: Re: problem running tcpdump In-Reply-To: <199507251000.LAA08395@sun.leeds.ac.uk> Message-ID: 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 ; 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: 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 ; 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: 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 ; 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 ; 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 ; 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 Message-Id: <199507252227.AAA06375@localhost.cs.tu-berlin.de> To: current@freebsd.org Subject: Manual page checker Replyt-to: Wolfram Schneider 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 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 <&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() { 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 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 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 ; 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 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 ; 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 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: 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 ; 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 cc: "Jordan K. Hubbard" , 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." Date: Tue, 25 Jul 1995 19:24:05 -0700 Message-ID: <26316.806725445@time.cdrom.com> From: "Jordan K. Hubbard" 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 cc: "Jordan K. Hubbard" , 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." Date: Tue, 25 Jul 1995 19:24:56 -0700 Message-ID: <26483.806725496@time.cdrom.com> From: "Jordan K. Hubbard" 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 ; 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 cc: "Rodney W. Grimes" , 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" 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" 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" 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 ; 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 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 :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 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 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 ; 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 ; 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" 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 #include #include + #include 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 ; 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 ; 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" 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 ; 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: 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 ; 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 ; 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" 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 " 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 ; 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" 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 ; 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 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 ; 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 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 ; 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 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 ; 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 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 ; 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 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: <9507252105.AA17181@cs.weber.edu> Sender: current-owner@freebsd.org Precedence: bulk < 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 ; 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 Message-Id: <9507261406.AA08195@halloran-eldar.lcs.mit.edu> To: "Serge A. Babkin" 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! < 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 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 ; 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 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 > > < 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 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 ; 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" 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 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" 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 > > > > < 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 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 ; 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" 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 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" 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" 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 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" 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 ; 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 > < > > 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// 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 ; 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 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 < 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 ; 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 ; 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 ; 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" 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 ; 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" 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 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 ; 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" 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! > > < 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 #include #include + #include 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 ; 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: 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 ; 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 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 :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 ; 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 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 < 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 ; 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 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 ; 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 To: current@freebsd.org Subject: diskless swapping Message-ID: 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 ; 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 To: freebsd-current@freebsd.org Subject: question on 2.1-STABLE Message-ID: 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 ; 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 ; 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 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 < 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 ; 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 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 ; 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 ; 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 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." Date: Thu, 27 Jul 1995 13:52:19 -0700 Message-ID: <2215.806878339@time.cdrom.com> From: "Jordan K. Hubbard" 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 ; 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 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 <> 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 ; 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 To: Robin Cutshaw cc: freebsd-current@freebsd.org Subject: Re: SMC Ultra interrupt problem In-Reply-To: <199507271838.OAA21637@intercore.com> Message-ID: 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 ; 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 ; 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 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: 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 ; 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 To: Robin Cutshaw cc: freebsd-current@freebsd.org Subject: Re: SMC Ultra interrupt problem In-Reply-To: <199507280228.WAA00588@intercore.com> Message-ID: 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 ; 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 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: 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 ; 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" 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 ; 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 ; 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 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" 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" 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 ; 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 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 ; 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 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 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 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 ; 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" 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 ; 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 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 > >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 ; 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 ; 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 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 ; 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 ; 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 ; 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 Message-Id: <199507292025.WAA01243@localhost> To: current@FreeBSD.org Subject: german words file Reply-to: Wolfram Schneider 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 ; 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 ; 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 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 ; 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 ; 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 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 ; 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 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 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 ; 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 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 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 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" 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 ; 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 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. ;-)