From owner-freebsd-current Sun Jul 16 02:04:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA11372 for current-outgoing; Sun, 16 Jul 1995 02:04:46 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA11353 for ; Sun, 16 Jul 1995 02:04:39 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA22263 for current@freebsd.org; Sun, 16 Jul 1995 19:03:35 +1000 Date: Sun, 16 Jul 1995 19:03:35 +1000 From: Bruce Evans Message-Id: <199507160903.TAA22263@godzilla.zeta.org.au> To: current@freebsd.org Subject: out of date binaries on freefall Sender: current-owner@freebsd.org Precedence: bulk /usr/sbin/config is dated May 31 1995. There have been several commits to config since then. bash is dated June 8 1995 but is version 1.14.2 which is almost a year old and has an annoying linewrap bug in column 80. Bruce From owner-freebsd-current Sun Jul 16 03:01:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA16956 for current-outgoing; Sun, 16 Jul 1995 03:01:39 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id DAA16928 for ; Sun, 16 Jul 1995 03:01:34 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA23567; Sun, 16 Jul 1995 12:01:31 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA00604 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 12:01:30 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id JAA16485 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 09:41:08 +0200 From: J Wunsch Message-Id: <199507160741.JAA16485@uriah.heep.sax.de> Subject: Move mt(1) to /bin? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 16 Jul 1995 09:41:07 +0200 (MET DST) 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 I've once been asking this, and got null opinions. IMHO, we should move the mt(1) command from /usr/bin into /bin, since it's containing functionality to modify the SCSI tape driver now that will be needed in order to recover a system from SCSI tapes on several sites. Currently, a statically linked mt command will bloat /bin by -rwxr-xr-x 1 j bin 53248 Jul 16 09:30 mt* compared to the dynamic /usr/bin/mt: -r-xr-xr-x 1 bin bin 12288 Apr 29 22:34 /usr/bin/mt* Unless somebody objects, i would going to move it some day. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Jul 16 05:00:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA21939 for current-outgoing; Sun, 16 Jul 1995 05:00:15 -0700 Received: from kryten.atinc.com ([198.138.38.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA21929 for ; Sun, 16 Jul 1995 05:00:13 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id HAA06401; Sun, 16 Jul 1995 07:53:33 -0400 Date: Sun, 16 Jul 1995 07:53:32 -0400 (EDT) From: "Jonathan M. Bresler" Subject: point-to-point links require destination addr To: current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk in 2.0.5 and later, point-to-point links, lp0 and sl0 (have not tried ppp0) require a destination address in the ifconfig line. this was not the case previously. if the destination is omitted 'ifconfig sl0 inet 111.222.333.444' EADDRNOTAVAIL 'Can't assign requested address' is returned. can this be changed to EDESTADDRREQ 'Destination address required' bug report kern/619 (from memory, submitted by me on friday--yes i can see how busy everyone is--an ulterior motive is to send mail to current for a test purpose, and include some useful information inplace of the usual 'this message left blank' ;) include the one line diff jmb Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-current Sun Jul 16 05:30:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA22425 for current-outgoing; Sun, 16 Jul 1995 05:30:14 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA22419 for ; Sun, 16 Jul 1995 05:30:12 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id FAA08269; Sun, 16 Jul 1995 05:29:13 -0700 From: "Rodney W. Grimes" Message-Id: <199507161229.FAA08269@gndrsh.aac.dev.com> Subject: Re: out of date binaries on freefall To: bde@zeta.org.au (Bruce Evans) Date: Sun, 16 Jul 1995 05:29:13 -0700 (PDT) Cc: current@freebsd.org In-Reply-To: <199507160903.TAA22263@godzilla.zeta.org.au> from "Bruce Evans" at Jul 16, 95 07:03:35 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: 721 Sender: current-owner@freebsd.org Precedence: bulk > > /usr/sbin/config is dated May 31 1995. There have been several commits > to config since then. Freefall never has run -current, it is suppose to be running RELEASE, but due to 2.0R bugs was upgraded a few times. Freefall is not such a great place to compile -current kernels, and hasn't been for 1.5 years. > bash is dated June 8 1995 but is version 1.14.2 which is almost a year > old and has an annoying linewrap bug in column 80. That should be updated, and am surprized that it isn't considering how many folks we have using bash on freefall. > Bruce -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Jul 16 05:39:58 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA22652 for current-outgoing; Sun, 16 Jul 1995 05:39:58 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA22646 for ; Sun, 16 Jul 1995 05:39:56 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id FAA08384 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 05:39:40 -0700 From: "Rodney W. Grimes" Message-Id: <199507161239.FAA08384@gndrsh.aac.dev.com> Subject: Re: Move mt(1) to /bin? To: freebsd-current@FreeBSD.org Date: Sun, 16 Jul 1995 05:39:40 -0700 (PDT) In-Reply-To: <199507160741.JAA16485@uriah.heep.sax.de> from "J Wunsch" at Jul 16, 95 09:41:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1301 Sender: current-owner@FreeBSD.org Precedence: bulk > > I've once been asking this, and got null opinions. IMHO, we should > move the mt(1) command from /usr/bin into /bin, since it's containing > functionality to modify the SCSI tape driver now that will be needed > in order to recover a system from SCSI tapes on several sites. > > Currently, a statically linked mt command will bloat /bin by > > -rwxr-xr-x 1 j bin 53248 Jul 16 09:30 mt* > > compared to the dynamic /usr/bin/mt: > > -r-xr-xr-x 1 bin bin 12288 Apr 29 22:34 /usr/bin/mt* > > > Unless somebody objects, i would going to move it some day. I don't want to go doing this on a binary by binary as the need comes up. There are several things that given the same above conditions should be moved to /, and several that could move the other way. I object to this single binary move, until we have a clear definition of what goes in / vs what goes in /usr and every binary in /, /sbin, /usr/bin and /usr/sbin has these definitions applied to them and a list of moves created. Also don't move things around with cvs remove/cvs add, contact me for a repository copy, otherwise history information is lost into the Attic. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Jul 16 05:41:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA22698 for current-outgoing; Sun, 16 Jul 1995 05:41:18 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA22692 for ; Sun, 16 Jul 1995 05:41:17 -0700 Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id FAA13853; Sun, 16 Jul 1995 05:40:38 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id FAA00925; Sun, 16 Jul 1995 05:41:49 -0700 Message-Id: <199507161241.FAA00925@corbin.Root.COM> To: "Rodney W. Grimes" cc: bde@zeta.org.au (Bruce Evans), current@freebsd.org Subject: Re: out of date binaries on freefall In-reply-to: Your message of "Sun, 16 Jul 95 05:29:13 PDT." <199507161229.FAA08269@gndrsh.aac.dev.com> From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 16 Jul 1995 05:41:48 -0700 Sender: current-owner@freebsd.org Precedence: bulk >> /usr/sbin/config is dated May 31 1995. There have been several commits >> to config since then. > >Freefall never has run -current, it is suppose to be running RELEASE, >but due to 2.0R bugs was upgraded a few times. Freefall is not such >a great place to compile -current kernels, and hasn't been for 1.5 years. > >> bash is dated June 8 1995 but is version 1.14.2 which is almost a year >> old and has an annoying linewrap bug in column 80. > >That should be updated, and am surprized that it isn't considering how >many folks we have using bash on freefall. Freefall will be upgraded to 2.1R when it is available. I'd prefer not mess with it until that time. -DG From owner-freebsd-current Sun Jul 16 05:41:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA22745 for current-outgoing; Sun, 16 Jul 1995 05:41:31 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA22739 for ; Sun, 16 Jul 1995 05:41:29 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA26825; Sun, 16 Jul 1995 14:41:26 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA01429; Sun, 16 Jul 1995 14:41:26 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id OAA19717; Sun, 16 Jul 1995 14:40:03 +0200 From: J Wunsch Message-Id: <199507161240.OAA19717@uriah.heep.sax.de> Subject: Re: point-to-point links require destination addr To: jmb@kryten.Atinc.COM (Jonathan M. Bresler) Date: Sun, 16 Jul 1995 14:40:02 +0200 (MET DST) Cc: current@freebsd.org In-Reply-To: from "Jonathan M. Bresler" at Jul 16, 95 07:53:32 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: 446 Sender: current-owner@freebsd.org Precedence: bulk As Jonathan M. Bresler wrote: > > > if the destination is omitted 'ifconfig sl0 inet 111.222.333.444' > EADDRNOTAVAIL 'Can't assign requested address' is returned. This is ok for your address. How are 333 and 444 supposed to go into a single byte^H^H^H^Hoctet? :-) (I've got your point 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 Sun Jul 16 07:01:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA25015 for current-outgoing; Sun, 16 Jul 1995 07:01:30 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA25005 ; Sun, 16 Jul 1995 07:01:21 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id XAA01095; Sun, 16 Jul 1995 23:44:21 +0930 From: Michael Smith Message-Id: <199507161414.XAA01095@genesis.atrad.adelaide.edu.au> Subject: Re: XFree86 and swap To: rsnow@legend.txdirect.net (Rob Snow) Date: Sun, 16 Jul 1995 23:44:20 +0930 (CST) Cc: paul@FreeBSD.org, FreeBSD-current@FreeBSD.org In-Reply-To: from "Rob Snow" at Jul 15, 95 04:17:10 pm Content-Type: text Content-Length: 1312 Sender: current-owner@FreeBSD.org Precedence: bulk Rob Snow stands accused of saying: > > > What clients are you cycling through on that server? Also, have you > > > tried linking it with gnu malloc? This should result in much better > > > memory utilization, though with an unknown impact on stability. > > > > Mainly netscape, apart from the usual xterms and a few odds and > > ends. > > Interesting. You may have seen my posts about "how to add swapfile?" > because my swap kept getting eaten and never flushed. Last night I did > a test and started X and everything looked fine until I ran Netscape and > browsed around. When I finished my Xserver was 14M. (in about 45minutes) That's not terribly suprising. > BTW, It stayed at 14MB when I exited Netscape. Either I'm behind the times, or you are failing to understand a fundamental fact about memory allocation under BSD (and IIRC most unices.) Processes can only ever grow, they can never shrink. > Rob Snow -- ]] 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 Sun Jul 16 07:14:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA25530 for current-outgoing; Sun, 16 Jul 1995 07:14:09 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA25521 ; Sun, 16 Jul 1995 07:14:06 -0700 Message-Id: <199507161414.HAA25521@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: freebsd-current@freebsd.org (FreeBSD-current users), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Move mt(1) to /bin? In-reply-to: Your message of "Sun, 16 Jul 95 09:41:07 +0200." <199507160741.JAA16485@uriah.heep.sax.de> Date: Sun, 16 Jul 1995 07:14:05 -0700 From: "Justin T. Gibbs" Sender: current-owner@freebsd.org Precedence: bulk >Unless somebody objects, i would going to move it some day. > >-- >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. ;-) No objection on my part. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sun Jul 16 07:18:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA25730 for current-outgoing; Sun, 16 Jul 1995 07:18:11 -0700 Received: from intercore.com (num1sun.intercore.com [205.198.76.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA25724 ; Sun, 16 Jul 1995 07:18:07 -0700 Received: (robin@localhost) by intercore.com (8.6.9/8.6.4) id KAA02795; Sun, 16 Jul 1995 10:14:18 -0400 From: Robin Cutshaw Message-Id: <199507161414.KAA02795@intercore.com> Subject: Re: XFree86 and swap To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sun, 16 Jul 1995 10:14:17 -0400 (EDT) Cc: rsnow@legend.txdirect.net, paul@FreeBSD.org, FreeBSD-current@FreeBSD.org In-Reply-To: <199507161414.XAA01095@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 16, 95 11:44:20 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: 451 Sender: current-owner@FreeBSD.org Precedence: bulk > > > BTW, It stayed at 14MB when I exited Netscape. > > Either I'm behind the times, or you are failing to understand a fundamental > fact about memory allocation under BSD (and IIRC most unices.) > > Processes can only ever grow, they can never shrink. > Actually, we (the XFree86 team) are testing a new memory allocator that uses mmap for large allocations in the Xserver. We are actually giving back memory now using this technique. robin From owner-freebsd-current Sun Jul 16 07:34:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA26350 for current-outgoing; Sun, 16 Jul 1995 07:34:19 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA26340 for ; Sun, 16 Jul 1995 07:34:14 -0700 Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id HAA14174; Sun, 16 Jul 1995 07:32:40 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id HAA03061; Sun, 16 Jul 1995 07:33:51 -0700 Message-Id: <199507161433.HAA03061@corbin.Root.COM> To: Michael Smith cc: rsnow@legend.txdirect.net (Rob Snow), FreeBSD-current@freebsd.org Subject: Re: XFree86 and swap In-reply-to: Your message of "Sun, 16 Jul 95 23:44:20 +0930." <199507161414.XAA01095@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 16 Jul 1995 07:31:20 -0700 Sender: current-owner@freebsd.org Precedence: bulk >> BTW, It stayed at 14MB when I exited Netscape. > >Either I'm behind the times, or you are failing to understand a fundamental >fact about memory allocation under BSD (and IIRC most unices.) > >Processes can only ever grow, they can never shrink. Fundamental? BSD malloc doesn't free memory back to the system, but GNU malloc and several others do. We plan to switch to one of these other mallocs (not a GPL'd one) at some point in the future (perhaps 2.2). -DG From owner-freebsd-current Sun Jul 16 09:33:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA29355 for current-outgoing; Sun, 16 Jul 1995 09:33:18 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA29349 for ; Sun, 16 Jul 1995 09:33:16 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.11/8.6.9) id MAA05179; Sun, 16 Jul 1995 12:34:02 -0400 Date: Sun, 16 Jul 1995 12:34:02 -0400 From: Charles Henrich Message-Id: <199507161634.MAA05179@crh.cl.msu.edu> To: davidg@Root.COM, freebsd-current@freebsd.org Subject: Re: XFree86 and swap Newsgroups: lists.freebsd.current References: <3ub86h$qp1@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 #3 (NOV) Sender: current-owner@freebsd.org Precedence: bulk In lists.freebsd.current you write: >>> BTW, It stayed at 14MB when I exited Netscape. >> >>Either I'm behind the times, or you are failing to understand a fundamental >>fact about memory allocation under BSD (and IIRC most unices.) >> >>Processes can only ever grow, they can never shrink. > Fundamental? BSD malloc doesn't free memory back to the system, but >GNU malloc and several others do. We plan to switch to one of these other >mallocs (not a GPL'd one) at some point in the future (perhaps 2.2). Unfortunatly in the X server situation, it helps but the server still grows amazingly large over time. Using gnumalloc just increases time. My server grows to 15m within a day of starting it, and stays there :(. -Crh -- Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-current Sun Jul 16 09:51:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA29637 for current-outgoing; Sun, 16 Jul 1995 09:51:39 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA29626 for ; Sun, 16 Jul 1995 09:51:36 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA01185; Sun, 16 Jul 1995 18:51:33 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA02770 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 18:51:32 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id SAA20762 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 18:25:25 +0200 From: J Wunsch Message-Id: <199507161625.SAA20762@uriah.heep.sax.de> Subject: Re: Move mt(1) to /bin? To: freebsd-current@FreeBSD.org Date: Sun, 16 Jul 1995 18:25:25 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org In-Reply-To: <199507161239.FAA08384@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 16, 95 05:39:40 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: 1047 Sender: current-owner@FreeBSD.org Precedence: bulk As Rodney W. Grimes wrote: > > > Unless somebody objects, i would going to move it some day. > > I don't want to go doing this on a binary by binary as the need > comes up. There are several things that given the same above > conditions should be moved to /, and several that could move > the other way. Ok. NB: i've made the above threat since this seems to be the only way to get opinions from other folks here... This is not to say mt(1) wouldn't be needed, it is. While ``mt fsf'' could also be performed by ``dd if=/dev/nrst0 of=/dev/null'', things like ``mt blocksize'' and ``mt density'' cannot be emulated. > Also don't move things around with cvs remove/cvs add, contact me for > a repository copy, otherwise history information is lost into the Attic. Of course. I didn't think about doing this myself. I know that this is the kind of stuff to leave for our Repository Meister. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Jul 16 09:51:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA29676 for current-outgoing; Sun, 16 Jul 1995 09:51:59 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA29670 for ; Sun, 16 Jul 1995 09:51:56 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA01194; Sun, 16 Jul 1995 18:51:44 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA02785; Sun, 16 Jul 1995 18:51:42 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id SAA20875; Sun, 16 Jul 1995 18:37:12 +0200 From: J Wunsch Message-Id: <199507161637.SAA20875@uriah.heep.sax.de> Subject: Re: XFree86 and swap To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 16 Jul 1995 18:37:12 +0200 (MET DST) Cc: msmith@atrad.adelaide.edu.au (Michael Smith) In-Reply-To: <199507161414.XAA01095@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 16, 95 11:44:20 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: 309 Sender: current-owner@FreeBSD.org Precedence: bulk As Michael Smith wrote: > > Processes can only ever grow, they can never shrink. At least since V7, processes can also shrink. See the HISTORY section of brk(2). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Jul 16 10:02:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA00300 for current-outgoing; Sun, 16 Jul 1995 10:02:16 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA00287 for ; Sun, 16 Jul 1995 10:02:14 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA01401; Sun, 16 Jul 1995 19:02:10 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA03336 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 19:02:10 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id SAA20974 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 18:55:31 +0200 From: J Wunsch Message-Id: <199507161655.SAA20974@uriah.heep.sax.de> Subject: Re: XFree86 and swap To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 16 Jul 1995 18:55:30 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) In-Reply-To: <199507161634.MAA05179@crh.cl.msu.edu> from "Charles Henrich" at Jul 16, 95 12:34:02 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: 582 Sender: current-owner@FreeBSD.org Precedence: bulk As Charles Henrich wrote: > > Unfortunatly in the X server situation, it helps but the server still grows > amazingly large over time. Using gnumalloc just increases time. My server > grows to 15m within a day of starting it, and stays there :(. This is due to memory fragmentation when applications are requesting storage for (too) many pixmaps. You can try to limit the datasize for the server and see what would crash then... :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Jul 16 10:03:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA00554 for current-outgoing; Sun, 16 Jul 1995 10:03:33 -0700 Received: from specgw.spec.co.jp (specgw.spec.co.jp [202.32.13.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA00535 ; Sun, 16 Jul 1995 10:03:28 -0700 Received: from localhost (uucp@localhost) by specgw.spec.co.jp (8.6.5/3.3Wb-SPEC) with UUCP id BAA07513; Mon, 17 Jul 1995 01:54:02 +0901 Received: by tama.spec.co.jp (8.6.11/6.4J.5) id BAA00676; Mon, 17 Jul 1995 01:39:25 +0900 From: Atsushi Murai Message-Id: <199507161639.BAA00676@tama.spec.co.jp> Subject: Re: ppp SIOCAIFADDR: File exists + Usage: add dest mask gateway To: jhs@vector.eikon.e-technik.tu-muenchen.de (Julian Howard Stacey) Date: Mon, 17 Jul 1995 01:39:25 +0900 (JST) Cc: current@freebsd.org, gj@freebsd.org In-Reply-To: <199507131219.OAA02511@vector.eikon.e-technik.tu-muenchen.de> from "Julian Howard Stacey" at Jul 13, 95 02:19:03 pm Reply-To: amurai@spec.co.jp X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 344 Sender: current-owner@freebsd.org Precedence: bulk > Any hints or advice most welcome ! What's described in your ppp.linkup ? > Thanks > Julian > --- > Julian Stacey jhs@freebsd.org & jhs@regent.e-technik.tu-muenchen.de Atsushi. -- Atsushi Murai Internet: amurai@spec.co.jp System Planning and Engineering Co,.Ltd. Voice : +81-33833-5341 From owner-freebsd-current Sun Jul 16 11:54:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA04277 for current-outgoing; Sun, 16 Jul 1995 11:54:20 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA04269 for ; Sun, 16 Jul 1995 11:54:16 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id LAA09001 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 11:53:58 -0700 From: "Rodney W. Grimes" Message-Id: <199507161853.LAA09001@gndrsh.aac.dev.com> Subject: Re: Move mt(1) to /bin? To: freebsd-current@FreeBSD.org Date: Sun, 16 Jul 1995 11:53:58 -0700 (PDT) In-Reply-To: <199507161625.SAA20762@uriah.heep.sax.de> from "J Wunsch" at Jul 16, 95 06:25:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4007 Sender: current-owner@FreeBSD.org Precedence: bulk > > As Rodney W. Grimes wrote: > > > > > Unless somebody objects, i would going to move it some day. > > > > I don't want to go doing this on a binary by binary as the need > > comes up. There are several things that given the same above > > conditions should be moved to /, and several that could move > > the other way. > > Ok. NB: i've made the above threat since this seems to be the only > way to get opinions from other folks here... This is not to say mt(1) > wouldn't be needed, it is. While ``mt fsf'' could also be performed > by ``dd if=/dev/nrst0 of=/dev/null'', things like ``mt blocksize'' and > ``mt density'' cannot be emulated. I don't have a problem with the technical reason that mt should move to /bin (or more probably /sbin since only root and operator class users cat access a tape device anyway) and agree this is one of them that should be static and on / _if_ the critera for being on / says ``Anything needed to restore a system from tape'' as one of it's items. The current man 7 hier is rather ambigous: /bin/ user utilities fundamental to both single-user and multi-user environments /sbin/ system programs and administration utilities fundamental to both single-user and multi-user environments I've almost growen sick of the /bin vs /usr/bin problems and maybe we should do what Bruce is doing and just make _every_ thing shared and move the libraries onto /lib :-) And while we are at it /usr/bin -> /bin and /usr/sbin -> /sbin. (That would be a 13MB increase for the shared /usr/bin and /usr/sbin, 3MB for /usr/lib/*.so.*, and I don't know what the shrink for shared /bin and /sbin is, but I seem to remeber Bruce saying that it makes the /usr/lib/*.so.* actually a 0 size increase to the root partition if you run all of /bin and /sbin shared, but I don't think we want all of it shared (/bin/sh is a bad things to have shared due to frequence of invokation and shlib startup times). I have seriously digressed from the original topic :-(, I'll move mt now, if no one objects to the folling moves: /usr/sbin -> /sbin bad144 (needed to fix your disk before you can restore from tape), chown (needed to fix and build /dev entries so you can mount your disk routed (needed to find routes to remote hosts before mounting nfs /usr or using a remote tape device to restore /usr from) sysctl (needed to tweak settings frequently so you can get to things over the network so you can get your system back to life) /usr/bin -> /bin awk (needed by /dev/MAKEDEV to rebuild several /dev entries that give you serious headaches if you try to do MAKEDEV all without /usr around, could be coded around with sh probably) chflags (So you can fix a permission problem that prevents you from restoring some part of / or /usr.) mt (So you can set the density on /dev/st0 to read your backup tape). I am going to stop now... but you get the idea... I have a very large pile of requests to move stuff to /bin, but not a one to go the other way :-(. IMHO, probably should not do these, though they have been requested at one time or another: kbdcontrol (Yes, I actually have a pending request to make this usable in single user mode, mainly to handle backspace key mapping, and load full keymap files, but that means /usr/share/syscons would need moving too :-() > > Also don't move things around with cvs remove/cvs add, contact me for > > a repository copy, otherwise history information is lost into the Attic. > > Of course. I didn't think about doing this myself. I know that this > is the kind of stuff to leave for our Repository Meister. ;-) > > -- > 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. ;-) > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Jul 16 17:58:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA16140 for current-outgoing; Sun, 16 Jul 1995 17:58:49 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA16132 for ; Sun, 16 Jul 1995 17:58:41 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA03333 (5.65c8/HUTCS-S 1.4 for ); Mon, 17 Jul 1995 03:58:36 +0300 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id DAA08168; Mon, 17 Jul 1995 03:58:38 +0300 Date: Mon, 17 Jul 1995 03:58:38 +0300 Message-Id: <199507170058.DAA08168@shadows.cs.hut.fi> From: Heikki Suonsivu To: davidg@root.com Cc: freebsd-current@freefall.cdrom.com In-Reply-To: David Greenman's message of 14 Jul 1995 17:47:50 +0300 Subject: Re: current breaks 2.0.5 binary Organization: Helsinki University of Technology, Otaniemi, Finland Sender: current-owner@FreeBSD.org Precedence: bulk >kvm_open: proc size mismatch (35520 total, 620 chunks) >top: Out of memory. " NOTE: libkvm, w, ps, 'top', and any other utility which depends on struct proc or any VM system structure will have to be rebuilt!!! " In addition, I had to remove /var/db/kvm_kernel.db and rebuild it. Just rebuilding produced a core dump from kvm_mkdb. Could it be sensible to add rm -f /var/db/kvm_kernel.db before kvm_mkdb in /etc/rc? -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Sun Jul 16 18:13:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA17455 for current-outgoing; Sun, 16 Jul 1995 18:13:39 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA17443 for ; Sun, 16 Jul 1995 18:13:35 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA00595; Sun, 16 Jul 1995 18:13:57 -0700 From: "Rodney W. Grimes" Message-Id: <199507170113.SAA00595@gndrsh.aac.dev.com> Subject: Re: current breaks 2.0.5 binary To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Sun, 16 Jul 1995 18:13:57 -0700 (PDT) Cc: davidg@Root.COM, freebsd-current@freefall.cdrom.com In-Reply-To: <199507170058.DAA08168@shadows.cs.hut.fi> from "Heikki Suonsivu" at Jul 17, 95 03:58:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 914 Sender: current-owner@FreeBSD.org Precedence: bulk > > > >kvm_open: proc size mismatch (35520 total, 620 chunks) > >top: Out of memory. > > " NOTE: libkvm, w, ps, 'top', and any other utility which depends on struct > proc or any VM system structure will have to be rebuilt!!! " > > In addition, I had to remove /var/db/kvm_kernel.db and rebuild it. Just > rebuilding produced a core dump from kvm_mkdb. This is the bug that should be fixed, kvm_mkdb must be blowing up in the attempt to validate the current db file, it should not do that :-(. > Could it be sensible to add > > rm -f /var/db/kvm_kernel.db > > before kvm_mkdb in /etc/rc? This is a bandaid to hide the real bug, I do not want a bandaid, I want a real fix :-). Now the crux, I can't get kvm_mkdb to core for me :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Jul 16 21:36:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA27997 for current-outgoing; Sun, 16 Jul 1995 21:36:26 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA27990 for ; Sun, 16 Jul 1995 21:36:22 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id VAA00381 for current@freebsd.org; Sun, 16 Jul 1995 21:36:53 -0700 From: "Rodney W. Grimes" Message-Id: <199507170436.VAA00381@gndrsh.aac.dev.com> Subject: patch for /usr/src/usr.sbin/ppp/chat.c (fwd) To: current@freebsd.org Date: Sun, 16 Jul 1995 21:36:53 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1439 Sender: current-owner@freebsd.org Precedence: bulk This patch has been reviewed by me, and looks good for inclusion. I would like the ppp folks to look at it and incorporate it as well as feed it back to the ppp maintainers. Thanks, Rod Grimes Forwarded message: > From rich@lamprey.utmb.edu Sun Jul 16 21:00:41 1995 > Date: Sun, 16 Jul 1995 22:59:59 -0500 > From: Rich Murphey > Message-Id: <199507170359.WAA03793@id.slip.bcm.tmc.edu> > To: rgrimes@gndrsh.aac.dev.com > Subject: patch for /usr/src/usr.sbin/ppp/chat.c > Return-Receipt-To: rich@lamprey.utmb.edu > Reply-to: rich@lamprey.utmb.edu > > > I'm a little uneasy about having the user-level-ppp daemon > echo your password to /usr/log/ppp.log. Here's a patch that > logs the token that represents the password (\P) rather than > the password itself. Rich > > > --- chat.c.dist Tue May 30 06:21:52 1995 > +++ chat.c Sun Jul 16 22:56:17 1995 > @@ -373,7 +373,11 @@ > } else { > (void) ExpandString(str, buff+2, 1); > } > + if (strchr(str, "\P")) { /* Do not log the password itself. */ > + LogPrintf(LOG_CHAT, "sending: %s\n", str); > + } else { > LogPrintf(LOG_CHAT, "sending: %s\n", buff+2); > + } > cp = buff; > if (DEV_IS_SYNC) > bcopy("\377\003", buff, 2); /* Prepend HDLC header */ > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Jul 16 21:37:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA28088 for current-outgoing; Sun, 16 Jul 1995 21:37:08 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA28080 for ; Sun, 16 Jul 1995 21:37:01 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA18589; Mon, 17 Jul 1995 14:32:53 +1000 Date: Mon, 17 Jul 1995 14:32:53 +1000 From: Bruce Evans Message-Id: <199507170432.OAA18589@godzilla.zeta.org.au> To: davidg@root.com, hsu@cs.hut.fi Subject: Re: current breaks 2.0.5 binary Cc: freebsd-current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >In addition, I had to remove /var/db/kvm_kernel.db and rebuild it. Just >rebuilding produced a core dump from kvm_mkdb. >Could it be sensible to add >rm -f /var/db/kvm_kernel.db >before kvm_mkdb in /etc/rc? No, kvm_mkdb goes to a lot of trouble to use the existing database. This speeds up booting by a whole 1 second on my 486DX2/66. It was about 5 times slower in 2.0 because of poor buffering in kvm_mkdb and poor caching in ufs. The poor buffering has been fixed. Bruce From owner-freebsd-current Sun Jul 16 21:56:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA29694 for current-outgoing; Sun, 16 Jul 1995 21:56:53 -0700 Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA29675 for ; Sun, 16 Jul 1995 21:56:48 -0700 Received: by haven.uniserve.com id <30733>; Sun, 16 Jul 1995 21:58:02 +0100 Date: Sun, 16 Jul 1995 21:57:52 -0700 (PDT) From: Tom Samplonius To: Bruce Evans cc: davidg@root.com, hsu@cs.hut.fi, freebsd-current@freefall.cdrom.com Subject: Re: current breaks 2.0.5 binary In-Reply-To: <199507170432.OAA18589@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Mon, 17 Jul 1995, Bruce Evans wrote: > >In addition, I had to remove /var/db/kvm_kernel.db and rebuild it. Just > >rebuilding produced a core dump from kvm_mkdb. > > >Could it be sensible to add > > >rm -f /var/db/kvm_kernel.db > > >before kvm_mkdb in /etc/rc? > > No, kvm_mkdb goes to a lot of trouble to use the existing database. This > speeds up booting by a whole 1 second on my 486DX2/66. It was about 5 > times slower in 2.0 because of poor buffering in kvm_mkdb and poor > caching in ufs. The poor buffering has been fixed. Perhaps add "rm -f /var/db/kvm_kernel.db" to the "install" target for the kernel makefile? Tom From owner-freebsd-current Sun Jul 16 23:54:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA05652 for current-outgoing; Sun, 16 Jul 1995 23:54:03 -0700 Received: from laphroaig.cs.hut.fi (hsu@laphroaig.cs.hut.fi [130.233.192.94]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA05642 for ; Sun, 16 Jul 1995 23:53:59 -0700 Received: by laphroaig.cs.hut.fi id AA17061 (5.65c8/HUTCS-C 1.3 for freebsd-current@freefall.cdrom.com); Mon, 17 Jul 1995 09:53:23 +0300 Date: Mon, 17 Jul 1995 09:53:23 +0300 From: Heikki Suonsivu Message-Id: <199507170653.AA17061@laphroaig.cs.hut.fi> To: Tom Samplonius Cc: Bruce Evans , davidg@root.com, hsu@cs.hut.fi, freebsd-current@freefall.cdrom.com Subject: Re: current breaks 2.0.5 binary In-Reply-To: References: <199507170432.OAA18589@godzilla.zeta.org.au> Organization: Helsinki University of Technology, Otaniemi, Finland Sender: current-owner@FreeBSD.org Precedence: bulk Tom Samplonius writes: > Perhaps add "rm -f /var/db/kvm_kernel.db" to the "install" target for > the kernel makefile? I compile kernels in fast servers and just copy them over to other machines (slow routers with 8M of memory and so on, no NFS). This wouldn't work. FreeBSD test doesn't seem to have -nt option (like in bash), that would be handy for checking out if the kernel is newer than the database. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Mon Jul 17 00:07:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA06610 for current-outgoing; Mon, 17 Jul 1995 00:07:16 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA06487 for ; Mon, 17 Jul 1995 00:05:57 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA22357; Mon, 17 Jul 1995 17:00:50 +1000 Date: Mon, 17 Jul 1995 17:00:50 +1000 From: Bruce Evans Message-Id: <199507170700.RAA22357@godzilla.zeta.org.au> To: freebsd-current@freebsd.org, rgrimes@gndrsh.aac.dev.com Subject: Re: Move mt(1) to /bin? Sender: current-owner@freebsd.org Precedence: bulk It should be moved to /sbin, not to /bin. >I don't want to go doing this on a binary by binary as the need >comes up. There are several things that given the same above >conditions should be moved to /, and several that could move >the other way. How about just installing it in /sbin? There are already a few Makefiles that set BINDIR to override the hierarchial default (/usr/src/bin/vgrindefs and several things in /usr/src/gnu/usr.bin/ld and a few Makefiles that set BINDIR to its default. Bruce From owner-freebsd-current Mon Jul 17 00:55:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA10676 for current-outgoing; Mon, 17 Jul 1995 00:55:15 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA10667 for ; Mon, 17 Jul 1995 00:55:12 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id AAA00692; Mon, 17 Jul 1995 00:52:24 -0700 From: "Rodney W. Grimes" Message-Id: <199507170752.AAA00692@gndrsh.aac.dev.com> Subject: Re: Move mt(1) to /bin? To: bde@zeta.org.au (Bruce Evans) Date: Mon, 17 Jul 1995 00:52:23 -0700 (PDT) Cc: freebsd-current@freebsd.org In-Reply-To: <199507170700.RAA22357@godzilla.zeta.org.au> from "Bruce Evans" at Jul 17, 95 05:00:50 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: 1401 Sender: current-owner@freebsd.org Precedence: bulk > > It should be moved to /sbin, not to /bin. > > >I don't want to go doing this on a binary by binary as the need > >comes up. There are several things that given the same above > >conditions should be moved to /, and several that could move > >the other way. > > How about just installing it in /sbin? There are already a few > Makefiles that set BINDIR to override the hierarchial default > (/usr/src/bin/vgrindefs and several things in /usr/src/gnu/usr.bin/ld ^^^^^^^^^^^^^^^^^^^^^^ does not exist on my boxes..., and from the ncvs repository has never existed there... If perhaps you mean /usr/src/usr.bin/vgrind/Makefile, well, that whole Makefile is a bloody mess, it installs 4 things in 3 difference directories in the beforeinstall target, and vfontedpr in /usr/libexec via the default install of PROG. > and a few Makefiles that set BINDIR to its default. That is a possible work around, you also need to set NOSHARED, or what ever it is to force it to be a static binary. But it still does not answer the long term question of exactly what criteria says things go in /bin vs /usr/bin. Nor does it get on with analyzing this problem so, or comeing up with a solution that prevents this type of discussion from reoccuring. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Jul 17 01:06:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA11687 for current-outgoing; Mon, 17 Jul 1995 01:06:16 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA11680 for ; Mon, 17 Jul 1995 01:06:11 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id BAA00738; Mon, 17 Jul 1995 01:06:32 -0700 From: "Rodney W. Grimes" Message-Id: <199507170806.BAA00738@gndrsh.aac.dev.com> Subject: Re: current breaks 2.0.5 binary To: mpp@legarto.minn.net (Mike Pritchard) Date: Mon, 17 Jul 1995 01:06:32 -0700 (PDT) Cc: hsu@cs.hut.fi, davidg@Root.COM, freebsd-current@freefall.cdrom.com In-Reply-To: <199507170758.CAA03221@mpp> from "Mike Pritchard" at Jul 17, 95 02:58:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1631 Sender: current-owner@FreeBSD.org Precedence: bulk > > Rodney W. Grimes wrote: > > > >kvm_open: proc size mismatch (35520 total, 620 chunks) > > > >top: Out of memory. > > > > > > " NOTE: libkvm, w, ps, 'top', and any other utility which depends on struct > > > proc or any VM system structure will have to be rebuilt!!! " > > > > > > In addition, I had to remove /var/db/kvm_kernel.db and rebuild it. Just > > > rebuilding produced a core dump from kvm_mkdb. > > > > This is the bug that should be fixed, kvm_mkdb must be blowing up in > > the attempt to validate the current db file, it should not do that :-(. > > > > > Could it be sensible to add > > > > > > rm -f /var/db/kvm_kernel.db > > > > > > before kvm_mkdb in /etc/rc? > > > > This is a bandaid to hide the real bug, I do not want a bandaid, I want > > a real fix :-). > > > > Now the crux, I can't get kvm_mkdb to core for me :-(. > > Just for the record, I've never seen kvm_mkdb core dump, either. > But for other reasons, I would like to see the kernel database > files cleaned up. I have the following in my /etc/weekly file to > remove old kernel database files: > > find /var/db -name "kvm_*.db" -a -atime +7 -exec rm -f -- {} \; > kvm_mkdb You can get the name of the running kernel with sysctl ``kern.bootfile'' and use that information to make the find find /var/db -name "kvm_*.db" -a ! -name "${kernel}"... this totally eliminates any race condition... with that done I would say it was fine to add to /etc/weekly. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Jul 17 01:42:17 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA14146 for current-outgoing; Mon, 17 Jul 1995 01:42:17 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA14124 for ; Mon, 17 Jul 1995 01:42:05 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA26603; Mon, 17 Jul 1995 18:37:08 +1000 Date: Mon, 17 Jul 1995 18:37:08 +1000 From: Bruce Evans Message-Id: <199507170837.SAA26603@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@gndrsh.aac.dev.com Subject: Re: Move mt(1) to /bin? Cc: freebsd-current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk >> (/usr/src/bin/vgrindefs and several things in /usr/src/gnu/usr.bin/ld > ^^^^^^^^^^^^^^^^^^^^^^ >does not exist on my boxes..., and from the ncvs repository has never >existed there... >If perhaps you mean /usr/src/usr.bin/vgrind/Makefile, well, that whole Yes. >>[changing BINDIR instead of moving the sources] >That is a possible work around, you also need to set NOSHARED, or what Everything in my /bin and /sbin (except ld.so) uses shared libraries :-). I need to unset NOSHARED in too many makefiles. Bruce From owner-freebsd-current Mon Jul 17 01:48:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA14800 for current-outgoing; Mon, 17 Jul 1995 01:48:48 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA14787 for ; Mon, 17 Jul 1995 01:48:43 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id KAA00478 ; Mon, 17 Jul 1995 10:47:49 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id XAA25167 ; Sun, 16 Jul 1995 23:15:33 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199507162115.XAA25167@blaise.ibp.fr> Subject: Re: XFree86 and swap To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Sun, 16 Jul 1995 23:15:32 +0200 (MET DST) Cc: davidg@Root.COM, freebsd-current@freebsd.org In-Reply-To: <199507161634.MAA05179@crh.cl.msu.edu> from "Charles Henrich" at Jul 16, 95 12:34:02 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 594 Sender: current-owner@freebsd.org Precedence: bulk > Unfortunatly in the X server situation, it helps but the server still grows > amazingly large over time. Using gnumalloc just increases time. My server > grows to 15m within a day of starting it, and stays there :(. That's interesting because I use netscape sometimes and I've used today : root 157 2.2 16.6 6512 5124 ?? S Fri12PM 16:09.02 /usr/X11R6/bin/ 5 MB is "normal size" for my gnumallocified server. It is seldom around 7 MB. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Mon Jul 17 01:48:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA14834 for current-outgoing; Mon, 17 Jul 1995 01:48:55 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA14812 for ; Mon, 17 Jul 1995 01:48:52 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id KAA00510 for ; Mon, 17 Jul 1995 10:48:36 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id VAA24644 for freebsd-current@FreeBSD.ORG; Sun, 16 Jul 1995 21:12:29 +0200 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.7.Beta.9/keltia-uucp-2.2) id UAA13954 for freebsd-current@FreeBSD.ORG; Sun, 16 Jul 1995 20:48:23 +0200 (MET DST) From: Ollivier Robert Message-Id: <199507161848.UAA13954@keltia.frmug.fr.net> Subject: New PCMCIA To: freebsd-current@freebsd.org (FreeBSD Current Users' list) Date: Sun, 16 Jul 1995 20:48:23 +0200 (MET DST) Reply-To: roberto@keltia.freenix.fr (Ollivier Robert) X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: current-owner@freebsd.org Precedence: bulk Problem with new PCMCIA code ? cc -c -O -m486 -pipe -W -Wreturn-type -Wcomment -Wredundant-decls -nostdinc -I. -I../.. -I../../sys -I../../../include -DKELTIA -DI486_CPU -DKTRACE -DGATEWAY -DSHMMAXPGS=128 -DSYSVMSG -DSYSVSEM -DSYSVSHM -DCOMPAT_LINUX -DTEST_LABELLING -DDUMMY_NOPS -DAUTO_EOI_2 -DAUTO_EOI_1 -DUCONSOLE -DSCSI_2_DEF -DCOMPAT_43 -DPROCFS -DLFS -DMFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../i386/i386/conf.c ../../i386/i386/conf.c:1199: `crdselect' undeclared here (not in a function) ../../i386/i386/conf.c:1199: initializer element for `cdevsw.d_select' is not constant *** Error code 1 Stop. ------------------------------------------------------------ machine "i386" cpu "I486_CPU" ident "KELTIA" maxusers 20 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options MFS #Berkeley Fast Filesystem options LFS #Berkeley Log Filesystem options PROCFS #Berkeley proc Filesystem options "COMPAT_43" #Compatible with BSD 4.3 options "SCSI_2_DEF" #hack for the mp1624 options UCONSOLE #for xconsole # Experimental options options "AUTO_EOI_1" options "AUTO_EOI_2" options DUMMY_NOPS options TEST_LABELLING # options "COMPAT_LINUX" options SYSVSHM options SYSVSEM options SYSVMSG options "SHMMAXPGS=128" # 512 KB of sharable memory # # Enable the kernel debugger. # options KTRACE config kernel root on sd0 swap on sd0 and sd1 and sd2 dumps on sd0 controller isa0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 controller bt0 at isa? port "IO_BT0" bio irq ? vector btintr controller scbus0 at bt0 controller ahb0 at isa? bio irq ? vector ahbintr controller scbus1 at ahb0 # BT: 2 fast disks + CD disk sd0 at scbus0 target 0 unit 0 disk sd0 at scbus0 target 2 device cd0 at scbus0 target 6 # 1742: mp1624 + all streamers disk sd1 at scbus1 target 1 tape st0 at scbus1 target 5 tape st1 at scbus1 target 4 # new sound config. controller snd0 device sb0 at isa? port 0x220 irq 5 drq 3 vector sbintr device opl0 at isa? port 0x388 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device ed0 at isa? port 0x300 net irq 10 iomem 0xcc000 vector edintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 pseudo-device ppp 1 pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device pty 24 pseudo-device speaker pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device disc #Discard device pseudo-device tun 1 #Enable user-level PPP see ppp(8) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. ------------------------------------------------------------ -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Mon Jul 17 01:49:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA14959 for current-outgoing; Mon, 17 Jul 1995 01:49:57 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA14947 for ; Mon, 17 Jul 1995 01:49:52 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id KAA00624 ; Mon, 17 Jul 1995 10:49:39 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id KAA22905 ; Sun, 16 Jul 1995 10:44:20 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199507160844.KAA22905@blaise.ibp.fr> Subject: Re: problems dumping large fs's? To: fn@pain.csrv.uidaho.edu (Faried Nawaz) Date: Sun, 16 Jul 1995 10:44:20 +0200 (MET DST) Cc: current@freebsd.org In-Reply-To: <199507151120.EAA06605@pain.csrv.uidaho.edu> from "Faried Nawaz" at Jul 15, 95 04:20:06 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 814 Sender: current-owner@freebsd.org Precedence: bulk > if i try to dump /usr/local, i get > > big-brother# dump 0uf /dev/nrst0 /usr/local > DUMP: Date of this level 0 dump: Sat Jul 15 04:02:37 1995 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /usr/local to /dev/nrst0 > DUMP: bad sblock magic number > DUMP: The ENTIRE dump is aborted. > big-brother# > > is this a known problem? this is the first time i've tried dump, btw. > tar and pax appear to operate without problems on /usr. It is not a bug it is a feature :-) dump can only dump full filesystems, not subtree of it. Your physical partition is /usr so you should dump /usr. /usr/local is not a valid file- system so it has no superblock. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Mon Jul 17 01:53:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA15269 for current-outgoing; Mon, 17 Jul 1995 01:53:04 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA15255 for ; Mon, 17 Jul 1995 01:52:58 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id KAA00608 for ; Mon, 17 Jul 1995 10:49:20 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id MAA23339 for freebsd-current@FreeBSD.ORG; Sun, 16 Jul 1995 12:06:41 +0200 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.7.Beta.9/keltia-uucp-2.2) id LAA08017 for freebsd-current@FreeBSD.ORG; Sun, 16 Jul 1995 11:55:52 +0200 (MET DST) From: Ollivier Robert Message-Id: <199507160955.LAA08017@keltia.frmug.fr.net> Subject: About ed0 problem and big Ierrs numbers To: freebsd-current@freebsd.org (FreeBSD Current Users' list) Date: Sun, 16 Jul 1995 11:55:51 +0200 (MET DST) Reply-To: roberto@keltia.freenix.fr (Ollivier Robert) X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: current-owner@freebsd.org Precedence: bulk I've run tcpdump during a FTP from my sparcbook to my PC (SMC8013EP, -current as of friday). I keep on getting bad numbers in netstat -i : Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 00.00.c0.4d.ed.08 3038 51 1204 0 0 ed0 1500 FR-ATL-NET keltia.frmug.fr 3038 51 1204 0 0 [...] 10:50:20.485274 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: . 1148929:1150389(1460) ack 1 win 4096 10:50:20.486375 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: . 1150389:1151849(1460) ack 1 win 4096 10:50:20.486972 keltia.frmug.fr.net.1089 > sidhe.frmug.fr.net.20: . ack 1151849 win 17520 10:50:20.487881 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: P 1151849:1152001(152) ack 1 win 4096 10:50:20.490232 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: . 1152001:1153461(1460) ack 1 win 4096 10:50:20.491386 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: . 1153461:1154921(1460) ack 1 win 4096 10:50:20.491946 keltia.frmug.fr.net.1089 > sidhe.frmug.fr.net.20: . ack 1154921 win 17520 10:50:20.492920 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: P 1154921:1155073(152) ack 1 win 4096 10:50:20.495212 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: . 1155073:1156533(1460) ack 1 win 4096 10:50:20.495299 sidhe.frmug.fr.net.ftp > keltia.frmug.fr.net.1086: P 853:877(24) ack 385 win 4096 10:50:20.495493 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: FP 1156533:1156979(446) ack 1 win 4096 10:50:20.495973 keltia.frmug.fr.net.1089 > sidhe.frmug.fr.net.20: . ack 1156980 win 15614 10:50:20.497509 keltia.frmug.fr.net.1089 > sidhe.frmug.fr.net.20: F 1:1(0) ack 1156980 win 17520 10:50:20.498170 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: . ack 2 win 4096 10:50:20.622065 keltia.frmug.fr.net.1086 > sidhe.frmug.fr.net.ftp: . ack 877 win 17520 10:50:20.634569 keltia.frmug.fr.net.1086 > sidhe.frmug.fr.net.ftp: P 385:391(6) ack 877 win 17520 Does it mean something to anybody ? A 4096 bytes window seems very small to me... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Mon Jul 17 01:54:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA15383 for current-outgoing; Mon, 17 Jul 1995 01:54:09 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA15376 for ; Mon, 17 Jul 1995 01:54:06 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id BAA00976; Mon, 17 Jul 1995 01:54:13 -0700 From: "Rodney W. Grimes" Message-Id: <199507170854.BAA00976@gndrsh.aac.dev.com> Subject: Re: Move mt(1) to /bin? To: mpp@legarto.minn.net (Mike Pritchard) Date: Mon, 17 Jul 1995 01:54:12 -0700 (PDT) Cc: bde@zeta.org.au, freebsd-current@freebsd.org In-Reply-To: <199507170842.DAA03545@mpp> from "Mike Pritchard" at Jul 17, 95 03:42:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2227 Sender: current-owner@freebsd.org Precedence: bulk > > Rodney W. Grimes wrote: > >... > > ever it is to force it to be a static binary. But it still does not > > answer the long term question of exactly what criteria says things go > > in /bin vs /usr/bin. Nor does it get on with analyzing this problem > > so, or coming up with a solution that prevents this type of discussion > > from reoccur-ing. > > Is there any reason not to decide this stuff right now (or at least > before 2.2)? How about everyone compiles a list of binaries they feel > should reside in /bin or /sbin and make an argument for them. > After 2 - 3 weeks, the list of proposed moves can be submitted to > the core team along with the pro/con arguments for each binary in question. Before you make decisions you should create formal criteria for the reasons things belong where they belong. If you use the above mechanism you may very well get folks like me or Bruce who find the distinction between /bin and /usr/bin of static vs shared to be pretty meaningless any more and just say ``mv /usr/bin/* /bin; mv /usr/sbin/* /sbin''. ``binaries they feel should reside'' is to wide open, we must have a list of reasonable things that when you take some binary and run down this list it clearly says one place or the other. > I'm willing to collect the data and submit a proposal to the core > team based on that data if that is what is needed. > > Let me know. If we want to pursue this, I'll draft something > up to send out to the mailing lists requesting the required > information, and we might consider posting it to the USENET groups. No! Don't do that, that is design by committee and you only end up with a mess when you do that. > Even if we decide that nothing moves locations, we may find > a set of binaries that are *REALLY* useful in getting a broken > system back up and running that could serve as an auxiliary floppy > to the boot and root floppies in emergency situations. 15 years of unix experience tell me what that list is already... and it is not the same for any 2 sites... though there is a common subset. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Jul 17 03:36:58 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA23052 for current-outgoing; Mon, 17 Jul 1995 03:36:58 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA23044 ; Mon, 17 Jul 1995 03:36:53 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id LAA24030; Mon, 17 Jul 1995 11:36:08 +0100 From: Paul Richards Message-Id: <199507171036.LAA24030@server.netcraft.co.uk> Subject: Re: XFree86 and swap To: imp@village.org (Warner Losh) Date: Mon, 17 Jul 1995 11:36:07 +0100 (BST) Cc: rsnow@legend.txdirect.net, paul@FreeBSD.org, FreeBSD-current@FreeBSD.org In-Reply-To: <199507160004.SAA02450@rover.village.org> from "Warner Losh" at Jul 15, 95 06:04:37 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: 1309 Sender: current-owner@FreeBSD.org Precedence: bulk In reply to Warner Losh who said > > : Interesting. You may have seen my posts about "how to add swapfile?" > : because my swap kept getting eaten and never flushed. Last night I did > : a test and started X and everything looked fine until I ran Netscape and > : browsed around. When I finished my Xserver was 14M. (in about 45minutes) > : > : BTW, It stayed at 14MB when I exited Netscape. > > It won't give memory back to the system. I seem to remember that our malloc was pretty stupid about freeing up memory but do you mean the X server never gives back the memory it grabs? If so, what's the reasoning? When you're running lots of X clients, like netsape and xv then you're going to use a LOT of memory in one go and if the X server never gives it back you're in trouble. > > Also, netscape (at least in some versions) eats huge amounts of server > resources by creating largish pixmaps. At least that's what I've seen > here with 1.0N. Purhaps that is your problem? Well, netscape seems to be the cause but I'm not sure it's the problem since I'd expect the memory to be freed when I kill it. -- 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 Mon Jul 17 04:04:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA25094 for current-outgoing; Mon, 17 Jul 1995 04:04:29 -0700 Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA25084 for ; Mon, 17 Jul 1995 04:04:25 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id KAA02988; Mon, 17 Jul 1995 10:33:18 +0100 Date: Mon, 17 Jul 1995 10:33:17 +0100 (BST) From: Doug Rabson To: Bruce Evans cc: current@freebsd.org Subject: Re: slow nfsv3 writes In-Reply-To: <199507151413.AAA23348@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk On Sun, 16 Jul 1995, Bruce Evans wrote: > The speed of writes seems to be slower for nfsv3 according to iozone: > > iozone 1 512: 9055 bytes/sec > iozone 1 8192: 113028 bytes/sec > > Read speeds are good (800K and 1000K/sec) although this may be due to > local caching (it would take too long to test a large file size at > 9055 bytes/sec :-). > > I don't know exactly what the write speeds used to be. I remember > something over 100K/sec and hoped for more. I don't remember such a > low speed for the small block size, except for a Linux client using > an unsuitable nfs block size. I don't have a FreeBSD NFSv3 server to test against (I only have one machine running current) but when I mount a v3 filesystem from an sgi, I get: iozone 1 512 63250 bytes/second for writing the file 725501 bytes/second for reading the file iozone 1 8192 372827 bytes/second for writing the file 16777216 bytes/second for reading the file It is interesting to see that the local cache appears to only work if the read size matches the filesystem blocksize (8k in this case). The 370k/sec is respectable but I would expect it to be much larger for NFSv3, for a reasonably fast server. > > Bruce > 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 17 04:15:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA25895 for current-outgoing; Mon, 17 Jul 1995 04:15:45 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA25889 ; Mon, 17 Jul 1995 04:15:42 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id UAA03075; Mon, 17 Jul 1995 20:59:01 +0930 From: Michael Smith Message-Id: <199507171129.UAA03075@genesis.atrad.adelaide.edu.au> Subject: Re: XFree86 and swap To: paul@FreeBSD.org Date: Mon, 17 Jul 1995 20:59:01 +0930 (CST) Cc: imp@village.org, rsnow@legend.txdirect.net, FreeBSD-current@FreeBSD.org In-Reply-To: <199507171036.LAA24030@server.netcraft.co.uk> from "Paul Richards" at Jul 17, 95 11:36:07 am Content-Type: text Content-Length: 1555 Sender: current-owner@FreeBSD.org Precedence: bulk Paul Richards stands accused of saying: > I seem to remember that our malloc was pretty stupid about freeing up memory > but do you mean the X server never gives back the memory it grabs? If so, > what's the reasoning? Good question. I'd hazard a guess that it's probably historical. Think about it a bit though, it's not as simple as it may seem. Consider the speed issue too. (Instant Expert Warning! 8) > When you're running lots of X clients, like netsape and xv then you're > going to use a LOT of memory in one go and if the X server never gives it > back you're in trouble. No; the process can reuse the space, it's just that under our current malloc, the memory is never returned to the system. > Well, netscape seems to be the cause but I'm not sure it's the problem since > I'd expect the memory to be freed when I kill it. The memory that netscape uses will be freed, but the memory used by the X server to manage netscapes requests isn't freed until the X server is killed. > Paul Richards, Bluebird Computer Systems. FreeBSD core team member. If you want something that will _really_ bloat your server, try 'display' from the ImageMagic package 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" - Terry Lambert [[ From owner-freebsd-current Mon Jul 17 04:32:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA26290 for current-outgoing; Mon, 17 Jul 1995 04:32:22 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA26284 ; Mon, 17 Jul 1995 04:32:19 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id MAA24214; Mon, 17 Jul 1995 12:30:55 +0100 From: Paul Richards Message-Id: <199507171130.MAA24214@server.netcraft.co.uk> Subject: Re: XFree86 and swap To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 17 Jul 1995 12:30:54 +0100 (BST) Cc: paul@FreeBSD.org, imp@village.org, rsnow@legend.txdirect.net, FreeBSD-current@FreeBSD.org In-Reply-To: <199507171129.UAA03075@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 17, 95 08:59:01 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: 1433 Sender: current-owner@FreeBSD.org Precedence: bulk In reply to Michael Smith who said > > > When you're running lots of X clients, like netsape and xv then you're > > going to use a LOT of memory in one go and if the X server never gives it > > back you're in trouble. > > No; the process can reuse the space, it's just that under our current > malloc, the memory is never returned to the system. But that's a major problem now. I guess before the days of X you never had this problem. Databases perhaps would have run permanently and accumulated memory over time but in those situations it would be more efficient to let the process keep the memory. X servers are a different, short lived clients like netscape can consume vast amounts of memory and the X server ends up owning all the systems memory, even if it spends most of its time idle. I've been running into problems. I've got a 16Mb box with 64Mb of swap. I use xdm so the server runs permanently. Every few days I have to kill X so it frees it memory because it ends up with ALL of it. I've had cron jobs die over night because of a lack of memory which isn't good at all. Sounds like the XFree86 folks are trying to address this problem in their server but it's probably time for someone to address the general malloc problem. -- 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 Mon Jul 17 05:07:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA27136 for current-outgoing; Mon, 17 Jul 1995 05:07:23 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA27129 ; Mon, 17 Jul 1995 05:07:21 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id VAA03178; Mon, 17 Jul 1995 21:51:05 +0930 From: Michael Smith Message-Id: <199507171221.VAA03178@genesis.atrad.adelaide.edu.au> Subject: Re: XFree86 and swap To: paul@FreeBSD.org Date: Mon, 17 Jul 1995 21:51:05 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, imp@village.org, rsnow@legend.txdirect.net, FreeBSD-current@FreeBSD.org In-Reply-To: <199507171130.MAA24214@server.netcraft.co.uk> from "Paul Richards" at Jul 17, 95 12:30:54 pm Content-Type: text Content-Length: 1264 Sender: current-owner@FreeBSD.org Precedence: bulk Paul Richards stands accused of saying: > I've been running into problems. I've got a 16Mb box with 64Mb of > swap. I use xdm so the server runs permanently. Every few days I > have to kill X so it frees it memory because it ends up with ALL > of it. I've had cron jobs die over night because of a lack of > memory which isn't good at all. That sounds like a memory leak. I've grown the S3 server to 30 or 40M by _really_ punishing it (run 5 copies of xboing one day for a laugh 8), but I haven't gone much beyond that. > Sounds like the XFree86 folks are trying to address this problem in their > server but it's probably time for someone to address the general malloc > problem. This is already happening; there are several new mallocs under consideration, at a guess I'd say you'll see the winer in 2.2 > Paul Richards, Bluebird Computer Systems. FreeBSD core team member. -- ]] 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 17 05:08:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA27181 for current-outgoing; Mon, 17 Jul 1995 05:08:36 -0700 Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA27174 for ; Mon, 17 Jul 1995 05:08:28 -0700 Received: by FileServ1.MI.Uni-Koeln.DE id AA19945 (5.67b/IDA-1.5 for current@freebsd.org); Mon, 17 Jul 1995 14:05:35 +0200 Message-Id: <199507171205.AA19945@FileServ1.MI.Uni-Koeln.DE> From: esser@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 17 Jul 1995 14:05:34 +0200 In-Reply-To: Doug Rabson "Re: slow nfsv3 writes" (Jul 17, 10:33) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Doug Rabson Subject: Re: slow nfsv3 writes Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk On Jul 17, 10:33, Doug Rabson wrote: } Subject: Re: slow nfsv3 writes } On Sun, 16 Jul 1995, Bruce Evans wrote: } The 370k/sec is respectable but I would expect it to be much larger for } NFSv3, for a reasonably fast server. This is NFSv2, a 486DX2/66 (16MB RAM, DEC 21040 PCI Ethernet), the server is a SparcServer 1000 running Solaris 2.4, measured when the NFSv3 patches had just been integrated: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU SP3G 20 577 35.3 579 4.5 356 7.5 874 58.6 985 10.4 53.4 16.1 Seems that near 600KB/s writes were still possible at that time. I'll try a few more test runs against this and other servers later ... 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 Mon Jul 17 05:40:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA28383 for current-outgoing; Mon, 17 Jul 1995 05:40:33 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA28377 for ; Mon, 17 Jul 1995 05:40:31 -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 FAA15687 for ; Mon, 17 Jul 1995 05:35:54 -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 NAA00324; Mon, 17 Jul 1995 13:15:19 +0200 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id NAA27472; Mon, 17 Jul 1995 13:15:07 +0200 Date: Mon, 17 Jul 1995 13:15:07 +0200 Message-Id: <199507171115.NAA27472@caramba.cs.tu-berlin.de> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) CC: current@freebsd.org Subject: Re: multilingual cal(1) In-Reply-To: <199507160919.LAA17170@uriah.heep.sax.de> References: <199507152210.AAA04109@caramba.cs.tu-berlin.de> <199507160919.LAA17170@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: current-owner@freebsd.org Precedence: bulk J. Wunsch writes: >As Wolfram Schneider wrote: >> >> >> >> Support month names and weekdays for english, german, austrian and >> french. > >Hmm, shouldn't this better be handled by a proper locale implementat- >ion instead (including external message files for the application- >dependant part that's not being covered by e.g. ctime(3))? Sure. But I think we need a new function, which return the names. Eg: asctime_name(MON_NAME_LONG, 0) -> 'Januar' asctime_name(MON_NAME_SHORT, 0) -> 'Jan' asctime_name(WDAY_NAME_LONG, 6) -> 'Saturday' asctime_name(WDAY_NAME_SHORT, 6) -> 'Sat' Wolfram [Solaris 2.x] $ for i in /usr/lib/locale/*/LC_TIME/time;do echo "$i:" ;cat $i;done /usr/lib/locale/C/LC_TIME/time: Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec January February March April May June July August September October November December Sun Mon Tue Wed Thu Fri Sat Sunday Monday Tuesday Wednesday Thursday Friday Saturday %H:%M:%S %m/%d/%y %a %b %d %H:%M:%S %Y AM PM %a %b %e %T %Z %Y /usr/lib/locale/POSIX/LC_TIME/time: Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec January February March April May June July August September October November December Sun Mon Tue Wed Thu Fri Sat Sunday Monday Tuesday Wednesday Thursday Friday Saturday %H:%M:%S %m/%d/%y %a %b %d %H:%M:%S %Y AM PM %a %b %e %T %Z %Y /usr/lib/locale/de/LC_TIME/time: Jan Feb Mär Apr Mai Jun Jul Aug Sep Okt Nov Dez Januar Februar März April Mai Juni Juli August September Oktober November Dezember So Mo Di Mi Do Fr Sa Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag %H:%M:%S %d.%m.%y %a %e %b %y, %T %Z AM PM %A, %e. %B %Y, %T Uhr %Z /usr/lib/locale/en_US/LC_TIME/time: Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec January February March April May June July August September October November December Sun Mon Tue Wed Thu Fri Sat Sunday Monday Tuesday Wednesday Thursday Friday Saturday %H:%M:%S %m/%d/%y %a %b %d %H:%M:%S %Y AM PM %a %b %e %T %Z %Y /usr/lib/locale/es/LC_TIME/time: Ene Feb Mar Abr May Jun Jul Ago Sep Oct Nov Dic Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Dom Lun Mar Mie Jue Vie Sab Domingo Lunes Martes Miércoles Jueves Viernes Sabado %H:%M:%S %d/%m/%y %a %d/%b/%y %H:%M:%S AM PM %A, %e de %B de %Y, %T %Z /usr/lib/locale/fr/LC_TIME/time: jan fév mar avr mai juin juil août sep oct nov déc janvier février mars avril mai juin juillet août septembre octobre novembre décembre dim lun mar mer jeu ven sam dimanche lundi mardi mercredi jeudi vendredi samedi %H:%M:%S %d.%m.%y %a %e %b %y, %T %Z AM PM %A, %e %B %Y, %T %Z /usr/lib/locale/it/LC_TIME/time: gen feb mar apr mag giu lug ago set ott nov dic gennaio febbraio marzo aprile maggio giugno luglio agosto settembre ottobre novembre dicembre Dom Lun Mar Mer Gio Ven Sab domenica lunedì martedì mercoledì giovedì venerdì sabato %H:%M:%S %d/%m/%y %a %e %b %y, %T %Z AM PM %A, %e %B %Y, %T %Z /usr/lib/locale/sv/LC_TIME/time: jan feb mar apr maj jun jul aug sep okt nov dec januari februari mars april maj juni juli augusti september oktober november december sön mån tis ons tor fre lör söndag måndag tisdag onsdag torsdag fredag lördag %H:%M:%S %y-%m-%d %a %e %b %y kl %T %Z FM EM %A, %e %B %Y kl %T %Z From owner-freebsd-current Mon Jul 17 08:08:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA04501 for current-outgoing; Mon, 17 Jul 1995 08:08:28 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA04492 for ; Mon, 17 Jul 1995 08:08:24 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA25389; Mon, 17 Jul 1995 11:07:45 -0400 Date: Mon, 17 Jul 1995 11:07:45 -0400 From: Garrett Wollman Message-Id: <9507171507.AA25389@halloran-eldar.lcs.mit.edu> To: Wolfram Schneider Cc: current@freebsd.org Subject: Re: multilingual cal(1) In-Reply-To: <199507171115.NAA27472@caramba.cs.tu-berlin.de> References: <199507152210.AAA04109@caramba.cs.tu-berlin.de> <199507160919.LAA17170@uriah.heep.sax.de> <199507171115.NAA27472@caramba.cs.tu-berlin.de> Sender: current-owner@freebsd.org Precedence: bulk < said: >> Hmm, shouldn't this better be handled by a proper locale implementat- >> ion instead (including external message files for the application- >> dependant part that's not being covered by e.g. ctime(3))? > Sure. But I think we need a new function, which return the names. There was posted a multilingual version of strftime() on the `tz' mailing list about a year ago. You can probably find it on elsie.nci.nih.gov somewhere. -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 17 08:10:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA04656 for current-outgoing; Mon, 17 Jul 1995 08:10:47 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA04649 for ; Mon, 17 Jul 1995 08:10:41 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA25395; Mon, 17 Jul 1995 11:10:05 -0400 Date: Mon, 17 Jul 1995 11:10:05 -0400 From: Garrett Wollman Message-Id: <9507171510.AA25395@halloran-eldar.lcs.mit.edu> To: roberto@keltia.freenix.fr (Ollivier Robert) Cc: freebsd-current@freebsd.org (FreeBSD Current Users' list) Subject: About ed0 problem and big Ierrs numbers In-Reply-To: <199507160955.LAA08017@keltia.frmug.fr.net> References: <199507160955.LAA08017@keltia.frmug.fr.net> Sender: current-owner@freebsd.org Precedence: bulk < said: > Does it mean something to anybody ? A 4096 bytes window seems very small to > me... What is the output of `route get name.of.problem.host'? The TCP receive window size is determined by the value of the `recvpipe' metric, or the `tcp_sendspace' kernel variable if the former is zero. -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 17 08:19:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA05240 for current-outgoing; Mon, 17 Jul 1995 08:19:41 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA05231 for ; Mon, 17 Jul 1995 08:19:35 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA25423; Mon, 17 Jul 1995 11:19:14 -0400 Date: Mon, 17 Jul 1995 11:19:14 -0400 From: Garrett Wollman Message-Id: <9507171519.AA25423@halloran-eldar.lcs.mit.edu> To: "Jonathan M. Bresler" Cc: current@freebsd.org Subject: point-to-point links require destination addr In-Reply-To: References: Sender: current-owner@freebsd.org Precedence: bulk < said: > in 2.0.5 and later, point-to-point links, lp0 and sl0 (have not tried > ppp0) require a destination address in the ifconfig line. > this was not the case previously. Yes. This change was made to avoid a lot of special-case code which otherwise would have had to go to great lengths to ensure that the all-zeros address did not end up as the destination of a route, which makes a mess of the routing table. I decided that it was a lot easier to simply make this particular configuration error an error rather than attempting to work around it. > if the destination is omitted 'ifconfig sl0 inet 111.222.333.444' > EADDRNOTAVAIL 'Can't assign requested address' is returned. > can this be changed to > EDESTADDRREQ 'Destination address required' Sure can, and just did. If I had noticed that one when I looked in sys_err.c for the appropriate error to return, I would have used it :-) . -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Mon Jul 17 09:09:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA06805 for current-outgoing; Mon, 17 Jul 1995 09:09:29 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA06795 ; Mon, 17 Jul 1995 09:09:18 -0700 Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id KAA06371; Mon, 17 Jul 1995 10:08:56 -0600 Message-Id: <199507171608.KAA06371@rover.village.org> To: paul@FreeBSD.org Subject: Re: XFree86 and swap Cc: rsnow@legend.txdirect.net, FreeBSD-current@FreeBSD.org In-reply-to: Your message of Mon, 17 Jul 1995 11:36:07 BST Date: Mon, 17 Jul 1995 10:08:56 -0600 From: Warner Losh Sender: current-owner@FreeBSD.org Precedence: bulk : I seem to remember that our malloc was pretty stupid about freeing up memory : but do you mean the X server never gives back the memory it grabs? If so, : what's the reasoning? : : When you're running lots of X clients, like netsape and xv then you're : going to use a LOT of memory in one go and if the X server never gives it : back you're in trouble. Most of the older X servers will not give memory back to the system, or are ineffective in doing so. This is especially true when you have boatloads of pixmaps that are of strange sizes (larger than 16x16 or so). At least that is what I've seen in using the X server on my FreeBSD box over the last couple of releases of XFree86. They may have corrected this problem more recently. : > : > Also, netscape (at least in some versions) eats huge amounts of server : > resources by creating largish pixmaps. At least that's what I've seen : > here with 1.0N. Purhaps that is your problem? : : Well, netscape seems to be the cause but I'm not sure it's the problem since : I'd expect the memory to be freed when I kill it. Hmm, if I'm a client, then I allocated 10M in the server for pixmaps, then someone else needs to allocate n bytes, and then I free the 10M, then the X server will still appear to be using that 10M of memory, even though it has internally marked it as free. I think that's what you are seeing. I know that OI apps did this from time to time. It is also possible, though unlikely, that there is some resource allocation that isn't completely free'd when you are done with it in the X server. For an R3-R4 server, this is likely. For newer ones (like R6), it is much less likely because Purify and other memory tools hit the streets long enough ago to make an impact in these areas. Warner From owner-freebsd-current Mon Jul 17 09:12:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA06888 for current-outgoing; Mon, 17 Jul 1995 09:12:13 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA06874 for ; Mon, 17 Jul 1995 09:12:04 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id RAA00454 for FreeBSD-current@FreeBSD.org; Mon, 17 Jul 1995 17:11:21 +0100 From: Paul Richards Message-Id: <199507171611.RAA00454@server.netcraft.co.uk> Subject: scsi problems To: FreeBSD-current@FreeBSD.org (FreeBSD current mailing list) Date: Mon, 17 Jul 1995 17:11:20 +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: 939 Sender: current-owner@FreeBSD.org Precedence: bulk Quick config question first: How do I get rid of this, can't find any info on the correct syntax for the config file. Warning: sd0 is configured at scbus0 which is not fixed at a single adapter. Now the real problem: I can't use any tape devices (a HP DAT mainly), if I try to write to it I get (I don't think it's specific to writes though) sd0(aha0:0:0): timed out adapter not taking commands.. frozen?! Debugger("aha1542") Now, problem is I can't get a crash dump to go looking through since the scsi adapter's frozen and I'm not familiar enough with the scsi code to look at structures in ddb, so, can someone help. Only tapes cause this problem, there's a Barracuda and Toshiba cdrom on the scsi chain too and neither cause any problems. -- 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 Mon Jul 17 10:11:58 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA10948 for current-outgoing; Mon, 17 Jul 1995 10:11:58 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA10941 ; Mon, 17 Jul 1995 10:11:53 -0700 Received: (dufault@localhost) by hda.com (8.6.11/8.3) id NAA11366; Mon, 17 Jul 1995 13:12:58 -0400 From: Peter Dufault Message-Id: <199507171712.NAA11366@hda.com> Subject: Re: scsi problems To: paul@FreeBSD.org Date: Mon, 17 Jul 1995 13:12:58 -0400 (EDT) Cc: FreeBSD-current@FreeBSD.org In-Reply-To: <199507171611.RAA00454@server.netcraft.co.uk> from "Paul Richards" at Jul 17, 95 05:11:20 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1231 Sender: current-owner@FreeBSD.org Precedence: bulk Paul Richards writes: > > Quick config question first: > > How do I get rid of this, can't find any info on the correct > syntax for the config file. > > Warning: sd0 is configured at scbus0 which is not fixed at a single adapter. This should be in "man 4 scsi" but isn't. The LINT kernel has some examples. It is: > controller scbus0 at aha0 where "aha?" is which board you want it wired at. > Now the real problem: > > I can't use any tape devices (a HP DAT mainly), if I try to write to > it I get (I don't think it's specific to writes though) > > sd0(aha0:0:0): timed out > adapter not taking commands.. frozen?! > Debugger("aha1542") Do you have any problems with tape transfers before this happens? This is what happens when the bus jams - the adaptec driver tries to abort the transaction (apparently the disk transaction in this case), and when it times out again it finds that the mailbox still has the ABORT command in it. At that point it assumes all is lost, and panics. Is the tape the only external device or anything else unusual? -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-current Mon Jul 17 10:30:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA12239 for current-outgoing; Mon, 17 Jul 1995 10:30:52 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA12229 ; Mon, 17 Jul 1995 10:30:50 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id SAA01309; Mon, 17 Jul 1995 18:30:04 +0100 From: Paul Richards Message-Id: <199507171730.SAA01309@server.netcraft.co.uk> Subject: Re: scsi problems To: dufault@hda.com (Peter Dufault) Date: Mon, 17 Jul 1995 18:30:03 +0100 (BST) Cc: paul@FreeBSD.org, FreeBSD-current@FreeBSD.org In-Reply-To: <199507171712.NAA11366@hda.com> from "Peter Dufault" at Jul 17, 95 01:12:58 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: 1008 Sender: current-owner@FreeBSD.org Precedence: bulk In reply to Peter Dufault who said > > > Now the real problem: > > > > I can't use any tape devices (a HP DAT mainly), if I try to write to > > it I get (I don't think it's specific to writes though) > > > > sd0(aha0:0:0): timed out > > adapter not taking commands.. frozen?! > > Debugger("aha1542") > > Do you have any problems with tape transfers before this happens? It writes to the tape for a while (not long) and then hangs. > This is what happens when the bus jams - the adaptec driver > tries to abort the transaction (apparently the disk transaction in > this case), and when it times out again it finds that the mailbox still > has the ABORT command in it. At that point it assumes all is lost, > and panics. > > Is the tape the only external device or anything else unusual? Everything is external. -- 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 Mon Jul 17 11:01:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA13568 for current-outgoing; Mon, 17 Jul 1995 11:01:19 -0700 Received: from bigdipper.iagi.net ([198.6.14.10]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA13553 for ; Mon, 17 Jul 1995 11:01:10 -0700 Received: (from adhir@localhost) by bigdipper.iagi.net (8.6.11/8.6.9) id NAA13043; Mon, 17 Jul 1995 13:59:49 -0400 Date: Mon, 17 Jul 1995 13:59:49 -0400 (EDT) From: "Alok K. Dhir" To: David Greenman cc: Bruce Evans , current@freebsd.org Subject: Re: nfs leaves unreferenced files or blocks In-Reply-To: <199507160645.XAA00180@corbin.Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk Where can I find the fixes to vfs_bio.c and trap.c? Thanks... On Sat, 15 Jul 1995, David Greenman wrote: > >For a:/usr nfs-mounted on /usr, the space for files created, written to and > >deleted by nfs is not recovered when the files are deleted, or when a:/usr > >is unmounted. It is recovered when system `a' is rebooted. > > > >This is with -current after the nfs speed fix in vfs_bio.c and the buggy > >fix in trap.c but before the second fix to trap.c. > > Nevermind my last message; this only happens if the _server_ is running > -current (e.g. it is not a client problem). I am able to reproduce the bug > here, but I don't think it is related to any of the recent changes. I think it > is related to the NFSv3 stuff. Shouldn't be too difficult to fix. > > -DG > Alok K. Dhir Internet Access Group, Inc. adhir@iagi.net (301) 652-0484 Fax: (301) 652-0649 http://www.iagi.net From owner-freebsd-current Mon Jul 17 11:09:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA13745 for current-outgoing; Mon, 17 Jul 1995 11:09:14 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA13739 for ; Mon, 17 Jul 1995 11:09:05 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id UAA09744 ; Mon, 17 Jul 1995 20:09:00 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id UAA00859 ; Mon, 17 Jul 1995 20:08:59 +0200 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.7.Beta.9/keltia-uucp-2.2) id TAA17644; Mon, 17 Jul 1995 19:41:33 +0200 (MET DST) From: Ollivier Robert Message-Id: <199507171741.TAA17644@keltia.frmug.fr.net> Subject: Re: About ed0 problem and big Ierrs numbers To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Mon, 17 Jul 1995 19:41:32 +0200 (MET DST) Cc: freebsd-current@freebsd.org Reply-To: roberto@keltia.freenix.fr (Ollivier Robert) In-Reply-To: <9507171510.AA25395@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 17, 95 11:10:05 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: current-owner@freebsd.org Precedence: bulk It seems that Garrett Wollman said: > What is the output of `route get name.of.problem.host'? The TCP > receive window size is determined by the value of the `recvpipe' > metric, or the `tcp_sendspace' kernel variable if the former is zero. 126 [23:49] root@keltia:~# route get sidhe route to: sidhe.frmug.fr.net destination: sidhe.frmug.fr.net interface: ed0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 16384 16384 0 0 0 0 1500 1199 sidhe is a Tadpole Sparcbook 2, SunOS 4.1.3. On Keltia : net.inet.ip.forwarding = 1 net.inet.ip.redirect = 1 net.inet.ip.ttl = 64 net.inet.ip.rtexpire = 3600 net.inet.ip.rtminexpire = 10 net.inet.ip.rtmaxcache = 128 net.inet.ip.sourceroute = 0 net.inet.icmp.maskrepl = 0 net.inet.tcp.rfc1323 = 1 net.inet.tcp.rfc1644 = 1 net.inet.tcp.mssdflt = 512 net.inet.tcp.rttdflt = 3 net.inet.tcp.keepidle = 14400 net.inet.tcp.keepintvl = 150 net.inet.tcp.sendspace = 16384 net.inet.tcp.recvspace = 16384 net.inet.udp.checksum = 1 net.inet.udp.maxdgram = 9216 net.inet.udp.recvspace = 41600 -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Mon Jul 17 14:06:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA23741 for current-outgoing; Mon, 17 Jul 1995 14:06:29 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA23700 for ; Mon, 17 Jul 1995 14:06:05 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.11/8.6.9) with ESMTP id XAA01051 for ; Mon, 17 Jul 1995 23:05:19 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.11/8.6.9) with SMTP id XAA01486 for ; Mon, 17 Jul 1995 23:05:18 +0200 Message-Id: <199507172105.XAA01486@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: current@freebsd.org Subject: CDROM Drive misbehaving? Date: Mon, 17 Jul 1995 23:05:18 +0200 From: Mark Murray Sender: current-owner@freebsd.org Precedence: bulk Hi I have just got a brand new CDROM drive (SCSI-2!) and it misbehaves when I try to play music: > FreeBSD 2.2-CURRENT #0: Sat Jul 15 09:17:50 SAT 1995 > root@grumble.grondar.za:/a/src/sys/compile/G486 > CPU: i486DX (486-class CPU) > real memory = 16384000 (4000 pages) > avail memory = 14921728 (3643 pages) > Probing for devices on the ISA bus: > : > : > aha0: AHA-1542CF-V0.1, enabling mailbox, enabling residuals > aha0: reading board settings, dma=5 int=11 (bus speed defaulted) > aha0 at 0x330-0x333 irq 11 drq 5 on isa > aha0 waiting for scsi devices to settle > (aha0:0:0): "MAXTOR 7213-SCSI 0742" type 0 fixed SCSI 1 > sd0(aha0:0:0): Direct-Access 202MB (415600 512 byte sectors) > (aha0:1:0): "HP C3323-300 4269" type 0 fixed SCSI 2 > sd1(aha0:1:0): Direct-Access 1003MB (2056008 512 byte sectors) > (aha0:2:0): "ARCHIVE VIPER 150 21247 -011" type 1 removable SCSI 1 > st0(aha0:2:0): Sequential-Access st0: Archive Viper 150 is a known rogue > density code 0x0, drive empty > (aha0:6:0): "MATSHITA CD-ROM CR-503 1.0f" type 5 removable SCSI 2 > cd0(aha0:6:0): CD-ROM > cd0(aha0:6:0): NOT READY asc:3a,0 Medium not present > can't get the size > : > : This happens when I try to play an audio CD (Mounting it works OK): > cd0(aha0:6:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > cd0(aha0:6:0): UNIT ATTENTION asc:28,0 > cd0(aha0:6:0): Not ready to ready transition, medium may have changed > cd0(aha0:6:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB Any ideas what the problem may be? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Mon Jul 17 14:48:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA26458 for current-outgoing; Mon, 17 Jul 1995 14:48:59 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA26448 ; Mon, 17 Jul 1995 14:48:29 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id OAA02136; Mon, 17 Jul 1995 14:48:54 -0700 From: "Rodney W. Grimes" Message-Id: <199507172148.OAA02136@gndrsh.aac.dev.com> Subject: Re: scsi problems To: paul@FreeBSD.org Date: Mon, 17 Jul 1995 14:48:54 -0700 (PDT) Cc: FreeBSD-current@FreeBSD.org In-Reply-To: <199507171611.RAA00454@server.netcraft.co.uk> from "Paul Richards" at Jul 17, 95 05:11:20 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: 1402 Sender: current-owner@FreeBSD.org Precedence: bulk > > Quick config question first: > > How do I get rid of this, can't find any info on the correct > syntax for the config file. > > Warning: sd0 is configured at scbus0 which is not fixed at a single adapter. Justin or Peter will have to answer that one... > Now the real problem: > > I can't use any tape devices (a HP DAT mainly), if I try to write to > it I get (I don't think it's specific to writes though) > > sd0(aha0:0:0): timed out > adapter not taking commands.. frozen?! > Debugger("aha1542") In the adaptec bios setup (assuming this is a 1542C or CF) have you tried setting the DAT drive target to async only? Some tape drives get confused by sync negotiation messages and hang the scsi bus. > Now, problem is I can't get a crash dump to go looking through since the scsi > adapter's frozen and I'm not familiar enough with the scsi code to look > at structures in ddb, so, can someone help. > > Only tapes cause this problem, there's a Barracuda and Toshiba cdrom on > the scsi chain too and neither cause any problems. > > -- > 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) > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Jul 17 14:54:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA26580 for current-outgoing; Mon, 17 Jul 1995 14:54:03 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA26552 ; Mon, 17 Jul 1995 14:53:33 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id OAA02168; Mon, 17 Jul 1995 14:53:57 -0700 From: "Rodney W. Grimes" Message-Id: <199507172153.OAA02168@gndrsh.aac.dev.com> Subject: Re: scsi problems To: paul@FreeBSD.org Date: Mon, 17 Jul 1995 14:53:57 -0700 (PDT) Cc: dufault@hda.com, FreeBSD-current@FreeBSD.org In-Reply-To: <199507171730.SAA01309@server.netcraft.co.uk> from "Paul Richards" at Jul 17, 95 06:30:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1322 Sender: current-owner@FreeBSD.org Precedence: bulk > > In reply to Peter Dufault who said > > > > > Now the real problem: > > > > > > I can't use any tape devices (a HP DAT mainly), if I try to write to > > > it I get (I don't think it's specific to writes though) > > > > > > sd0(aha0:0:0): timed out > > > adapter not taking commands.. frozen?! > > > Debugger("aha1542") > > > > Do you have any problems with tape transfers before this happens? > > It writes to the tape for a while (not long) and then hangs. Never mind my sync point then, if you can get this far it is not that! > > This is what happens when the bus jams - the adaptec driver > > tries to abort the transaction (apparently the disk transaction in > > this case), and when it times out again it finds that the mailbox still > > has the ABORT command in it. At that point it assumes all is lost, > > and panics. > > > > Is the tape the only external device or anything else unusual? > > Everything is external. I know you've heard this a hundred times, but, do you have the terminators installed and enabled on the 1542? And are your scsi cables double shielded SCSI-ii rated (meaning there should be about 1/2" in diameter, not 3/8")? -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Jul 17 16:39:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA00549 for current-outgoing; Mon, 17 Jul 1995 16:39:54 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA00543 for ; Mon, 17 Jul 1995 16:39:53 -0700 Message-Id: <199507172339.QAA00543@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: current@freefall.cdrom.com Subject: YOU MUST REBUILD CONFIG Date: Mon, 17 Jul 1995 16:39:52 -0700 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk I've just committed the changes that allow hardwiring scsi busses on controllers with more than one bus. You will need to rebuild config before a -current kernel build will succeed. __ Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Jul 17 23:49:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA12882 for current-outgoing; Mon, 17 Jul 1995 23:49:43 -0700 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA12872 for ; Mon, 17 Jul 1995 23:49:37 -0700 Received: (from news@localhost) by haywire.DIALix.COM (8.6.12/8.6.12/DIALix) id OAA20691 for freebsd-current@freebsd.org; Tue, 18 Jul 1995 14:49:02 +0800 Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 18 Jul 1995 14:48:58 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <3uflgq$k6f$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199507160955.LAA08017@keltia.frmug.fr.net> Subject: Re: About ed0 problem and big Ierrs numbers Sender: current-owner@freebsd.org Precedence: bulk roberto@keltia.frmug.fr.net (Ollivier Robert) writes: >I've run tcpdump during a FTP from my sparcbook to my PC (SMC8013EP, >-current as of friday). I keep on getting bad numbers in netstat -i : [...] >10:50:20.486375 sidhe.frmug.fr.net.20 > keltia.frmug.fr.net.1089: . 1150389:1151849(1460) ack 1 win 4096 >10:50:20.486972 keltia.frmug.fr.net.1089 > sidhe.frmug.fr.net.20: . ack 1151849 win 17520 >Does it mean something to anybody ? A 4096 bytes window seems very small to >me... Yup. Solaris has a 4096 byte max window... -Peter >-- >Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net > FreeBSD keltia 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Tue Jul 18 01:26:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA15539 for current-outgoing; Tue, 18 Jul 1995 01:26:31 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA15524 ; Tue, 18 Jul 1995 01:26:27 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id KAA15613 ; Tue, 18 Jul 1995 10:26:03 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id KAA03755 ; Tue, 18 Jul 1995 10:26:02 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199507180826.KAA03755@blaise.ibp.fr> Subject: Re: XFree86 and swap To: paul@freebsd.org Date: Tue, 18 Jul 1995 10:26:02 +0200 (MET DST) Cc: msmith@atrad.adelaide.edu.au, imp@village.org, rsnow@legend.txdirect.net, FreeBSD-current@freebsd.org In-Reply-To: <199507171130.MAA24214@server.netcraft.co.uk> from "Paul Richards" at Jul 17, 95 12:30:54 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 709 Sender: current-owner@freebsd.org Precedence: bulk > Sounds like the XFree86 folks are trying to address this problem in their > server but it's probably time for someone to address the general malloc > problem. I've recompiled most of /bin and /sbin with dlmalloc (and I have a libc.so with it). Everything is working except that sh dumps core when I run my .xinitrc The line is pretty std : xterm -fn ... -g ... -title -e tail -f /var/spool/uucp/Log & I guess sh is freeing something already freed but it is weird that it happens only in .xinitrc. If I launch the line at the shell (tcsh) it does not core dump. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Tue Jul 18 01:40:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA16150 for current-outgoing; Tue, 18 Jul 1995 01:40:43 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA16142 for ; Tue, 18 Jul 1995 01:40:37 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id KAA15742 ; Tue, 18 Jul 1995 10:40:26 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id KAA03804 ; Tue, 18 Jul 1995 10:40:20 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199507180840.KAA03804@blaise.ibp.fr> Subject: Re: XFree86 and swap To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Tue, 18 Jul 1995 10:40:19 +0200 (MET DST) Cc: davidg@Root.COM, freebsd-current@freebsd.org In-Reply-To: <199507171732.NAA02757@crh.cl.msu.edu> from "Charles Henrich" at Jul 17, 95 01:32:56 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 413 Sender: current-owner@freebsd.org Precedence: bulk > > 5 MB is "normal size" for my gnumallocified server. It is seldom around > > 7 MB. > > What resolution? Im doing 1600x1200@8bit and before was doing 1280x1024@8bit. > This is using the S3 server.. 1024x768. I am now back at my wonderful 1152x800 and still under 7 MB. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Tue Jul 18 02:02:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA17373 for current-outgoing; Tue, 18 Jul 1995 02:02:08 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA17363 for ; Tue, 18 Jul 1995 02:02:03 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id LAA16046 ; Tue, 18 Jul 1995 11:01:57 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id LAA03912 ; Tue, 18 Jul 1995 11:01:56 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199507180901.LAA03912@blaise.ibp.fr> Subject: Re: About ed0 problem and big Ierrs numbers To: peter@haywire.dialix.com (Peter Wemm) Date: Tue, 18 Jul 1995 11:01:56 +0200 (MET DST) Cc: freebsd-current@freebsd.org In-Reply-To: <3uflgq$k6f$1@haywire.DIALix.COM> from "Peter Wemm" at Jul 18, 95 02:48:58 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 392 Sender: current-owner@freebsd.org Precedence: bulk > Yup. Solaris has a 4096 byte max window... I don't use Solaris. Sidhe is a 4.1.3 SunOS. And the slowdown I've encountered started between 2.0R and 2.0.5R. I used to get between 400 and 600 KB/s between my two machines. The slowdown is a new thing. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Tue Jul 18 02:12:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA17728 for current-outgoing; Tue, 18 Jul 1995 02:12:43 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA17722 for ; Tue, 18 Jul 1995 02:12:40 -0700 Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id CAA16924; Tue, 18 Jul 1995 02:11:59 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id CAA00812; Tue, 18 Jul 1995 02:13:14 -0700 Message-Id: <199507180913.CAA00812@corbin.Root.COM> To: roberto@blaise.ibp.fr (Ollivier Robert) cc: peter@haywire.dialix.com (Peter Wemm), freebsd-current@freebsd.org Subject: Re: About ed0 problem and big Ierrs numbers In-reply-to: Your message of "Tue, 18 Jul 95 11:01:56 +0200." <199507180901.LAA03912@blaise.ibp.fr> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 18 Jul 1995 02:13:13 -0700 Sender: current-owner@freebsd.org Precedence: bulk >> Yup. Solaris has a 4096 byte max window... > >I don't use Solaris. Sidhe is a 4.1.3 SunOS. And the slowdown I've >encountered started between 2.0R and 2.0.5R. I used to get between >400 and 600 KB/s between my two machines. The slowdown is a new thing. Try adding "options TCP_ACK_HACK" to your kernel config file. This restores one of my old hacks that causes TCP to ack small packets ( Message-Id: <199507181035.LAA02599@server.netcraft.co.uk> Subject: Re: scsi problems To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Tue, 18 Jul 1995 11:35:53 +0100 (BST) Cc: paul@FreeBSD.org, dufault@hda.com, FreeBSD-current@FreeBSD.org In-Reply-To: <199507172153.OAA02168@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 17, 95 02:53:57 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: 962 Sender: current-owner@FreeBSD.org Precedence: bulk In reply to Rodney W. Grimes who said > > > Everything is external. > > I know you've heard this a hundred times, but, do you have the terminators > installed and enabled on the 1542? And are your scsi cables double shielded > SCSI-ii rated (meaning there should be about 1/2" in diameter, not 3/8")? Yes, everthying's terminated correctly :-) Umm not all my cables are scsi-ii though. I'm only running the scsi bus as 5Mb/s anyway though since the ISA bus on this motherboard won't go any faster. Just for general info (and it may be the cause after all) what's the difference in the specs between a scsi-i and scsi-ii cable and when is it safe to use scsi-i and when not. I have had this setup working in the past though, since I installed off the DAT originally. -- 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 Tue Jul 18 04:10:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA20598 for current-outgoing; Tue, 18 Jul 1995 04:10:18 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA20589 ; Tue, 18 Jul 1995 04:10:15 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id EAA03940; Tue, 18 Jul 1995 04:10:42 -0700 From: "Rodney W. Grimes" Message-Id: <199507181110.EAA03940@gndrsh.aac.dev.com> Subject: Re: scsi problems To: paul@FreeBSD.org Date: Tue, 18 Jul 1995 04:10:41 -0700 (PDT) Cc: dufault@hda.com, FreeBSD-current@FreeBSD.org In-Reply-To: <199507181035.LAA02599@server.netcraft.co.uk> from "Paul Richards" at Jul 18, 95 11:35:53 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2063 Sender: current-owner@FreeBSD.org Precedence: bulk > > In reply to Rodney W. Grimes who said > > > > > Everything is external. > > > > I know you've heard this a hundred times, but, do you have the terminators > > installed and enabled on the 1542? And are your scsi cables double shielded > > SCSI-ii rated (meaning there should be about 1/2" in diameter, not 3/8")? > > Yes, everthying's terminated correctly :-) :-), well, you know how it goes.. I just have to ask it... :-) > Umm not all my cables are scsi-ii though. I'm only running the scsi > bus as 5Mb/s anyway though since the ISA bus on this motherboard > won't go any faster. There is no reason to throttle a scsi bus to 5MB/sec just becuase the ISA bus is only capabile of something less. The aha1542 has a buffer on it so that the scsi bus can run wide open minimizing transfer from the drive to the controller. If you mean you set the host DMA transfer rate to 5.0MB/sec, this did not slow the scsi bus down at all, that is in the per device setup menu (if this is a 1542C or CF). If it is a 1542B forget it, that controller won't do fast scsi-ii, it maxes out at scsi-ii 5MB/sec sync. > Just for general info (and it may be the cause after all) what's the > difference in the specs between a scsi-i and scsi-ii cable and when is > it safe to use scsi-i and when not. The biggest difference in the spec is the allowed impendence of the cable. I can't recall the numbers off the top of my head, but scsi-ii narrows the range around the 110 ohm ideal value. My rule pretty much anymore is use scsi-ii cables for _anything_ doing sync scsi, along with active terminations. > I have had this setup working in the past though, since I installed > off the DAT originally. It is a rather simple thing to get good high quality cables and active termination, even if it was not the problem, at least you know that never well be the problem in the future, something I find conforting. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Jul 18 05:34:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA24449 for current-outgoing; Tue, 18 Jul 1995 05:34:38 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA24440 ; Tue, 18 Jul 1995 05:34:26 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA02801; Tue, 18 Jul 1995 13:47:03 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA20590; Tue, 18 Jul 1995 13:47:02 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id JAA09081; Tue, 18 Jul 1995 09:15:44 +0200 From: J Wunsch Message-Id: <199507180715.JAA09081@uriah.heep.sax.de> Subject: Re: scsi problems To: paul@FreeBSD.org Date: Tue, 18 Jul 1995 09:15:44 +0200 (MET DST) Cc: FreeBSD-current@FreeBSD.org In-Reply-To: <199507171611.RAA00454@server.netcraft.co.uk> from "Paul Richards" at Jul 17, 95 05:11:20 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: 282 Sender: current-owner@FreeBSD.org Precedence: bulk As Paul Richards wrote: > > Warning: sd0 is configured at scbus0 which is not fixed at a single adapter. controller scbus0 at bt0 -- 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 18 05:44:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA24849 for current-outgoing; Tue, 18 Jul 1995 05:44:14 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA24841 for ; Tue, 18 Jul 1995 05:44:09 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA01605; Tue, 18 Jul 1995 13:24:42 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA20320 for freebsd-current@freebsd.org; Tue, 18 Jul 1995 13:24:41 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA08396 for freebsd-current@freebsd.org; Tue, 18 Jul 1995 08:10:18 +0200 From: J Wunsch Message-Id: <199507180610.IAA08396@uriah.heep.sax.de> Subject: Re: Move mt(1) to /bin? To: freebsd-current@freebsd.org Date: Tue, 18 Jul 1995 08:10:18 +0200 (MET DST) Reply-To: freebsd-current@freebsd.org In-Reply-To: <199507170700.RAA22357@godzilla.zeta.org.au> from "Bruce Evans" at Jul 17, 95 05:00:50 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: 477 Sender: current-owner@freebsd.org Precedence: bulk As Bruce Evans wrote: > > It should be moved to /sbin, not to /bin. I disagree. mt(1) is not mt(8), even though some of its functionality is superuser-only. Hiding things that used to be publically visible (and /sbin is not supposed to be in every user's PATH) ain't a good idea. Anyway, this doesn't solve the actual question. -- 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 18 05:48:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA25039 for current-outgoing; Tue, 18 Jul 1995 05:48:12 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA25033 for ; Tue, 18 Jul 1995 05:48:10 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.6.11/8.6.11) with SMTP id FAA12176 for ; Tue, 18 Jul 1995 05:47:02 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA01601; Tue, 18 Jul 1995 13:24:40 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA20317 for freebsd-current@freebsd.org; Tue, 18 Jul 1995 13:24:39 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA08407 for freebsd-current@freebsd.org; Tue, 18 Jul 1995 08:14:15 +0200 From: J Wunsch Message-Id: <199507180614.IAA08407@uriah.heep.sax.de> Subject: Re: Move mt(1) to /bin? To: freebsd-current@freebsd.org Date: Tue, 18 Jul 1995 08:14:14 +0200 (MET DST) Reply-To: freebsd-current@freebsd.org In-Reply-To: <199507170854.BAA00976@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 17, 95 01:54:12 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: 828 Sender: current-owner@freebsd.org Precedence: bulk As Rodney W. Grimes wrote: > > Before you make decisions you should create formal criteria for the > reasons things belong where they belong. Binaries that are essential for system recovery, even in case there's no /usr file system available (since it's disk is dead, or it's NFS and not reachable to recover the system). This includes everything that handles potential backup media and establishing a basic network connection. (The argument is for both, /bin and /sbin here. The latter decision should be based on hier(7).) > 15 years of unix experience tell me what that list is already... and > it is not the same for any 2 sites... though there is a common subset. Agreed. -- 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 18 06:28:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA28619 for current-outgoing; Tue, 18 Jul 1995 06:28:11 -0700 Received: from elbe.desy.de (elbe.desy.de [131.169.82.208]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id GAA27423 for ; Tue, 18 Jul 1995 06:24:01 -0700 From: Lars Gerhard Kuehl Date: Tue, 18 Jul 95 13:22:00 +0200 Message-Id: <9507181122.AA05448@elbe.desy.de> To: roberto@blaise.ibp.fr Subject: Re: XFree86 and swap Cc: FreeBSD-current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk >I've recompiled most of /bin and /sbin with dlmalloc (and I have a libc.so with >it). Everything is working except that sh dumps core when I run my .xinitrc Be careful not to use dlmalloc as a standard replacement for libc malloc, it does NOT supply page aligned memory even if you malloc a multiple of NBPG. Standard malloc fits much better into the VM environment and the only programs I know which have serious problems with it are the XFree servers. LGK From owner-freebsd-current Tue Jul 18 07:27:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA14400 for current-outgoing; Tue, 18 Jul 1995 07:27:31 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA14387 for ; Tue, 18 Jul 1995 07:27:29 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA26981; Tue, 18 Jul 1995 10:20:11 -0400 Date: Tue, 18 Jul 1995 10:20:11 -0400 From: Garrett Wollman Message-Id: <9507181420.AA26981@halloran-eldar.lcs.mit.edu> To: freebsd-current@freebsd.org, joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Move mt(1) to /bin? In-Reply-To: <199507180614.IAA08407@uriah.heep.sax.de> References: <199507170854.BAA00976@gndrsh.aac.dev.com> <199507180614.IAA08407@uriah.heep.sax.de> Sender: current-owner@freebsd.org Precedence: bulk < said: >> Before you make decisions you should create formal criteria for the >> reasons things belong where they belong. > Binaries that are essential for system recovery, even in case there's > no /usr file system available (since it's disk is dead, or it's NFS > and not reachable to recover the system). This includes everything > that handles potential backup media and establishing a basic network > connection. (The argument is for both, /bin and /sbin here. The > latter decision should be based on hier(7).) This seems like a good starting point. I would also add the criterion of ``extremely frequently-used system utilities''. The rationale for including these (and it would be necessary to do some thought to figure out the precise set) is to minimize load time as much as possible. Having them be in the root partition and be statically-linked serves this goal. It turns out that almost all of these programs are also needed for system recovery; I think that the current set of /bin programs should all stay, and maybe some should be added. I don't see anything in /sbin that I would throw out immediately, either. (I note that I still have the `st' program from 1.1.5 in my /sbin...) -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 18 09:51:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA29874 for current-outgoing; Tue, 18 Jul 1995 09:51:29 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA29864 for ; Tue, 18 Jul 1995 09:51:26 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id RAA00375 for FreeBSD-current@FreeBSD.org; Tue, 18 Jul 1995 17:51:16 +0100 From: Paul Richards Message-Id: <199507181651.RAA00375@server.netcraft.co.uk> Subject: scsi problem solved To: FreeBSD-current@FreeBSD.org (FreeBSD current mailing list) Date: Tue, 18 Jul 1995 17:51:15 +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: 521 Sender: current-owner@FreeBSD.org Precedence: bulk Well, the scsi tape problem's fixed. It did turn out to be that the tape wouldn't handle sync. Thanks for the pointer Rod, maybe it should go in a FAQ somewhere. The reason it suddenly broke was someone borrowed the DAT and it came back on a different scsi id and sync was enabled for that id and not what I originally had it on. -- 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 Tue Jul 18 10:59:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA02583 for current-outgoing; Tue, 18 Jul 1995 10:59:30 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA02577 ; Tue, 18 Jul 1995 10:59:26 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id KAA04933; Tue, 18 Jul 1995 10:59:51 -0700 From: "Rodney W. Grimes" Message-Id: <199507181759.KAA04933@gndrsh.aac.dev.com> Subject: Re: scsi problem solved To: paul@FreeBSD.org Date: Tue, 18 Jul 1995 10:59:51 -0700 (PDT) Cc: FreeBSD-current@FreeBSD.org In-Reply-To: <199507181651.RAA00375@server.netcraft.co.uk> from "Paul Richards" at Jul 18, 95 05:51:15 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: 1137 Sender: current-owner@FreeBSD.org Precedence: bulk > > Well, the scsi tape problem's fixed. > > It did turn out to be that the tape wouldn't handle sync. Thanks for the > pointer Rod, maybe it should go in a FAQ somewhere. > > The reason it suddenly broke was someone borrowed the DAT and it came > back on a different scsi id and sync was enabled for that id and not > what I originally had it on. Humm, this really suprizes me as the usually symptom of a device that does not understand sync when probed by the 1542 bios is a scsi bus lockup during POST in the 1542 bios. You rarely get to where you can boot the system, and I have never seen it actually transfer data when this is the cause of the problem. Really really strange, I am going to have to remeber this one!! Can you enlightenme with some details about which model of the 1542 you have (B/C/CF) and just what model dat drive this is (dmesg output would probably do for both since I think we now print the 1542 board id info, but maybe that is only for boot -v. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Jul 18 11:05:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA02878 for current-outgoing; Tue, 18 Jul 1995 11:05:09 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA02872 ; Tue, 18 Jul 1995 11:05:07 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id TAA00314; Tue, 18 Jul 1995 19:04:19 +0100 From: Paul Richards Message-Id: <199507181804.TAA00314@server.netcraft.co.uk> Subject: Re: scsi problem solved To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Tue, 18 Jul 1995 19:04:18 +0100 (BST) Cc: paul@FreeBSD.org, FreeBSD-current@FreeBSD.org In-Reply-To: <199507181759.KAA04933@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 18, 95 10:59:51 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: 1654 Sender: current-owner@FreeBSD.org Precedence: bulk In reply to Rodney W. Grimes who said > > Humm, this really suprizes me as the usually symptom of a device that > does not understand sync when probed by the 1542 bios is a scsi bus > lockup during POST in the 1542 bios. You rarely get to where you > can boot the system, and I have never seen it actually transfer data > when this is the cause of the problem. > > Really really strange, I am going to have to remeber this one!! Can > you enlightenme with some details about which model of the 1542 you > have (B/C/CF) and just what model dat drive this is (dmesg output > would probably do for both since I think we now print the 1542 board > id info, but maybe that is only for boot -v. aha0: AHA-1542CF BIOS v2.01-VE.0, enabling mailbox, enabling residuals aha0: reading board settings, dma=5 int=11 (bus speed defaulted) aha0 at 0x330-0x333 irq 11 drq 5 on isa (aha0:0:0): "SEAGATE ST15150N 0019" type 0 fixed SCSI 2 sd0(aha0:0:0): Direct-Access 4095MB (8388315 512 byte sectors) (aha0:5:0): "HP C1533A 9406" type 1 removable SCSI 2 st0(aha0:5:0): Sequential-Access density code 0x24, variable blocks, write-enabled (aha0:6:0): "TOSHIBA CD-ROM XM-3601TA 0265" type 5 removable SCSI 2 cd0(aha0:6:0): CD-ROM cd present.[307527 x 2048 byte records] I ran into more problems when I added the cdrom though and I'm now running with adpatec bios default settings, which is no scsi-ii and no sync on anything. We'll see if it survives a bit longer this time.... -- 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 Tue Jul 18 11:21:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA03330 for current-outgoing; Tue, 18 Jul 1995 11:21:28 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA03322 ; Tue, 18 Jul 1995 11:21:24 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id TAA00209; Tue, 18 Jul 1995 19:21:01 +0100 From: Paul Richards Message-Id: <199507181821.TAA00209@server.netcraft.co.uk> Subject: Re: scsi problem solved To: paul@FreeBSD.org Date: Tue, 18 Jul 1995 19:20:59 +0100 (BST) Cc: rgrimes@gndrsh.aac.dev.com, FreeBSD-current@FreeBSD.org In-Reply-To: <199507181804.TAA00314@server.netcraft.co.uk> from "Paul Richards" at Jul 18, 95 07:04:18 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: 1161 Sender: current-owner@FreeBSD.org Precedence: bulk In reply to Paul Richards who said > > aha0: AHA-1542CF BIOS v2.01-VE.0, enabling mailbox, enabling residuals > aha0: reading board settings, dma=5 int=11 (bus speed defaulted) > aha0 at 0x330-0x333 irq 11 drq 5 on isa > (aha0:0:0): "SEAGATE ST15150N 0019" type 0 fixed SCSI 2 > sd0(aha0:0:0): Direct-Access 4095MB (8388315 512 byte sectors) > (aha0:5:0): "HP C1533A 9406" type 1 removable SCSI 2 > st0(aha0:5:0): Sequential-Access density code 0x24, variable blocks, write-enabled > (aha0:6:0): "TOSHIBA CD-ROM XM-3601TA 0265" type 5 removable SCSI 2 > cd0(aha0:6:0): CD-ROM cd present.[307527 x 2048 byte records] > > I ran into more problems when I added the cdrom though and I'm now running > with adpatec bios default settings, which is no scsi-ii and no sync on > anything. We'll see if it survives a bit longer this time.... > Well, it didn't. Same problem, hung bus. It's working fine with just the disk and tape though, it's running a backup as I do this. -- 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 Tue Jul 18 11:24:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA03598 for current-outgoing; Tue, 18 Jul 1995 11:24:13 -0700 Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA03591 ; Tue, 18 Jul 1995 11:24:09 -0700 Received: by FileServ1.MI.Uni-Koeln.DE id AA19991 (5.67b/IDA-1.5); Tue, 18 Jul 1995 20:23:26 +0200 Message-Id: <199507181823.AA19991@FileServ1.MI.Uni-Koeln.DE> From: esser@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 18 Jul 1995 20:23:26 +0200 In-Reply-To: Paul Richards "Re: scsi problem solved" (Jul 18, 19:04) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: paul@FreeBSD.org Subject: Re: scsi problem solved Cc: FreeBSD-current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk On Jul 18, 19:04, Paul Richards wrote: } Subject: Re: scsi problem solved } > Really really strange, I am going to have to remeber this one!! Can } > you enlightenme with some details about which model of the 1542 you } > have (B/C/CF) and just what model dat drive this is (dmesg output } > would probably do for both since I think we now print the 1542 board } > id info, but maybe that is only for boot -v. } } aha0: AHA-1542CF BIOS v2.01-VE.0, enabling mailbox, enabling residuals } aha0: reading board settings, dma=5 int=11 (bus speed defaulted) } aha0 at 0x330-0x333 irq 11 drq 5 on isa } (aha0:0:0): "SEAGATE ST15150N 0019" type 0 fixed SCSI 2 } sd0(aha0:0:0): Direct-Access 4095MB (8388315 512 byte sectors) } (aha0:5:0): "HP C1533A 9406" type 1 removable SCSI 2 } st0(aha0:5:0): Sequential-Access density code 0x24, variable blocks, write-enabled } (aha0:6:0): "TOSHIBA CD-ROM XM-3601TA 0265" type 5 removable SCSI 2 } cd0(aha0:6:0): CD-ROM cd present.[307527 x 2048 byte records] } } I ran into more problems when I added the cdrom though and I'm now running } with adpatec bios default settings, which is no scsi-ii and no sync on } anything. We'll see if it survives a bit longer this time.... All your devices (Seagate ST15150N, HP C1533A and Toshiba 3601) support FAST synchronous transfers. I'm using a HP 1533 DAT myself, and though the documentation mentions a max. synch. transfer rate of 7.5MB/s, it successfully negotiates 10MB/s and has always worked flawlessly in my system ... Regards, 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 Tue Jul 18 12:14:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA07307 for current-outgoing; Tue, 18 Jul 1995 12:14:42 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA07294 ; Tue, 18 Jul 1995 12:14:37 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id MAA05141; Tue, 18 Jul 1995 12:15:02 -0700 From: "Rodney W. Grimes" Message-Id: <199507181915.MAA05141@gndrsh.aac.dev.com> Subject: Re: scsi problem solved To: paul@FreeBSD.org Date: Tue, 18 Jul 1995 12:15:01 -0700 (PDT) Cc: FreeBSD-current@FreeBSD.org In-Reply-To: <199507181804.TAA00314@server.netcraft.co.uk> from "Paul Richards" at Jul 18, 95 07:04:18 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: 3622 Sender: current-owner@FreeBSD.org Precedence: bulk > > In reply to Rodney W. Grimes who said > > > > Humm, this really suprizes me as the usually symptom of a device that > > does not understand sync when probed by the 1542 bios is a scsi bus > > lockup during POST in the 1542 bios. You rarely get to where you > > can boot the system, and I have never seen it actually transfer data > > when this is the cause of the problem. > > > > Really really strange, I am going to have to remeber this one!! Can > > you enlightenme with some details about which model of the 1542 you > > have (B/C/CF) and just what model dat drive this is (dmesg output > > would probably do for both since I think we now print the 1542 board > > id info, but maybe that is only for boot -v. > > aha0: AHA-1542CF BIOS v2.01-VE.0, enabling mailbox, enabling residuals > aha0: reading board settings, dma=5 int=11 (bus speed defaulted) > aha0 at 0x330-0x333 irq 11 drq 5 on isa > (aha0:0:0): "SEAGATE ST15150N 0019" type 0 fixed SCSI 2 > sd0(aha0:0:0): Direct-Access 4095MB (8388315 512 byte sectors) > (aha0:5:0): "HP C1533A 9406" type 1 removable SCSI 2 > st0(aha0:5:0): Sequential-Access density code 0x24, variable blocks, write-enabled > (aha0:6:0): "TOSHIBA CD-ROM XM-3601TA 0265" type 5 removable SCSI 2 > cd0(aha0:6:0): CD-ROM cd present.[307527 x 2048 byte records] Hummm okay, that is really strange, every thing there is claiming scsi 2 compliancy yet it has problems with sync :-(. This is really starting to smell of cable and termination (I know, we have been down that road :-(). > I ran into more problems when I added the cdrom though and I'm now running > with adpatec bios default settings, which is no scsi-ii and no sync on > anything. We'll see if it survives a bit longer this time.... Ahh.. longer chain.. okay.. just for my enjoyment (:-)), what is switch 1 set to on the aha1542CF? I remeber you saying all your devices are external. Well, I have heard that sometimes the software termination enable just does not work quite right on some 1542CF's. Turn switch 1 on which hardwires the terminators on the board to the on possition and ignores the sofware setting. I also suspect that the 3601TA was added to the end of this chain, and am pretty sure that it uses passive 220/330 ohm termination, try switching the order of things so that your ST15150N which should have active terminations is the last drive in the chain. Also from the aha2940 cheat sheet make sure your total scsi cable length is 3 meters (9.8 feet) or under (this is the fast scsi-ii recomendation, they say 6 meters for scsi-i, but we want to be as safe as possible here in trying to find the problem). Also that is a 1542CF, which is known to have some very fast edges on the scsi bus drivers and really wants to have scsi-ii double shielded 110 ohm cables to work reliably. Anything less is asking for trouble with it :-(. You can take the exact same working setup that is totally within spec running on a 1542B and plug it into a 1542CF and have it give you royal fits until you upgrade the cables even if everything is running at 3MB/sec scsi-i async speeds :-(). First time I saw this problem was at WC when we upgraded the controller for the cdrom burner from an ancient 1542 that died to a 1542CF, it proceded to destroy 5 or 6 attempts at one off mastering before I finally replaced the external 1 meter (really a 3 footer) old scsi-i cable with a really nice scsi-ii double shielded job, then it purred like a kitten. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Jul 18 12:21:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA08002 for current-outgoing; Tue, 18 Jul 1995 12:21:00 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA07991 ; Tue, 18 Jul 1995 12:20:53 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id MAA05247; Tue, 18 Jul 1995 12:21:11 -0700 From: "Rodney W. Grimes" Message-Id: <199507181921.MAA05247@gndrsh.aac.dev.com> Subject: Re: scsi problem solved To: paul@FreeBSD.org Date: Tue, 18 Jul 1995 12:21:11 -0700 (PDT) Cc: FreeBSD-current@FreeBSD.org In-Reply-To: <199507181821.TAA00209@server.netcraft.co.uk> from "Paul Richards" at Jul 18, 95 07:20:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1557 Sender: current-owner@FreeBSD.org Precedence: bulk > > In reply to Paul Richards who said > > > > aha0: AHA-1542CF BIOS v2.01-VE.0, enabling mailbox, enabling residuals > > aha0: reading board settings, dma=5 int=11 (bus speed defaulted) > > aha0 at 0x330-0x333 irq 11 drq 5 on isa > > (aha0:0:0): "SEAGATE ST15150N 0019" type 0 fixed SCSI 2 > > sd0(aha0:0:0): Direct-Access 4095MB (8388315 512 byte sectors) > > (aha0:5:0): "HP C1533A 9406" type 1 removable SCSI 2 > > st0(aha0:5:0): Sequential-Access density code 0x24, variable blocks, write-enabled > > (aha0:6:0): "TOSHIBA CD-ROM XM-3601TA 0265" type 5 removable SCSI 2 > > cd0(aha0:6:0): CD-ROM cd present.[307527 x 2048 byte records] > > > > I ran into more problems when I added the cdrom though and I'm now running > > with adpatec bios default settings, which is no scsi-ii and no sync on > > anything. We'll see if it survives a bit longer this time.... > > > > Well, it didn't. Same problem, hung bus. :-(. > > It's working fine with just the disk and tape though, it's running a > backup as I do this. See my other email for more things to try (please bare with me on this, I am asking you to be my hands and eyes and having you do just what I would be doing if I was sitting here working on your machine.) Working slighly blind and with your fingers stuffed through a phone line is rather hard, but given the slow carefull process of elimination we will find the problem :-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Jul 18 12:30:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA08976 for current-outgoing; Tue, 18 Jul 1995 12:30:47 -0700 Received: from iworks.InterWorks.org (iworks.interworks.org [128.255.18.10]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA08970 ; Tue, 18 Jul 1995 12:30:46 -0700 Received: by iworks.InterWorks.org (1.37.109.8/16.2) id AA09967; Tue, 18 Jul 1995 14:25:29 -0500 Message-Id: <9507181925.AA09967@iworks.InterWorks.org> Date: Tue, 18 Jul 1995 14:25:29 -0500 From: "Daniel M. Eischen" To: FreeBSD-current@FreeBSD.org, paul@FreeBSD.org, rgrimes@gndrsh.aac.dev.com Subject: Re: scsi problem solved Sender: current-owner@FreeBSD.org Precedence: bulk >aha0: AHA-1542CF BIOS v2.01-VE.0, enabling mailbox, enabling residuals >aha0: reading board settings, dma=5 int=11 (bus speed defaulted) >aha0 at 0x330-0x333 irq 11 drq 5 on isa >(aha0:0:0): "SEAGATE ST15150N 0019" type 0 fixed SCSI 2 >sd0(aha0:0:0): Direct-Access 4095MB (8388315 512 byte sectors) >(aha0:5:0): "HP C1533A 9406" type 1 removable SCSI 2 >st0(aha0:5:0): Sequential-Access density code 0x24, variable blocks, write-enabled >(aha0:6:0): "TOSHIBA CD-ROM XM-3601TA 0265" type 5 removable SCSI 2 >cd0(aha0:6:0): CD-ROM cd present.[307527 x 2048 byte records] > >I ran into more problems when I added the cdrom though and I'm now running >with adpatec bios default settings, which is no scsi-ii and no sync on >anything. We'll see if it survives a bit longer this time.... > >-- > 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) Funny, I have an HP C1533A DAT tape drive also. I'm not at home right now, but I could swear that my DAT drive negotiates synchronous data transfers at 5.0MB/sec. I'm using a 2940W and definitely have synch enabled in Adaptec BIOS. I'm running 2.0.5R. I've never had a problem with my tape drive with synch enabled. I've also run some pretty intensive tests on my two hard drives, CD-ROM, and the DAT drive without problems. Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-current Tue Jul 18 14:25:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA15613 for current-outgoing; Tue, 18 Jul 1995 14:25:28 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA15595 for ; Tue, 18 Jul 1995 14:25:18 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA25447; Wed, 19 Jul 1995 07:23:41 +1000 Date: Wed, 19 Jul 1995 07:23:41 +1000 From: Bruce Evans Message-Id: <199507182123.HAA25447@godzilla.zeta.org.au> To: dfr@render.com, esser@zpr.uni-koeln.de Subject: Re: slow nfsv3 writes Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >This is NFSv2, a 486DX2/66 (16MB RAM, DEC 21040 PCI Ethernet), >the server is a SparcServer 1000 running Solaris 2.4, measured >when the NFSv3 patches had just been integrated: And for -current on a slow 486DX2/66 (16MB RAM, _loopback_): > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- >Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU >SP3G 20 577 35.3 579 4.5 356 7.5 874 58.6 985 10.4 53.4 16.1 >Noname 1 111 8.8 132 3.8 140 7.1 964 76.8 9417 99.3 175.8 26.8 All combinations of interface, benchmark and benchmark block size that I tried give about 100K/sec writes and 900K/sec reads. The disk on the server is on constantly. Bruce From owner-freebsd-current Tue Jul 18 18:24:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id SAA26834 for current-outgoing; Tue, 18 Jul 1995 18:24:50 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id SAA26822 ; Tue, 18 Jul 1995 18:24:47 -0700 Received: (dufault@localhost) by hda.com (8.6.11/8.3) id VAA00380; Tue, 18 Jul 1995 21:25:46 -0400 From: Peter Dufault Message-Id: <199507190125.VAA00380@hda.com> Subject: Re: scsi problem solved To: paul@freebsd.org Date: Tue, 18 Jul 1995 21:25:46 -0400 (EDT) Cc: rgrimes@gndrsh.aac.dev.com, FreeBSD-current@freebsd.org In-Reply-To: <199507181821.TAA00209@server.netcraft.co.uk> from "Paul Richards" at Jul 18, 95 07:20:59 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 516 Sender: current-owner@freebsd.org Precedence: bulk Paul Richards writes: > > Well, it didn't. Same problem, hung bus. > > It's working fine with just the disk and tape though, it's running a > backup as I do this. Paul, this is really starting to smell like cables. It is time to go to the known SCSI-II cables and active termination. Didn't you say you weren't sure they were all SCSI-II? -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-current Tue Jul 18 19:16:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id TAA28976 for current-outgoing; Tue, 18 Jul 1995 19:16:45 -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 TAA28970 ; Tue, 18 Jul 1995 19:16:40 -0700 Received: (robin@localhost) by intercore.com (8.6.9/8.6.4) id WAA19628; Tue, 18 Jul 1995 22:12:32 -0400 From: Robin Cutshaw Message-Id: <199507190212.WAA19628@intercore.com> Subject: Re: scsi problem solved To: paul@FreeBSD.org Date: Tue, 18 Jul 1995 22:12:31 -0400 (EDT) Cc: FreeBSD-current@FreeBSD.org In-Reply-To: <199507181651.RAA00375@server.netcraft.co.uk> from "Paul Richards" at Jul 18, 95 05:51:15 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: 294 Sender: current-owner@FreeBSD.org Precedence: bulk > > Well, the scsi tape problem's fixed. > > It did turn out to be that the tape wouldn't handle sync. Thanks for the > pointer Rod, maybe it should go in a FAQ somewhere. > I've had to turn off disconnect for some HP 4mm DAT drives using BusLogic 946C scsi controllers. Just a FYI, robin From owner-freebsd-current Tue Jul 18 20:31:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id UAA00904 for current-outgoing; Tue, 18 Jul 1995 20:31:28 -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 UAA00898 ; Tue, 18 Jul 1995 20:31:22 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id UAA06086; Tue, 18 Jul 1995 20:31:30 -0700 From: "Rodney W. Grimes" Message-Id: <199507190331.UAA06086@gndrsh.aac.dev.com> Subject: Re: scsi problem solved To: dufault@hda.com (Peter Dufault) Date: Tue, 18 Jul 1995 20:31:30 -0700 (PDT) Cc: paul@freebsd.org, FreeBSD-current@freebsd.org In-Reply-To: <199507190125.VAA00380@hda.com> from "Peter Dufault" at Jul 18, 95 09:25:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1179 Sender: current-owner@freebsd.org Precedence: bulk > > Paul Richards writes: > > > > > Well, it didn't. Same problem, hung bus. > > > > It's working fine with just the disk and tape though, it's running a > > backup as I do this. > > Paul, this is really starting to smell like cables. I see your getting that same odor. :-) :-) > It is time > to go to the known SCSI-II cables and active termination. Didn't you > say you weren't sure they were all SCSI-II? One more idea just came to mind that I have seen in the past. Do there happen to be any HD-50 type connectors in this chain (an HD-50 is the 0.5" pin spacing high density scsi-ii connector, not the Centronics-50 on the 1542)? If so please look at the male HD-50 connectors for signs of bent pins. If one of the ground pins is bent or broken off it smells just like a cable problem and can be very hard to track down. (Well, unless your like me and have scsi-ii cables laying all over and just do a wholesale swap to a known good set when that odor starts to get even the slightest bit noticable :-)) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Jul 19 03:25:58 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id DAA18995 for current-outgoing; Wed, 19 Jul 1995 03:25: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 DAA18943 for ; Wed, 19 Jul 1995 03:25:34 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA00299; Wed, 19 Jul 1995 12:23:11 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA01930 for freebsd-current@freebsd.org; Wed, 19 Jul 1995 12:23:10 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA12945 for freebsd-current@freebsd.org; Wed, 19 Jul 1995 08:51:48 +0200 From: J Wunsch Message-Id: <199507190651.IAA12945@uriah.heep.sax.de> Subject: Re: Move mt(1) to /bin? To: freebsd-current@freebsd.org Date: Wed, 19 Jul 1995 08:51:48 +0200 (MET DST) Reply-To: freebsd-current@freebsd.org In-Reply-To: <9507181420.AA26981@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 18, 95 10:20:11 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: 629 Sender: current-owner@freebsd.org Precedence: bulk As Garrett Wollman wrote: > > all stay, and maybe some should be added. I don't see anything in > /sbin that I would throw out immediately, either. (I note that I > still have the `st' program from 1.1.5 in my /sbin...) You can safely throw it away now. All its functionality has been merged into mt(1) about a couple of months ago (that's why i've been starting this discussion). It has been counter-intuitive to have two distinct commands that duplicated 80 % of its features. -- 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 19 04:47:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id EAA20659 for current-outgoing; Wed, 19 Jul 1995 04:47:45 -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 EAA20653 for ; Wed, 19 Jul 1995 04:47:39 -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 NAA11019; Wed, 19 Jul 1995 13:30:03 +0200 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id NAA13694; Wed, 19 Jul 1995 13:29:54 +0200 Date: Wed, 19 Jul 1995 13:29:54 +0200 Message-Id: <199507191129.NAA13694@caramba.cs.tu-berlin.de> To: Garrett Wollman Cc: current@freebsd.org Subject: Re: multilingual cal(1) In-Reply-To: <9507171507.AA25389@halloran-eldar.lcs.mit.edu> References: <199507152210.AAA04109@caramba.cs.tu-berlin.de> <199507160919.LAA17170@uriah.heep.sax.de> <199507171115.NAA27472@caramba.cs.tu-berlin.de> <9507171507.AA25389@halloran-eldar.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: current-owner@freebsd.org Precedence: bulk Garrett Wollman writes: >There was posted a multilingual version of strftime() on the `tz' >mailing list about a year ago. You can probably find it on >elsie.nci.nih.gov somewhere. Found. BTW, support FreeBSD GNU-gettext? Wolfram From owner-freebsd-current Wed Jul 19 05:12:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id FAA21271 for current-outgoing; Wed, 19 Jul 1995 05:12:16 -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 FAA21264 ; Wed, 19 Jul 1995 05:12:08 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id NAA02642; Wed, 19 Jul 1995 13:11:07 +0100 From: Paul Richards Message-Id: <199507191211.NAA02642@server.netcraft.co.uk> Subject: Re: scsi problem solved To: dufault@hda.com (Peter Dufault) Date: Wed, 19 Jul 1995 13:11:06 +0100 (BST) Cc: paul@freebsd.org, rgrimes@gndrsh.aac.dev.com, FreeBSD-current@freebsd.org In-Reply-To: <199507190125.VAA00380@hda.com> from "Peter Dufault" at Jul 18, 95 09:25:46 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: 1400 Sender: current-owner@freebsd.org Precedence: bulk In reply to Peter Dufault who said > > Paul Richards writes: > > > > > Well, it didn't. Same problem, hung bus. > > > > It's working fine with just the disk and tape though, it's running a > > backup as I do this. > > Paul, this is really starting to smell like cables. It is time > to go to the known SCSI-II cables and active termination. Didn't you > say you weren't sure they were all SCSI-II? > Ok, a summary and yes I proably agree with you its cables. I've found a setup that works and I'm leaving it that way :-) I had to disable scsi=ii and sync for all three devices, even that didn't work first off. I then found a scsi chain configuration that did work, with a scsi-ii cable from card to disk, scsi-ii from disk to cdrom and a scsi-i (no more scsi-ii cables) from the cdrom to DAT with active termination on the DAT. I'm not using internal termination on any of the devices, just the controller, I plug an active terminator into the back of the DAT. Well, this has worked well under heavy loading for over 12 hours so I'm not touching it :-) This whole box is a temporary setup so when we buy the new server I'll make sure we get decent cables too :-) Thanks for all the help guys. -- 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 19 06:24:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA23226 for current-outgoing; Wed, 19 Jul 1995 06:24:38 -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 GAA23219 for ; Wed, 19 Jul 1995 06:24:27 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA21816; Wed, 19 Jul 1995 23:20:28 +1000 Date: Wed, 19 Jul 1995 23:20:28 +1000 From: Bruce Evans Message-Id: <199507191320.XAA21816@godzilla.zeta.org.au> To: bde@zeta.org.au, dfr@render.com Subject: Re: slow nfsv3 writes Cc: current@freebsd.org, esser@zpr.uni-koeln.de Sender: current-owner@freebsd.org Precedence: bulk >> All combinations of interface, benchmark and benchmark block size that I tried >> give about 100K/sec writes and 900K/sec reads. The disk on the server is on >> constantly. >This is fixed by a recent change to vfs_bio. The buffer cache was >getting confused and was forcing synchronous writes for blocksizes >smaller than 8k. I now get 400k/sec writes to my sgi with all blocksizes. I was getting 9K/sec for writes before I complained and this change was made :-). Bruce From owner-freebsd-current Wed Jul 19 06:25:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA23283 for current-outgoing; Wed, 19 Jul 1995 06:25:50 -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 GAA23271 for ; Wed, 19 Jul 1995 06:25:36 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id NAA23026; Wed, 19 Jul 1995 13:43:57 +0100 Date: Wed, 19 Jul 1995 13:43:55 +0100 (BST) From: Doug Rabson To: Bruce Evans cc: esser@zpr.uni-koeln.de, current@freebsd.org Subject: Re: slow nfsv3 writes In-Reply-To: <199507182123.HAA25447@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk On Wed, 19 Jul 1995, Bruce Evans wrote: > >This is NFSv2, a 486DX2/66 (16MB RAM, DEC 21040 PCI Ethernet), > >the server is a SparcServer 1000 running Solaris 2.4, measured > >when the NFSv3 patches had just been integrated: > > And for -current on a slow 486DX2/66 (16MB RAM, _loopback_): > > > -------Sequential Output-------- ---Sequential Input-- --Random-- > > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > >Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > >SP3G 20 577 35.3 579 4.5 356 7.5 874 58.6 985 10.4 53.4 16.1 > >Noname 1 111 8.8 132 3.8 140 7.1 964 76.8 9417 99.3 175.8 26.8 > > All combinations of interface, benchmark and benchmark block size that I tried > give about 100K/sec writes and 900K/sec reads. The disk on the server is on > constantly. This is fixed by a recent change to vfs_bio. The buffer cache was getting confused and was forcing synchronous writes for blocksizes smaller than 8k. I now get 400k/sec writes to my sgi with all blocksizes. I managed to hang my machine a couple of times testing a loopback mount. All the nfsds were blocked on nfsrcvlk. Any ideas? -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Wed Jul 19 06:30:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA23687 for current-outgoing; Wed, 19 Jul 1995 06:30:41 -0700 Received: (from phk@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA23678 ; Wed, 19 Jul 1995 06:30:40 -0700 From: Poul-Henning Kamp Message-Id: <199507191330.GAA23678@freefall.cdrom.com> Subject: Re: slow nfsv3 writes To: bde@zeta.org.au (Bruce Evans) Date: Wed, 19 Jul 1995 06:30:39 -0700 (PDT) Cc: bde@zeta.org.au, dfr@render.com, current@freebsd.org, esser@ZPR.Uni-Koeln.DE In-Reply-To: <199507191320.XAA21816@godzilla.zeta.org.au> from "Bruce Evans" at Jul 19, 95 11:20:28 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 822 Sender: current-owner@freebsd.org Precedence: bulk > >> All combinations of interface, benchmark and benchmark block size that I tried > >> give about 100K/sec writes and 900K/sec reads. The disk on the server is on > >> constantly. > > >This is fixed by a recent change to vfs_bio. The buffer cache was > >getting confused and was forcing synchronous writes for blocksizes > >smaller than 8k. I now get 400k/sec writes to my sgi with all blocksizes. > > I was getting 9K/sec for writes before I complained and this change > was made :-). How about running a snoop and get some per-packet times ? -- 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 19 07:12:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id HAA25120 for current-outgoing; Wed, 19 Jul 1995 07:12:55 -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 HAA25112 ; Wed, 19 Jul 1995 07:12:37 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA23267; Thu, 20 Jul 1995 00:08:07 +1000 Date: Thu, 20 Jul 1995 00:08:07 +1000 From: Bruce Evans Message-Id: <199507191408.AAA23267@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@freefall.cdrom.com Subject: Re: slow nfsv3 writes Cc: current@freebsd.org, dfr@render.com, esser@ZPR.Uni-Koeln.DE Sender: current-owner@freebsd.org Precedence: bulk >> I was getting 9K/sec for writes before I complained and this change >> was made :-). >How about running a snoop and get some per-packet times ? `iozone 1 8192' on a 486DX2/66 over lo0 reports reading at 1775129 bytes/sec and writing at 111227 bytes/sec. tcpdump reports about 4ms for reading 8292 bytes and about 70ms for writing 8320 bytes. The problem was that this is actually for nfsv2. For some reason I thought that nfsv3 would be the default. Under nfsv3, `iozone 4 8192' reports ... oops it hangs on netio and other processes hang on nfsrcvlk and after a little while other processes hang on ufslk2 ... This is probably the same problem that Doug saw. Bruce From owner-freebsd-current Wed Jul 19 07:39:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id HAA25807 for current-outgoing; Wed, 19 Jul 1995 07:39:12 -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 HAA25792 ; Wed, 19 Jul 1995 07:39:04 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id PAA23535; Wed, 19 Jul 1995 15:23:12 +0100 Date: Wed, 19 Jul 1995 15:23:11 +0100 (BST) From: Doug Rabson To: Bruce Evans cc: bde@zeta.org.au, phk@freefall.cdrom.com, current@freebsd.org, esser@zpr.uni-koeln.de Subject: Re: slow nfsv3 writes In-Reply-To: <199507191408.AAA23267@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk On Thu, 20 Jul 1995, Bruce Evans wrote: > >> I was getting 9K/sec for writes before I complained and this change > >> was made :-). > > >How about running a snoop and get some per-packet times ? > > `iozone 1 8192' on a 486DX2/66 over lo0 reports reading at > 1775129 bytes/sec and writing at 111227 bytes/sec. tcpdump reports > about 4ms for reading 8292 bytes and about 70ms for writing 8320 > bytes. > > The problem was that this is actually for nfsv2. For some reason I > thought that nfsv3 would be the default. I think the default should be for mount_nfs to attempt a v3 mount rpc and if that fails, then fall back to v2. > > Under nfsv3, `iozone 4 8192' reports ... oops it hangs on netio and > other processes hang on nfsrcvlk and after a little while other > processes hang on ufslk2 ... This is probably the same problem > that Doug saw. I haven't had a chance to look at this yet. I am in Windows95 mode at the moment :-( -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Wed Jul 19 08:02:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id IAA26523 for current-outgoing; Wed, 19 Jul 1995 08:02:35 -0700 Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id IAA26512 for ; Wed, 19 Jul 1995 08:02:27 -0700 Received: (from news@localhost) by haywire.DIALix.COM (8.6.12/8.6.12/DIALix) id XAA03674 for freebsd-current@freebsd.org; Wed, 19 Jul 1995 23:02:16 +0800 Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 19 Jul 1995 23:02:08 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <3uj6pg$3h3$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. Subject: what's going on here? (NFSv3 problem?) Sender: current-owner@freebsd.org Precedence: bulk Some time in the last few weeks, doing a ls on a large NFS mounted directory.. It looks like the server is answering with the wrong offset, but it used to work and the server hasn't changed lately (like, years... It's a vintage SVR4.0/386 system.) The freebsd client has it mounted with a read and write size of 1024, which struck me as odd that it appears to be asking for a 8192 byte chunk... It works fine with directory scans of smaller directories.. And yes, I'm just about to run fsirand on the server.. :-) Puzzled, (I don't speak NFS, so please be gentle.. ;-) -Peter jhome # tcpdump -s 10000 -vv port nfs tcpdump: listening on ed0 14:32:00.078577 jhome.f3 > haywire.nfs: 128 lookup fh 0,1/11 "." (ttl 64, id 35407) 14:32:00.083958 haywire.nfs > jhome.f3: reply ok 128 lookup fh 0,1/11 DIR 40755 ids 2004/304 sz 4608 nlink 20 rdev 0 fsid 1 nodeid 122b0 a/m/ctime 806164215.955880 806140879.043601 806140879.043601 (ttl 30, id 56882) 14:32:00.085901 jhome.f4 > haywire.nfs: 128 lookup fh 0,1/11 "." (ttl 64, id 35408) 14:32:00.089350 haywire.nfs > jhome.f4: reply ok 128 lookup fh 0,1/11 DIR 40755 ids 2004/304 sz 4608 nlink 20 rdev 0 fsid 1 nodeid 122b0 a/m/ctime 806164215.955880 806140879.043601 806140879.043601 (ttl 30, id 56883) 14:32:00.090940 jhome.f5 > haywire.nfs: 120 getattr fh 0,1/11 (ttl 64, id 35409) 14:32:00.094075 haywire.nfs > jhome.f5: reply ok 96 getattr DIR 40755 ids 2004/304 sz 4608 (ttl 30, id 56884) [ note that it asks the same thing again ] 14:32:00.095423 jhome.f6 > haywire.nfs: 120 getattr fh 0,1/11 (ttl 64, id 35410) 14:32:00.098540 haywire.nfs > jhome.f6: reply ok 96 getattr DIR 40755 ids 2004/304 sz 4608 (ttl 30, id 56885) [and again.. another getattr...] 14:32:00.099626 jhome.f7 > haywire.nfs: 120 getattr fh 0,1/11 (ttl 64, id 35411) 14:32:00.105959 haywire.nfs > jhome.f7: reply ok 96 getattr DIR 40755 ids 2004/304 sz 4608 (ttl 30, id 56886) [ and here we start the readdir packets.. note the times...] 14:32:00.108383 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35412) 14:32:00.120718 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56887:1480@0+) (ttl 30) ^^ 14:32:00.315550 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35413) 14:32:00.339449 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56888:1480@0+) (ttl 30) ^^ 14:32:00.725494 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35418) 14:32:00.739364 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56889:1480@0+) (ttl 30) ^^ 14:32:01.535204 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35420) 14:32:01.547494 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56904:1480@0+) (ttl 30) ^^ 14:32:03.144782 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35421) 14:32:03.155896 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56905:1480@0+) (ttl 30) ^^ 14:32:06.354102 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35424) 14:32:06.365342 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56907:1480@0+) (ttl 30) ^^ 14:32:12.762514 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35426) 14:32:12.775162 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56909:1480@0+) (ttl 30) ^^ 14:32:25.569545 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35427) 14:32:25.582252 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56915:1480@0+) (ttl 30) ^^ 14:32:51.173615 jhome.f8 > haywire.nfs: 128 readdir fh 0,1/11 8192 bytes @ 0 (ttl 64, id 35430) 14:32:51.186349 haywire.nfs > jhome.f8: reply ok 1472 readdir offset 1 size 74416 eof (frag 56922:1480@0+) (ttl 30) ^^ Script done on Wed Jul 19 22:34:54 1995 From owner-freebsd-current Wed Jul 19 08:53:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id IAA28907 for current-outgoing; Wed, 19 Jul 1995 08:53:41 -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 IAA28899 for ; Wed, 19 Jul 1995 08:53:33 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id QAA24889; Wed, 19 Jul 1995 16:53:26 +0100 Date: Wed, 19 Jul 1995 16:53:25 +0100 (BST) From: Doug Rabson To: Peter Wemm cc: freebsd-current@freebsd.org Subject: Re: what's going on here? (NFSv3 problem?) In-Reply-To: <3uj6pg$3h3$1@haywire.DIALix.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk On 19 Jul 1995, Peter Wemm wrote: > Some time in the last few weeks, doing a ls on a large NFS mounted > directory.. It looks like the server is answering with the wrong > offset, but it used to work and the server hasn't changed lately > (like, years... It's a vintage SVR4.0/386 system.) > > The freebsd client has it mounted with a read and write size of 1024, > which struck me as odd that it appears to be asking for a 8192 byte > chunk... It works fine with directory scans of smaller directories.. > > And yes, I'm just about to run fsirand on the server.. :-) > > Puzzled, (I don't speak NFS, so please be gentle.. ;-) > -Peter > I just checked and it appears that the size used for readdir requests (NFS_DIRBLKSIZE) has increased from 1024 to 4096 in the nfsv3 change. I am not sure why though. It is also a bit confusing that you are seeing 8k readdir requests - from the looks of it, they should be 4k. Try reducing NFS_DIRBLKSIZE in to 1024 and see if it fixes your problem. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Wed Jul 19 10:42:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id KAA02442 for current-outgoing; Wed, 19 Jul 1995 10:42:18 -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 KAA02419 ; Wed, 19 Jul 1995 10:42:15 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id KAA01357; Wed, 19 Jul 1995 10:41:36 -0700 To: Wolfram Schneider cc: Garrett Wollman , current@freebsd.org Subject: Re: multilingual cal(1) In-reply-to: Your message of "Wed, 19 Jul 1995 13:29:54 +0200." <199507191129.NAA13694@caramba.cs.tu-berlin.de> Date: Wed, 19 Jul 1995 10:41:36 -0700 Message-ID: <1355.806175696@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk > BTW, support FreeBSD GNU-gettext? Work on this is underway. Jordan From owner-freebsd-current Wed Jul 19 11:16:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id LAA04414 for current-outgoing; Wed, 19 Jul 1995 11:16:30 -0700 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id LAA04408 for ; Wed, 19 Jul 1995 11:16:27 -0700 Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id NAA09615 for ; Wed, 19 Jul 1995 13:16:25 -0500 Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Wed, 19 Jul 95 13:16 CDT Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Wed, 19 Jul 95 13:16 CDT Message-Id: Subject: SUP target for -STABLE, and setup for SUP info? To: current@freebsd.org Date: Wed, 19 Jul 1995 13:16:23 -0500 (CDT) From: "Karl Denninger, MCSNet" X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 600 Sender: current-owner@freebsd.org Precedence: bulk Hi there! I'd like to set up to get SUP updates of -STABLE, if there is a target for it. Unfortunately for me, I haven't set up SUP before. Anyone got a FAQ for me on the way to get this going? Thanks in advance! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's only FULL AP Clarinet feed! From owner-freebsd-current Wed Jul 19 14:48:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id OAA12566 for current-outgoing; Wed, 19 Jul 1995 14:48:47 -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 OAA12560 for ; Wed, 19 Jul 1995 14:48:43 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id OAA07950; Wed, 19 Jul 1995 14:48:58 -0700 From: "Rodney W. Grimes" Message-Id: <199507192148.OAA07950@gndrsh.aac.dev.com> Subject: Re: SUP target for -STABLE, and setup for SUP info? To: karl@mcs.com (Karl Denninger, MCSNet) Date: Wed, 19 Jul 1995 14:48:58 -0700 (PDT) Cc: current@freebsd.org In-Reply-To: from "Karl Denninger, MCSNet" at Jul 19, 95 01:16: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: 797 Sender: current-owner@freebsd.org Precedence: bulk > > > Hi there! > > I'd like to set up to get SUP updates of -STABLE, if there is a target for > it. Yes, and there is a sample sup file for getting it. Probably the best way to get that is to ftp it from the -CURRENT tree (I commited it there and pulled it into the -STABLE branch). Path name relative to the base of the -CURRENT src tree is: src/share/FAQ/extras/stable-supfile > Unfortunately for me, I haven't set up SUP before. Anyone got a FAQ for me > on the way to get this going? /usr/share/FAQ/Text/sup.FAQ on any 2.0.5 or later system or src/share/FAQ/Text/sup.FAQ from a source tree. > Thanks in advance! Your welcome! -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Jul 19 22:22:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id WAA23148 for current-outgoing; Wed, 19 Jul 1995 22:22:55 -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 WAA23141 for ; Wed, 19 Jul 1995 22:22:52 -0700 Received: (from jkh@localhost) by time.cdrom.com (8.6.11/8.6.9) id WAA16192 for current@freefall; Wed, 19 Jul 1995 22:22:14 -0700 Date: Wed, 19 Jul 1995 22:22:14 -0700 From: "Jordan K. Hubbard" Message-Id: <199507200522.WAA16192@time.cdrom.com> To: current@freefall.cdrom.com Subject: Hmmmm! New error encountered with cpio while building root.flp Sender: current-owner@FreeBSD.org Precedence: bulk .. cpio: stand/date not dumped: minor number would be truncated cpio: stand/dd not dumped: minor number would be truncated cpio: stand/echo not dumped: minor number would be truncated cpio: stand/ed not dumped: minor number would be truncated cpio: stand/expr not dumped: minor number would be truncated cpio: stand/grep not dumped: minor number would be truncated And so on. It results in a root.flp image that's only 512 bytes long.. :-( Building the root.flp in /usr/src/release/Makefile *used* to work, but now this. Some recent change in current? I'm building a 2.2 snapshot just for my own use.. Jordan From owner-freebsd-current Wed Jul 19 23:25:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id XAA24525 for current-outgoing; Wed, 19 Jul 1995 23:25:47 -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 XAA24518 for ; Wed, 19 Jul 1995 23:25:45 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id XAA08596; Wed, 19 Jul 1995 23:25:57 -0700 From: "Rodney W. Grimes" Message-Id: <199507200625.XAA08596@gndrsh.aac.dev.com> Subject: Re: Hmmmm! New error encountered with cpio while building root.flp To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 19 Jul 1995 23:25:57 -0700 (PDT) Cc: current@freefall.cdrom.com In-Reply-To: <199507200522.WAA16192@time.cdrom.com> from "Jordan K. Hubbard" at Jul 19, 95 10:22:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1276 Sender: current-owner@FreeBSD.org Precedence: bulk > > .. > cpio: stand/date not dumped: minor number would be truncated > cpio: stand/dd not dumped: minor number would be truncated > cpio: stand/echo not dumped: minor number would be truncated > cpio: stand/ed not dumped: minor number would be truncated > cpio: stand/expr not dumped: minor number would be truncated > cpio: stand/grep not dumped: minor number would be truncated > > And so on. It results in a root.flp image that's only 512 bytes long.. :-( Looks like Bruces changes to cpio to skip dumping dev nodes that have high values is causing some problems :-(. > Building the root.flp in /usr/src/release/Makefile *used* to work, but > now this. Some recent change in current? I'm building a 2.2 snapshot > just for my own use.. Looks like we are going to have to be _very_ carefull that we build 2.1R on a 2.1R system or we may get some really bizzare problems :-(. And you may very well want to build your 2.2 snaps on a 2.0.5R system for similiar reasons, until 2.1R can be rolled :-(. 2.0.5R cpio should properly read 2.2 cpio files, if it does not we have a bigger problem than I thought :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Jul 20 01:42:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id BAA28284 for current-outgoing; Thu, 20 Jul 1995 01:42:40 -0700 Received: (from phk@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id BAA28272 ; Thu, 20 Jul 1995 01:42:38 -0700 From: Poul-Henning Kamp Message-Id: <199507200842.BAA28272@freefall.cdrom.com> Subject: Re: Hmmmm! New error encountered with cpio while building root.flp To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 20 Jul 1995 01:42:37 -0700 (PDT) Cc: current@freefall.cdrom.com In-Reply-To: <199507200522.WAA16192@time.cdrom.com> from "Jordan K. Hubbard" at Jul 19, 95 10:22:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 998 Sender: current-owner@FreeBSD.org Precedence: bulk > cpio: stand/date not dumped: minor number would be truncated > cpio: stand/dd not dumped: minor number would be truncated > cpio: stand/echo not dumped: minor number would be truncated > cpio: stand/ed not dumped: minor number would be truncated > cpio: stand/expr not dumped: minor number would be truncated > cpio: stand/grep not dumped: minor number would be truncated > > And so on. It results in a root.flp image that's only 512 bytes long.. :-( > > Building the root.flp in /usr/src/release/Makefile *used* to work, but > now this. Some recent change in current? I'm building a 2.2 snapshot > just for my own use.. I think Bruce added this warning. Bruce, that shouldn't apply to a "cpio -dump" command should it ? -- 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 Thu Jul 20 02:02:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id CAA29340 for current-outgoing; Thu, 20 Jul 1995 02:02:02 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id CAA29333 for ; Thu, 20 Jul 1995 02:01:59 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id LAA12941 for ; Thu, 20 Jul 1995 11:01:54 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id LAA14837 for current@FreeBSD.org; Thu, 20 Jul 1995 11:01:53 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199507200901.LAA14837@blaise.ibp.fr> Subject: install FreeBSD (fwd) To: current@FreeBSD.org (Current's list FreeBSD) Date: Thu, 20 Jul 1995 11:01:53 +0200 (MET DST) X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 983 Sender: current-owner@FreeBSD.org Precedence: bulk Forwarded message: > Date: Thu, 20 Jul 1995 10:06:23 -0300 > To: FAQ@FreeBSD.ORG > From: bougron@world-net.sct.fr (Support Technique Worldnet) > Subject: install FreeBSD > > Hello, I was very happy to see that you answered me yesterday but even after > I have disabled the devices in conflict with ed1(ethernet card NE2000) > and made partition and distribution I can't connect to the server who > provides FreeBSD. I receive these messages : 'cannot resolve hostname...' or > 'couldn't open FTP connection' or warning 'missing name server value ...' > and 'unable to configure the ed1 interface '. > PLEASE HELP > > Renaud. > > Support Worldnet > Worldnet The French Provider > Hot Line Technique : 40.37.32.67 > Service Commercial : 40.37.90.90 > Fax : 40.37.90.89 > France, Paris > > -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Thu Jul 20 02:57:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id CAA01270 for current-outgoing; Thu, 20 Jul 1995 02:57:36 -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 CAA01262 for ; Thu, 20 Jul 1995 02:57:00 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA20979; Thu, 20 Jul 1995 19:55:07 +1000 Date: Thu, 20 Jul 1995 19:55:07 +1000 From: Bruce Evans Message-Id: <199507200955.TAA20979@godzilla.zeta.org.au> To: current@freefall.cdrom.com, jkh@time.cdrom.com Subject: Re: Hmmmm! New error encountered with cpio while building root.flp Sender: current-owner@FreeBSD.org Precedence: bulk >cpio: stand/date not dumped: minor number would be truncated >cpio: stand/dd not dumped: minor number would be truncated >And so on. It results in a root.flp image that's only 512 bytes long.. :-( >Building the root.flp in /usr/src/release/Makefile *used* to work, but cpio (and tar) now check for minor numbers that would be truncated. pax now uses the correct macro for minor() so its existing check works. The check is only done for st_rdev, not for st_dev. st_rdev is meaningless for regular files. Unfortunately, st_rdev is apparently a garbage value for regular files, and cpio apparently attempts to copy it. I'm not sure what tar does. pax zeros it except for special files, at least for tar format. You should be using a cpio format that preserves all minor numbers, e.g., `cpio -H newc'. Bruce From owner-freebsd-current Thu Jul 20 03:03:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id DAA01630 for current-outgoing; Thu, 20 Jul 1995 03:03:54 -0700 Received: (from phk@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id DAA01620 ; Thu, 20 Jul 1995 03:03:52 -0700 From: Poul-Henning Kamp Message-Id: <199507201003.DAA01620@freefall.cdrom.com> Subject: Re: Hmmmm! New error encountered with cpio while building root.flp To: bde@zeta.org.au (Bruce Evans) Date: Thu, 20 Jul 1995 03:03:52 -0700 (PDT) Cc: current@freefall.cdrom.com, jkh@time.cdrom.com In-Reply-To: <199507200955.TAA20979@godzilla.zeta.org.au> from "Bruce Evans" at Jul 20, 95 07:55:07 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 757 Sender: current-owner@FreeBSD.org Precedence: bulk > >cpio: stand/date not dumped: minor number would be truncated > >cpio: stand/dd not dumped: minor number would be truncated > > >And so on. It results in a root.flp image that's only 512 bytes long.. :-( > > >Building the root.flp in /usr/src/release/Makefile *used* to work, but > > cpio (and tar) now check for minor numbers that would be truncated. pax > now uses the correct macro for minor() so its existing check works. The You shouldn't check when "cpio -p" is in effect.. -- 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 Thu Jul 20 03:32:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id DAA02360 for current-outgoing; Thu, 20 Jul 1995 03:32:08 -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 DAA02337 for ; Thu, 20 Jul 1995 03:31:47 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA21969; Thu, 20 Jul 1995 20:28:07 +1000 Date: Thu, 20 Jul 1995 20:28:07 +1000 From: Bruce Evans Message-Id: <199507201028.UAA21969@godzilla.zeta.org.au> To: jkh@time.cdrom.com, rgrimes@gndrsh.aac.dev.com Subject: Re: Hmmmm! New error encountered with cpio while building root.flp Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> cpio: stand/date not dumped: minor number would be truncated >> cpio: stand/dd not dumped: minor number would be truncated >Looks like Bruces changes to cpio to skip dumping dev nodes that have >high values is causing some problems :-(. These changes should be in 2.1 (I submitted them very late for 2.0.5). Apparently 2.2 isn't used enough for them to be tested enough. To see the bug, try `cd somedir; /bin/ls | cpio -o | cpio -it'. This works here for somedir=/bin but fails for somedir=/usr/src/bin/cat. I think this has something to do with /bin being on a smaller file system. >Looks like we are going to have to be _very_ carefull that we build 2.1R >on a 2.1R system or we may get some really bizzare problems :-(. >And you may very well want to build your 2.2 snaps on a 2.0.5R system >for similiar reasons, until 2.1R can be rolled :-(. 2.0.5R cpio should That would be another way to get a system that can't build itself. >properly read 2.2 cpio files, if it does not we have a bigger problem >than I thought :-(. There is no problem reading. cpio now refuses to copyout files that it can't handle. Bruce From owner-freebsd-current Thu Jul 20 04:08:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id EAA03795 for current-outgoing; Thu, 20 Jul 1995 04:08:00 -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 EAA03666 ; Thu, 20 Jul 1995 04:07:34 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA22942; Thu, 20 Jul 1995 21:02:31 +1000 Date: Thu, 20 Jul 1995 21:02:31 +1000 From: Bruce Evans Message-Id: <199507201102.VAA22942@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@freefall.cdrom.com Subject: Re: Hmmmm! New error encountered with cpio while building root.flp Cc: current@freefall.cdrom.com, jkh@time.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> cpio (and tar) now check for minor numbers that would be truncated. pax >> now uses the correct macro for minor() so its existing check works. The >You shouldn't check when "cpio -p" is in effect.. I only check for `cpio -o' since that is the only place where I thought minor numbers would be truncated. Now I can think of some more places: for `cpio -i', 32-bit rdevs in the input may be silently truncated if ints or rdevs in the target system are less than 32 bits. I think there are similar bugs in nfs. Bruce From owner-freebsd-current Thu Jul 20 04:35:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id EAA04542 for current-outgoing; Thu, 20 Jul 1995 04:35:19 -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 EAA04536 for ; Thu, 20 Jul 1995 04:35:17 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id EAA09014; Thu, 20 Jul 1995 04:32:29 -0700 From: "Rodney W. Grimes" Message-Id: <199507201132.EAA09014@gndrsh.aac.dev.com> Subject: Re: Hmmmm! New error encountered with cpio while building root.flp To: bde@zeta.org.au (Bruce Evans) Date: Thu, 20 Jul 1995 04:32:29 -0700 (PDT) Cc: jkh@time.cdrom.com, current@freefall.cdrom.com In-Reply-To: <199507201028.UAA21969@godzilla.zeta.org.au> from "Bruce Evans" at Jul 20, 95 08:28:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2556 Sender: current-owner@FreeBSD.org Precedence: bulk > > >> cpio: stand/date not dumped: minor number would be truncated > >> cpio: stand/dd not dumped: minor number would be truncated > > >Looks like Bruces changes to cpio to skip dumping dev nodes that have > >high values is causing some problems :-(. > > These changes should be in 2.1 (I submitted them very late for 2.0.5). > Apparently 2.2 isn't used enough for them to be tested enough. > > To see the bug, try `cd somedir; /bin/ls | cpio -o | cpio -it'. This > works here for somedir=/bin but fails for somedir=/usr/src/bin/cat. I > think this has something to do with /bin being on a smaller file > system. Should that error perhaps be ``inode number would be truncated''??? > >Looks like we are going to have to be _very_ carefull that we build 2.1R > >on a 2.1R system or we may get some really bizzare problems :-(. > > >And you may very well want to build your 2.2 snaps on a 2.0.5R system > >for similiar reasons, until 2.1R can be rolled :-(. 2.0.5R cpio should > > That would be another way to get a system that can't build itself. Yes I suppose that could be true, I use to start with a system that had 2 iterations of make world run on it before I used that to create a chroot tree which I then ran a 3rd make world in that was the actually production build. Perhaps overkill, but it made darn sure I could say the last release can build the current release and the current release can build itself. I use to have to do all this double build stuff by hand until Poul and Jordan went and automated it for the 2.0 release, and then heavly improved that for the 2.0.5 release. [I may have release numbers off here, I didn't look at src/release until the 2.0.5 release when I started to run it every 24 hours for Jordan to make sure we didn't do anything that made it fall over] My concern is that you may have problems building the chroot tree using 2.2 as the release tools need some fixing, but that fixing may break the release tools when they run inside the 2.1 tree, and as you point out the opposite may be true as well :-(. > >properly read 2.2 cpio files, if it does not we have a bigger problem > >than I thought :-(. > > There is no problem reading. cpio now refuses to copyout files that it > can't handle. Okay, good. So the problems will all happen during the builds which means worse case we end up missing bits, and in the case above all the bits :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Jul 20 05:11:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id FAA06147 for current-outgoing; Thu, 20 Jul 1995 05:11:00 -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 FAA06141 for ; Thu, 20 Jul 1995 05:10:53 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA25205; Thu, 20 Jul 1995 22:10:03 +1000 Date: Thu, 20 Jul 1995 22:10:03 +1000 From: Bruce Evans Message-Id: <199507201210.WAA25205@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@gndrsh.aac.dev.com Subject: Re: Hmmmm! New error encountered with cpio while building root.flp Cc: current@freefall.cdrom.com, jkh@time.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> To see the bug, try `cd somedir; /bin/ls | cpio -o | cpio -it'. This >> works here for somedir=/bin but fails for somedir=/usr/src/bin/cat. I >> think this has something to do with /bin being on a smaller file >> system. >Should that error perhaps be ``inode number would be truncated''??? No, truncation of inodes is a different bug. st_rdev is identical to the first data block number for regular ufs files. Thus there is no (new) problem on file systems with < 65536 blocks. Bruce From owner-freebsd-current Thu Jul 20 05:55:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id FAA07104 for current-outgoing; Thu, 20 Jul 1995 05:55:08 -0700 Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id FAA07098 for ; Thu, 20 Jul 1995 05:55:02 -0700 Received: (from news@localhost) by haywire.DIALix.COM (8.6.12/8.6.12/DIALix) id UAA27712 for freebsd-current@freebsd.org; Thu, 20 Jul 1995 20:54:49 +0800 Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 20 Jul 1995 20:54:45 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <3uljml$r1t$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <3uj6pg$3h3$1@haywire.DIALix.COM>, Subject: Re: what's going on here? (NFSv3 problem?) Sender: current-owner@freebsd.org Precedence: bulk dfr@render.com (Doug Rabson) writes: >On 19 Jul 1995, Peter Wemm wrote: >> Some time in the last few weeks, doing a ls on a large NFS mounted >> directory.. It looks like the server is answering with the wrong >> offset, but it used to work and the server hasn't changed lately >> (like, years... It's a vintage SVR4.0/386 system.) >> >> The freebsd client has it mounted with a read and write size of 1024, >> which struck me as odd that it appears to be asking for a 8192 byte >> chunk... It works fine with directory scans of smaller directories.. >> >> And yes, I'm just about to run fsirand on the server.. :-) >> >> Puzzled, (I don't speak NFS, so please be gentle.. ;-) >> -Peter >> >I just checked and it appears that the size used for readdir requests >(NFS_DIRBLKSIZE) has increased from 1024 to 4096 in the nfsv3 change. I >am not sure why though. It is also a bit confusing that you are seeing >8k readdir requests - from the looks of it, they should be 4k. Hmm. I noticed the following have changed (plus context) from: #define NFS_WSIZE 8192 /* Def. write size */ #define NFS_RSIZE 8192 /* Def. read size */ #define NFS_MAXREADDIR NFS_MAXDATA /* Max size of directory read */ to: #define NFS_WSIZE 8192 /* Def. write size */ #define NFS_RSIZE 8192 /* Def. read size */ #define NFS_READDIRSIZE 8192 /* Def. size of directory read */ I think that's where the 8K readdir comes from.. >Try reducing NFS_DIRBLKSIZE in to 1024 and see if it fixes >your problem. I have not tried that yet, but increasing the mount blocksize from 1K to the default of 8K solves the problem. I then made a very large directory to test that it wasn't because the directory was larger than the read packet size. Perhaps there's a problem with the readdir packet reassembly? -Peter >-- >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 20 07:48:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id HAA10135 for current-outgoing; Thu, 20 Jul 1995 07:48: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 HAA10129 ; Thu, 20 Jul 1995 07:48:53 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id HAA17293; Thu, 20 Jul 1995 07:48:14 -0700 To: Bruce Evans cc: current@freefall.cdrom.com Subject: Re: Hmmmm! New error encountered with cpio while building root.flp In-reply-to: Your message of "Thu, 20 Jul 1995 19:55:07 +1000." <199507200955.TAA20979@godzilla.zeta.org.au> Date: Thu, 20 Jul 1995 07:48:14 -0700 Message-ID: <17290.806251694@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > cpio (and tar) now check for minor numbers that would be truncated. pax > now uses the correct macro for minor() so its existing check works. The > check is only done for st_rdev, not for st_dev. st_rdev is meaningless > for regular files. Unfortunately, st_rdev is apparently a garbage value > for regular files, and cpio apparently attempts to copy it. I'm not > sure what tar does. pax zeros it except for special files, at least for > tar format. > > You should be using a cpio format that preserves all minor numbers, > e.g., `cpio -H newc'. I can easily do this, but it still concerns me that the *default* method for cpio is now essentially broken. This will generate tech support problems for us and should be fixed. A bug is a bug! Thanks.. Jordan From owner-freebsd-current Thu Jul 20 09:16:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id JAA12873 for current-outgoing; Thu, 20 Jul 1995 09:16:01 -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 JAA12859 for ; Thu, 20 Jul 1995 09:15:41 -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 <55498>; Thu, 20 Jul 1995 18:14:50 +0200 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.11/8.6.9) id BAA07660 for current%freebsd.org@regent.e-technik.tu-muenchen.de; Thu, 20 Jul 1995 01:59:37 +0200 Date: Thu, 20 Jul 1995 01:59:37 +0200 From: Julian Howard Stacey Message-Id: <199507192359.BAA07660@vector.eikon.e-technik.tu-muenchen.de> To: current@freebsd.org Subject: cvs strings Sender: current-owner@freebsd.org Precedence: bulk I had hoped to be able to prune down my current src tree by establishing per file symbolic links to the new CD-ROM (as I've done on previous FreeBSD CDs) This time round, many files are just subtly different enough to defeat my automatic compare & delete tool, here is a typical example: diff -c bin/csh/char.c /pub/cd/src/bin/csh/char.c *** bin/csh/char.c Wed May 3 15:38:54 1995 --- /cd/src/bin/csh/char.c Fri Sep 23 14:53:46 1994 *************** *** 30,36 **** ! * $Id: char.c,v 1.2 1994/09/24 02:53:46 davidg Exp $ --- 30,36 ---- ! * char.c,v 1.2 1994/09/24 02:53:46 davidg Exp These changes seem most unfortunate. Can we avoid such slight alterations next time round ? It seems wasteful on disc space, sup & ctm bandwidth, to put a different stamp on a file that has identical contents. BTW This is a general CVS policy question with no particular reference to davidg, who I guess just happened to be in this example Those tiny strings changes "$Id: " & " $" convey no extra information to me, but prevent people with CD-ROMS saving space. Julian S From owner-freebsd-current Thu Jul 20 09:16:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id JAA12975 for current-outgoing; Thu, 20 Jul 1995 09:16:41 -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 JAA12954 for ; Thu, 20 Jul 1995 09:16:34 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA00562; Fri, 21 Jul 1995 02:11:59 +1000 Date: Fri, 21 Jul 1995 02:11:59 +1000 From: Bruce Evans Message-Id: <199507201611.CAA00562@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@gndrsh.aac.dev.com Subject: Re: Hmmmm! New error encountered with cpio while building root.flp Cc: current@freefall.cdrom.com, jkh@time.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> There is no problem reading. cpio now refuses to copyout files that it >> can't handle. >Okay, good. So the problems will all happen during the builds which >means worse case we end up missing bits, and in the case above all >the bits :-(. There will be no problem unless you ignore the error output. I didn't make the error fatal because that would be inconsistent with cpio's handling of worse errors. cpio should continue but exit with a nonzero status like tar does. Bruce From owner-freebsd-current Thu Jul 20 10:25:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id KAA15718 for current-outgoing; Thu, 20 Jul 1995 10:25:26 -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 KAA15712 for ; Thu, 20 Jul 1995 10:25:24 -0700 Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id KAA02215; Thu, 20 Jul 1995 10:24:55 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id KAA06743; Thu, 20 Jul 1995 10:25:55 -0700 Message-Id: <199507201725.KAA06743@corbin.Root.COM> To: Julian Howard Stacey cc: current@freebsd.org Subject: Re: cvs strings In-reply-to: Your message of "Thu, 20 Jul 95 01:59:37 +0200." <199507192359.BAA07660@vector.eikon.e-technik.tu-muenchen.de> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 20 Jul 1995 10:25:54 -0700 Sender: current-owner@freebsd.org Precedence: bulk >I had hoped to be able to prune down my current src tree >by establishing per file symbolic links to the new CD-ROM >(as I've done on previous FreeBSD CDs) > >This time round, many files are just subtly different enough >to defeat my automatic compare & delete tool, here is a typical example: > diff -c bin/csh/char.c /pub/cd/src/bin/csh/char.c > *** bin/csh/char.c Wed May 3 15:38:54 1995 > --- /cd/src/bin/csh/char.c Fri Sep 23 14:53:46 1994 > *************** > *** 30,36 **** > ! * $Id: char.c,v 1.2 1994/09/24 02:53:46 davidg Exp $ > --- 30,36 ---- > ! * char.c,v 1.2 1994/09/24 02:53:46 davidg Exp > >These changes seem most unfortunate. >Can we avoid such slight alterations next time round ? >It seems wasteful on disc space, sup & ctm bandwidth, >to put a different stamp on a file that has identical contents. > >BTW This is a general CVS policy question with no particular reference >to davidg, who I guess just happened to be in this example > >Those tiny strings changes "$Id: " & " $" convey no extra information to me, >but prevent people with CD-ROMS saving space. This definately tops my "most silly things said" list. Of course, I didn't make such a gratuitous change. The identifier ($Id$, $Log$, etc...) keywords are automatically removed as part of the cvs export operation, which is how the final source tree is created. -DG From owner-freebsd-current Thu Jul 20 11:00:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id LAA17174 for current-outgoing; Thu, 20 Jul 1995 11:00:18 -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 LAA17168 ; Thu, 20 Jul 1995 11:00:16 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA02515; Thu, 20 Jul 95 11:52:44 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9507201752.AA02515@cs.weber.edu> Subject: Re: Hmmmm! New error encountered with cpio while building root.flp To: bde@zeta.org.au (Bruce Evans) Date: Thu, 20 Jul 95 11:52:43 MDT Cc: bde@zeta.org.au, phk@freefall.cdrom.com, current@freefall.cdrom.com, jkh@time.cdrom.com In-Reply-To: <199507201102.VAA22942@godzilla.zeta.org.au> from "Bruce Evans" at Jul 20, 95 09:02:31 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > Now I can think of some more places: for `cpio -i', 32-bit rdevs in the > input may be silently truncated if ints or rdevs in the target system > are less than 32 bits. I think there are similar bugs in nfs. The "bug" is that device file systems should be accessed locally through devfs only for BSD-to-BSD and that device nodes are an antiquated concept that should be present only fodiskless support of legacy systems. If there's going to be a hatchet-job on minor numbers, then it ought to be done all the way instead of half-heartedly. 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 20 11:40:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id LAA18388 for current-outgoing; Thu, 20 Jul 1995 11:40:08 -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 LAA18382 for ; Thu, 20 Jul 1995 11:40:05 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA02687; Thu, 20 Jul 95 12:32:52 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9507201832.AA02687@cs.weber.edu> Subject: Re: what's going on here? (NFSv3 problem?) To: peter@haywire.dialix.com (Peter Wemm) Date: Thu, 20 Jul 95 12:32:51 MDT Cc: freebsd-current@freebsd.org In-Reply-To: <3uljml$r1t$1@haywire.DIALix.COM> from "Peter Wemm" at Jul 20, 95 08:54:45 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > I think that's where the 8K readdir comes from.. > [ ... ] > I have not tried that yet, but increasing the mount blocksize from 1K > to the default of 8K solves the problem. > > I then made a very large directory to test that it wasn't because the > directory was larger than the read packet size. > > Perhaps there's a problem with the readdir packet reassembly? The bug is in the VOP_READDIR code to work around the stat structure size differences. Where I said it was a year ago when they were being implemented. 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 20 14:20:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id OAA24750 for current-outgoing; Thu, 20 Jul 1995 14:20:53 -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 OAA24744 for ; Thu, 20 Jul 1995 14:20:52 -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 OAA08698 for ; Thu, 20 Jul 1995 14:20:40 -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 XAA00928; Thu, 20 Jul 1995 23:03:36 +0200 Received: (from w@localhost) by localhost.cs.tu-berlin.de (8.6.9/8.6.9) id XAA03168; Thu, 20 Jul 1995 23:02:54 +0200 Date: Thu, 20 Jul 1995 23:02:54 +0200 From: Wolfram Schneider Message-Id: <199507202102.XAA03168@localhost.cs.tu-berlin.de> To: current@freebsd.org, wosch@cs.tu-berlin.de Subject: New options for lastcomm(1) Reply-to: wosch@cs.tu-berlin.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: current-owner@freebsd.org Precedence: bulk Example: $ lastcomm -e kermit kermit -FX w ttyp2 366.50 es >From the manpage: lastcomm [-EScesu] [-f file] [command ...] [user ...] [terminal ...] The following options are available: -E The time the process exited. -S The time the process started, default. -c The amount of cpu time used by the process (in seconds), de- fault. -e The amount of elapsed time used by the process (in seconds). -s The amount of system time used by the process (in seconds). -u The amount of user time used by the process (in seconds). Use [-cS] as default if no one of these previous options called. --- 1.1 1995/07/20 13:09:21 +++ lastcomm.c 1995/07/20 14:49:22 @@ -29,6 +29,9 @@ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. + * + * @(#)lastcomm.c 8.1 (Berkeley) 6/6/93 + * $Id: $ */ #ifndef lint @@ -63,6 +66,16 @@ void usage __P((void)); char *user_from_uid(); +#define AC_UTIME 1 /* user */ +#define AC_STIME 2 /* system */ +#define AC_ETIME 4 /* elapsed */ +#define AC_CTIME 8 /* user + system time, default */ + +#define AC_BTIME 16 /* starting time */ +#define AC_FTIME 32 /* exit time (starting time + elapsed time )*/ + +#define AC_HZ ((double)AHZ) + int main(argc, argv) int argc; @@ -76,17 +89,46 @@ time_t t; int ch; char *acctfile; + int time = 0; acctfile = _PATH_ACCT; - while ((ch = getopt(argc, argv, "f:")) != EOF) + while ((ch = getopt(argc, argv, "f:usecSE")) != EOF) switch((char)ch) { case 'f': acctfile = optarg; break; + + case 'u': + time |= AC_UTIME; /* user time */ + break; + case 's': + time |= AC_STIME; /* system time */ + break; + case 'e': + time |= AC_ETIME; /* elapsed time */ + break; + case 'c': + time |= AC_CTIME; /* user + system time */ + break; + + case 'S': + time |= AC_BTIME; /* starting time */ + break; + case 'E': + /* exit time (starting time + elapsed time )*/ + time |= AC_FTIME; + break; + case '?': default: usage(); } + + /* default user + system time and starting time */ + if (!time) { + time = AC_CTIME | AC_BTIME; + } + argc -= optind; argv += optind; @@ -134,12 +176,47 @@ if (*argv && !requested(argv, &ab)) continue; - t = expand(ab.ac_utime) + expand(ab.ac_stime); - (void)printf("%-*s %-7s %-*s %-*s %6.2f secs %.16s\n", + (void)printf("%-*s %-7s %-*s %-*s ", fldsiz(acct, ac_comm), ab.ac_comm, flagbits(ab.ac_flag), UT_NAMESIZE, user_from_uid(ab.ac_uid, 0), - UT_LINESIZE, getdev(ab.ac_tty), - t / (double)AHZ, ctime(&ab.ac_btime)); + UT_LINESIZE, getdev(ab.ac_tty)); + + + /* user + system time */ + if (time & AC_CTIME) { + (void)printf("%6.2f secs ", + (expand(ab.ac_utime) + + expand(ab.ac_stime))/AC_HZ); + } + + /* usr time */ + if (time & AC_UTIME) { + (void)printf("%6.2f us ", expand(ab.ac_utime)/AC_HZ); + } + + /* system time */ + if (time & AC_STIME) { + (void)printf("%6.2f sy ", expand(ab.ac_stime)/AC_HZ); + } + + /* elapsed time */ + if (time & AC_ETIME) { + (void)printf("%8.2f es ", expand(ab.ac_etime)/AC_HZ); + } + + /* starting time */ + if (time & AC_BTIME) { + (void)printf("%.16s ", ctime(&ab.ac_btime)); + } + + /* exit time (starting time + elapsed time )*/ + if (time & AC_FTIME) { + t = ab.ac_btime; + t += (time_t)(expand(ab.ac_etime)/AC_HZ); + (void)printf("%.16s ", + ctime(&t)); + } + printf("\n"); } exit(0); } @@ -217,6 +294,6 @@ usage() { (void)fprintf(stderr, - "lastcomm [ -f file ] [command ...] [user ...] [tty ...]\n"); + "lastcomm [-EScesu] [ -f file ] [command ...] [user ...] [tty ...]\n"); exit(1); } --- 1.1 1995/07/20 14:40:29 +++ lastcomm.1 1995/07/20 15:01:22 @@ -30,6 +30,7 @@ .\" SUCH DAMAGE. .\" .\" @(#)lastcomm.1 8.1 (Berkeley) 6/6/93 +.\" $Id: $ .\" .Dd June 6, 1993 .Dt LASTCOMM 1 @@ -39,6 +40,7 @@ .Nd show last commands executed in reverse order .Sh SYNOPSIS .Nm lastcomm +.Op Fl EScesu .Op Fl f Ar file .Op Ar command ... .Op Ar user ... @@ -50,8 +52,35 @@ .Nm lastcomm prints information about all the commands recorded during the current accounting file's lifetime. + .Pp -Option: +The following options are available: +.Pp +.Bl -tag -width Fl +.Pp +.It Fl E +The time the process exited. +.Pp +.It Fl S +The time the process started, default. + +.It Fl c +The amount of cpu time used by the process (in seconds), default. +.It Fl e +The amount of elapsed time used by the process (in seconds). +.It Fl s +The amount of system time used by the process (in seconds). +.It Fl u +The amount of user time used by the process (in seconds). +.El + +.Pp +Use +.Op Fl cS +as default if no one of these previous options called. +.Pp +.Pp + .Pp .Bl -tag -width Fl .It Fl f Ar file @@ -95,7 +124,8 @@ .It The amount of cpu time used by the process (in seconds). .It -The time the process exited. +.\" Wrong: The time the process exited. +The time the process started. .El .Pp The flags are encoded as follows: ``S'' indicates the command was From owner-freebsd-current Thu Jul 20 14:40:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id OAA25904 for current-outgoing; Thu, 20 Jul 1995 14:40:30 -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 OAA25896 for ; Thu, 20 Jul 1995 14:40:27 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id OAA09980; Thu, 20 Jul 1995 14:37:43 -0700 From: "Rodney W. Grimes" Message-Id: <199507202137.OAA09980@gndrsh.aac.dev.com> Subject: Re: New options for lastcomm(1) To: wosch@cs.tu-berlin.de Date: Thu, 20 Jul 1995 14:37:43 -0700 (PDT) Cc: current@freebsd.org In-Reply-To: <199507202102.XAA03168@localhost.cs.tu-berlin.de> from "Wolfram Schneider" at Jul 20, 95 11:02:54 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: 667 Sender: current-owner@freebsd.org Precedence: bulk > > > Example: ... > --- 1.1 1995/07/20 13:09:21 > +++ lastcomm.c 1995/07/20 14:49:22 > @@ -29,6 +29,9 @@ > * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > * SUCH DAMAGE. > + * > + * @(#)lastcomm.c 8.1 (Berkeley) 6/6/93 Please do not add UCB SCCS ID strings to files that shipped from UCB without them, this causes later imports to conflict here if CSRG should happen to correct the problem. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Jul 20 20:50:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id UAA05778 for current-outgoing; Thu, 20 Jul 1995 20:50:04 -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 UAA05754 ; Thu, 20 Jul 1995 20:49:57 -0700 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id UAA10144 ; Thu, 20 Jul 1995 20:49:47 -0700 Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id WAA21436; Thu, 20 Jul 1995 22:48:32 -0500 Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Thu, 20 Jul 95 22:48 CDT Received: (from karl@localhost) by Jupiter.mcs.net (8.6.11/8.6.9) id WAA00203; Thu, 20 Jul 1995 22:48:26 -0500 From: Karl Denninger Message-Id: <199507210348.WAA00203@Jupiter.mcs.net> Subject: Re: SUP target for -STABLE, and setup for SUP info? To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Thu, 20 Jul 1995 22:48:26 -0500 (CDT) Cc: karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org In-Reply-To: <199507192148.OAA07950@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 19, 95 02:48:58 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2126 Sender: current-owner@freebsd.org Precedence: bulk > > > > > > > Hi there! > > > > I'd like to set up to get SUP updates of -STABLE, if there is a target for > > it. > > Yes, and there is a sample sup file for getting it. Probably the best > way to get that is to ftp it from the -CURRENT tree (I commited it there > and pulled it into the -STABLE branch). Path name relative to the > base of the -CURRENT src tree is: > src/share/FAQ/extras/stable-supfile > > > Unfortunately for me, I haven't set up SUP before. Anyone got a FAQ for me > > on the way to get this going? > > /usr/share/FAQ/Text/sup.FAQ on any 2.0.5 or later system or > src/share/FAQ/Text/sup.FAQ from a source tree. > > > Thanks in advance! > Your welcome! I guess that -STABLE isn't. I get the same silent hang on the 1742 machine that I get on the other releases, and we've added a panic in biodone to the mix. The 2742 driver problems are not addressed in -STABLE either. -CURRENT is incompatible with anything that touches the NFS areas, unless I want to start completely over and reload the ENTIRE system. Since -CURRENT is such a moving target, this isn't really a good option either, especially when I have no idea when or if -CURRENT is stable. So right now, we have -RELEASE which doesn't run right, -STABLE which isn't, and a -CURRENT which kernels blow up when tickled by -RELEASE's binaries during the startup of NFS and amd. This is getting frustrating, and I'm running out of time and patience. Perhaps this isn't the path we want to go down with our operating system choice. I'm going to give this another week of effort, and if we don't have it stable by then I'm tossing in the towel and going to start on the evaluation process again from scratch. This is costing me far too much sleep. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's only FULL AP Clarinet feed! From owner-freebsd-current Thu Jul 20 22:29:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id WAA08016 for current-outgoing; Thu, 20 Jul 1995 22:29:08 -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 WAA07993 ; Thu, 20 Jul 1995 22:29:04 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id WAA11175; Thu, 20 Jul 1995 22:29:14 -0700 From: "Rodney W. Grimes" Message-Id: <199507210529.WAA11175@gndrsh.aac.dev.com> Subject: Re: SUP target for -STABLE, and setup for SUP info? To: karl@Mcs.Net (Karl Denninger) Date: Thu, 20 Jul 1995 22:29:13 -0700 (PDT) Cc: karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org In-Reply-To: <199507210348.WAA00203@Jupiter.mcs.net> from "Karl Denninger" at Jul 20, 95 10:48:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3176 Sender: current-owner@freebsd.org Precedence: bulk > > > > > > > > > > > > Hi there! > > > > > > I'd like to set up to get SUP updates of -STABLE, if there is a target for > > > it. > > > > Yes, and there is a sample sup file for getting it. Probably the best > > way to get that is to ftp it from the -CURRENT tree (I commited it there > > and pulled it into the -STABLE branch). Path name relative to the > > base of the -CURRENT src tree is: > > src/share/FAQ/extras/stable-supfile > > > > > Unfortunately for me, I haven't set up SUP before. Anyone got a FAQ for me > > > on the way to get this going? > > > > /usr/share/FAQ/Text/sup.FAQ on any 2.0.5 or later system or > > src/share/FAQ/Text/sup.FAQ from a source tree. > > > > > Thanks in advance! > > Your welcome! > > I guess that -STABLE isn't. It is as stable as we have, it is a slight notch above 2.0.5R, and a far lot more so than 2.2-CURRENT. > I get the same silent hang on the 1742 machine that I get on the other > releases, and we've added a panic in biodone to the mix. The 2742 driver > problems are not addressed in -STABLE either. That is correct, we can't address your 1742/2742 problem in _any_ branch until we find what it is that is causing it. Since we have not identified that problem how could we have fixed it??? > -CURRENT is incompatible with anything that touches the NFS areas, unless I > want to start completely over and reload the ENTIRE system. Since -CURRENT > is such a moving target, this isn't really a good option either, especially > when I have no idea when or if -CURRENT is stable. You made a mistake if you tried to go -CURRENT and you wanted stability, we never recomend -CURRENT for a site that is not willing to suffer through some rather serious problems at time. I don't know if someone told you to try this, or just what, but please, stop using -CURRENT to try and get stabalized, that is the wrong route to go as you have already found out :-(. > So right now, we have -RELEASE which doesn't run right, -STABLE which isn't, > and a -CURRENT which kernels blow up when tickled by -RELEASE's binaries > during the startup of NFS and amd. Mixing -RELEASE and -CURRENT is a no no, it is bound to have problems, and I do not recommend even trying that for any reason ever. > This is getting frustrating, and I'm running out of time and patience. > Perhaps this isn't the path we want to go down with our operating system > choice. Perhaps you should get on the -STABLE branch, stay there, and let us work the problems in _one_ tree. > I'm going to give this another week of effort, and if we don't have it > stable by then I'm tossing in the towel and going to start on the evaluation > process again from scratch. This is costing me far too much sleep. We can't get you stabalized if you change the code faster than I can respond to email :-) Please, compile up a make world from the STABLE sup bits, and lets tackle the bug with the 1742/2742 in that set of code without adding all the other complications of what is going on in -current. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Jul 20 23:17:17 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id XAA09761 for current-outgoing; Thu, 20 Jul 1995 23:17:17 -0700 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id XAA09744 ; Thu, 20 Jul 1995 23:17:14 -0700 Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id BAA26860; Fri, 21 Jul 1995 01:17:12 -0500 Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Fri, 21 Jul 95 00:50 CDT Received: (from karl@localhost) by Jupiter.mcs.net (8.6.11/8.6.9) id AAA00306; Fri, 21 Jul 1995 00:50:52 -0500 From: Karl Denninger Message-Id: <199507210550.AAA00306@Jupiter.mcs.net> Subject: Re: SUP target for -STABLE, and setup for SUP info? To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Fri, 21 Jul 1995 00:50:52 -0500 (CDT) Cc: karl@Mcs.Net, karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org In-Reply-To: <199507210529.WAA11175@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 20, 95 10:29:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1688 Sender: current-owner@freebsd.org Precedence: bulk > That is correct, we can't address your 1742/2742 problem in _any_ branch > until we find what it is that is causing it. Since we have not identified > that problem how could we have fixed it??? I thought Peter said it was a VM issue? Or was I mistaken? > Perhaps you should get on the -STABLE branch, stay there, and let us > work the problems in _one_ tree. That's what I'm going to do -- I'm supping the -STABLE branch right now onto one of our development machines in a place that I can work with it and not blow away anything else. > > I'm going to give this another week of effort, and if we don't have it > > stable by then I'm tossing in the towel and going to start on the evaluation > > process again from scratch. This is costing me far too much sleep. > > We can't get you stabalized if you change the code faster than I can > respond to email :-) Please, compile up a make world from the STABLE > sup bits, and lets tackle the bug with the 1742/2742 in that set of > code without adding all the other complications of what is going on > in -current. We're there right now with the exception of a couple of things that we have hacked (the login program, for instance). I'm grabbing a current copy of -STABLE right now via SUP, and have put that tree on auto-update every 6 hours. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-freebsd-current Thu Jul 20 23:30:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id XAA10206 for current-outgoing; Thu, 20 Jul 1995 23:30:33 -0700 Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id XAA10198 ; Thu, 20 Jul 1995 23:30:28 -0700 Received: (from peter@localhost) by haywire.DIALix.COM (8.6.12/8.6.12/DIALix) id OAA03442; Fri, 21 Jul 1995 14:30:08 +0800 Date: Fri, 21 Jul 1995 14:30:07 +0800 (WST) From: Peter Wemm To: Karl Denninger cc: "Rodney W. Grimes" , karl@Mcs.Net, current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SUP target for -STABLE, and setup for SUP info? In-Reply-To: <199507210550.AAA00306@Jupiter.mcs.net> 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, Karl Denninger wrote: > > That is correct, we can't address your 1742/2742 problem in _any_ branch > > until we find what it is that is causing it. Since we have not identified > > that problem how could we have fixed it??? > > I thought Peter said it was a VM issue? Or was I mistaken? There's several problems. The "silent death" on the 1742 is/was a buffer cache leak, of which davigd has just recently committed the fix to -stable. IMHO, the 2742 problem is completely unrelated... (Karl, if you have a ncr controller handy, it might be worth trying that and seeing if that works for you.. I seem to recall you mentioning that the box with the 2742 is a new configuration, perhaps it might be worth trying a few an alternatives until the 2742 problem can be found? The ncr controllers should be pretty close in performance to the 2742's from what I've heard. I know it's not the answer to probable software problem, but it might get you out of a jam..) > > Perhaps you should get on the -STABLE branch, stay there, and let us > > work the problems in _one_ tree. > > That's what I'm going to do -- I'm supping the -STABLE branch right now onto > one of our development machines in a place that I can work with it and not > blow away anything else. That's good news... Please dont give up yet, we need to find the bugs you've run into... -Peter > -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland > Voice: [+1 312 248-8649] | 7 Chicagoland POPs, ISDN, 28.8, much more > Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net > ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! > From owner-freebsd-current Fri Jul 21 00:29:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id AAA12389 for current-outgoing; Fri, 21 Jul 1995 00:29:01 -0700 Received: from world-net.sct.fr (world-net.sct.fr [194.2.128.2]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id AAA12383 for ; Fri, 21 Jul 1995 00:28:58 -0700 Received: from earth (desk1.sct.fr [194.51.76.10]) by world-net.sct.fr (8.6.12/8.6.10) with SMTP id JAA29146 for ; Fri, 21 Jul 1995 09:30:57 +0200 Message-Id: <199507210730.JAA29146@world-net.sct.fr> X-Sender: bourgon@worldnet.net (Unverified) X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jul 1995 09:29:36 -0300 To: current@FreeBSD.ORG From: bourgon@world-net.sct.fr (Support Technique Worldnet) Sender: current-owner@FreeBSD.ORG Precedence: bulk Hello, I have tried to get FreeBSD by ftp://ftp.ibp.fr but I receive this message: ' couldn't open FTP anonymous to ftp.ibp.fr '. I don't know how to solve this problem because it's the same problem with any server. PLEASE HELP Renaud. Support Worldnet Worldnet The French Provider Hot Line Technique : 40.37.32.67 Service Commercial : 40.37.90.90 Fax : 40.37.90.89 France, Paris From owner-freebsd-current Fri Jul 21 01:25:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id BAA15527 for current-outgoing; Fri, 21 Jul 1995 01:25:41 -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 BAA15521 for ; Fri, 21 Jul 1995 01:25:36 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id JAA07808; Fri, 21 Jul 1995 09:22:07 +0100 Date: Fri, 21 Jul 1995 09:22:06 +0100 (BST) From: Doug Rabson To: Terry Lambert cc: Peter Wemm , freebsd-current@freebsd.org Subject: Re: what's going on here? (NFSv3 problem?) In-Reply-To: <9507201832.AA02687@cs.weber.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk On Thu, 20 Jul 1995, Terry Lambert wrote: > > I think that's where the 8K readdir comes from.. > > > > [ ... ] > > > I have not tried that yet, but increasing the mount blocksize from 1K > > to the default of 8K solves the problem. > > > > I then made a very large directory to test that it wasn't because the > > directory was larger than the read packet size. > > > > Perhaps there's a problem with the readdir packet reassembly? > > The bug is in the VOP_READDIR code to work around the stat structure > size differences. > > Where I said it was a year ago when they were being implemented. No, the bug is that nfs_readdir is making larger protocol requests than it used to and the server is puking. NFSv3 allows the server to hint at a size to use. I don't have the rfc for NFSv2 handy so I can't check. It is possible that we are violating the protocol here. It is also possible that the SVR4 server is returning crap data. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Fri Jul 21 01:49:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id BAA16373 for current-outgoing; Fri, 21 Jul 1995 01:49:45 -0700 Received: from sunny.bog.msu.su (sunny.bog.msu.su [158.250.20.1]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id BAA16364 for ; Fri, 21 Jul 1995 01:49:39 -0700 Received: (from dima@localhost) by sunny.bog.msu.su (8.6.12/8.6.12) id MAA09471; Fri, 21 Jul 1995 12:47:23 +0400 Date: Fri, 21 Jul 1995 12:47:18 +0400 (????) From: Dmitry Khrustalev To: current@FreeBSD.ORG Subject: Re: what's going on here? (NFSv3 problem?) 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, Doug Rabson wrote: >No, the bug is that nfs_readdir is making larger protocol requests than >it used to and the server is puking. NFSv3 allows the server to hint at >a size to use. I don't have the rfc for NFSv2 handy so I can't check. >It is possible that we are violating the protocol here. It is also >possible that the SVR4 server is returning crap data. Very possible. Sun has simular problem with SunOS 5.4 - it is the first version using 8k readdirs and it is known to fail on Ultrix and SunOS 3.5 servers. Their solution is system wide option limiting readdir size. -Dima From owner-freebsd-current Fri Jul 21 01:56:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id BAA16688 for current-outgoing; Fri, 21 Jul 1995 01:56:25 -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 BAA16682 for ; Fri, 21 Jul 1995 01:56:22 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA25198; Fri, 21 Jul 1995 10:56:12 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA25855 for freebsd-current@FreeBSD.org; Fri, 21 Jul 1995 10:56:12 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA20663 for freebsd-current@FreeBSD.org; Fri, 21 Jul 1995 08:29:38 +0200 From: J Wunsch Message-Id: <199507210629.IAA20663@uriah.heep.sax.de> Subject: Re: Hmmmm! New error encountered with cpio while building root.flp To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 21 Jul 1995 08:29:37 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) In-Reply-To: <17290.806251694@time.cdrom.com> from "Jordan K. Hubbard" at Jul 20, 95 07:48:14 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: 533 Sender: current-owner@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > I can easily do this, but it still concerns me that the *default* > method for cpio is now essentially broken. This will generate tech > support problems for us and should be fixed. A bug is a bug! > Thanks.. Why not change the default to the safe "newc"? cpio is supposed to read all formats automagically, and Posix does only standardize pax anyway. -- 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 21 01:56:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id BAA16767 for current-outgoing; Fri, 21 Jul 1995 01:56:59 -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 BAA16723 for ; Fri, 21 Jul 1995 01:56:32 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA25194; Fri, 21 Jul 1995 10:56:11 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA25852 for current@freebsd.org; Fri, 21 Jul 1995 10:56:11 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA20706 for current@freebsd.org; Fri, 21 Jul 1995 08:36:39 +0200 From: J Wunsch Message-Id: <199507210636.IAA20706@uriah.heep.sax.de> Subject: Re: New options for lastcomm(1) To: current@freebsd.org Date: Fri, 21 Jul 1995 08:36:38 +0200 (MET DST) Reply-To: current@freebsd.org In-Reply-To: <199507202137.OAA09980@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 20, 95 02:37:43 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: 702 Sender: current-owner@freebsd.org Precedence: bulk As Rodney W. Grimes wrote: > > > + * > > + * @(#)lastcomm.c 8.1 (Berkeley) 6/6/93 > > Please do not add UCB SCCS ID strings to files that shipped from > UCB without them, this causes later imports to conflict here if > CSRG should happen to correct the problem. Any other opinions? Anybody objecting against commiting it? I would otherwise, after fixing minor things (like these SCCSids, and perhaps spelling problems), but i personally don't run accounting and would prefer getting opinions of those who do. The additions would make sense for me. -- 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 21 02:26:05 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id CAA18076 for current-outgoing; Fri, 21 Jul 1995 02:26:05 -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 CAA18070 for ; Fri, 21 Jul 1995 02:26:02 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id CAA11990 for current@freebsd.org; Fri, 21 Jul 1995 02:26:16 -0700 From: "Rodney W. Grimes" Message-Id: <199507210926.CAA11990@gndrsh.aac.dev.com> Subject: Re: New options for lastcomm(1) To: current@freebsd.org Date: Fri, 21 Jul 1995 02:26:15 -0700 (PDT) In-Reply-To: <199507210636.IAA20706@uriah.heep.sax.de> from "J Wunsch" at Jul 21, 95 08:36:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1222 Sender: current-owner@freebsd.org Precedence: bulk > > As Rodney W. Grimes wrote: > > > > > + * > > > + * @(#)lastcomm.c 8.1 (Berkeley) 6/6/93 > > > > Please do not add UCB SCCS ID strings to files that shipped from > > UCB without them, this causes later imports to conflict here if > > CSRG should happen to correct the problem. > > Any other opinions? Anybody objecting against commiting it? I would > otherwise, after fixing minor things (like these SCCSids, and perhaps > spelling problems), but i personally don't run accounting and would > prefer getting opinions of those who do. I did not evaluate any other parts of that diff, as I also do not run accounting (who I am I going to bill, myself :-)), so didn't pay a whole lot of attention to the new functionality, though I probably should have. > 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 :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Jul 21 02:53:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id CAA19119 for current-outgoing; Fri, 21 Jul 1995 02:53:08 -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 CAA19106 for ; Fri, 21 Jul 1995 02:53:01 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA28372; Fri, 21 Jul 1995 11:52:57 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA26320 for freebsd-current@FreeBSD.org; Fri, 21 Jul 1995 11:52:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id LAA21157 for freebsd-current@FreeBSD.org; Fri, 21 Jul 1995 11:20:11 +0200 From: J Wunsch Message-Id: <199507210920.LAA21157@uriah.heep.sax.de> Subject: dip for BSD To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 21 Jul 1995 11:20:11 +0200 (MET DST) 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: 2624 Sender: current-owner@FreeBSD.org Precedence: bulk It comes up from time to time, and recently somebody posted that he's got a `dip' (dialup IP) program for BSD ready. I've fetched the files from the rather limited ftp server of a small German university and David has put them up into freefall's incoming directory (anon ftp). It would be nice if people who are interested could give it a try, and it would be even nicer :) if they could make this a FreeBSD `port' (even though we certainly cannot rely on the Uni Clausthal ftp server -- they allow for 5 German and 3 abroad ftp connections during the business hours :-(( ). Here's a copy of the original announcement: > From: Joachim Bartz > Newsgroups: comp.unix.bsd.netbsd.announce > Subject: Ann: dip -dialup IP handler for bsd > Supersedes: <199505090036.CAA00872@verleihnix.rz.tu-clausthal.de> > Followup-To: poster > Date: 8 May 1995 18:09:06 -0700 > Organization: University of California, Berkeley > Lines: 30 > Sender: cgd@agate.berkeley.edu > Approved: netbsd-announce-request@agate.berkeley.edu > Message-ID: <199505090045.CAA00930@verleihnix.rz.tu-clausthal.de> > NNTP-Posting-Host: agate.berkeley.edu > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > To: netbsd-announce@agate.berkeley.edu > X-Mailer: ELM [version 2.4 PL24] > Content-Length: 996 > > > DIP is mainly a tool to establish a SLIP connection. It handles all > the necessary actions to set up the tty port and the modem, dial out > and finally build up a SLIP connection between the tty port and the > kernel. To do so, dip offers an own very simple command language (a > mostly complete description can be found in the man page). > > Dip can handle both incoming and outgoing connections using password > security for incoming connections. > > This dip version was ported from Linux to NetBSD, although it will > work on other BSDish systems as well. > > > It can be found at this site: > ftp.rz.tu-clausthal.de in /pub/unix/tuc > > Filenames: > bsddip-1.01.ReadMe > bsddip-1.01.tar.Z > > > Joachim Bartz > > ------------------------------------------------------------------------------ > Joachim Bartz A person with one watch knows what time it is; > injb@sun.rz.tu-clausthal.de a person with two watches is never sure. > ------------------------------------------------------------------------------ > Note: the actual files are already version 1.02 now. -- 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 21 02:53:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id CAA19191 for current-outgoing; Fri, 21 Jul 1995 02:53:48 -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 CAA19184 for ; Fri, 21 Jul 1995 02:53:42 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA28425; Fri, 21 Jul 1995 11:53:20 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA26349; Fri, 21 Jul 1995 11:53:19 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id LAA21266; Fri, 21 Jul 1995 11:34:00 +0200 From: J Wunsch Message-Id: <199507210934.LAA21266@uriah.heep.sax.de> Subject: Re: your mail To: bourgon@world-net.sct.fr (Support Technique Worldnet) Date: Fri, 21 Jul 1995 11:34:00 +0200 (MET DST) Cc: current@FreeBSD.ORG In-Reply-To: <199507210730.JAA29146@world-net.sct.fr> from "Support Technique Worldnet" at Jul 21, 95 09:29:36 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: 569 Sender: current-owner@FreeBSD.ORG Precedence: bulk As Support Technique Worldnet wrote: > > Hello, > I have tried to get FreeBSD by ftp://ftp.ibp.fr but I receive this message: > ' couldn't open FTP anonymous to ftp.ibp.fr '. > I don't know how to solve this problem because it's the same problem with > any server. Do you have a bit more of input? E.g. some description of what did you do to setup your network connection, or some debug messages from the Alt-F2 screen. -- 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 21 04:36:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id EAA24182 for current-outgoing; Fri, 21 Jul 1995 04:36:22 -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 EAA24169 for ; Fri, 21 Jul 1995 04:36:09 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA31644 for freebsd-current@freebsd.org; Fri, 21 Jul 1995 21:33:50 +1000 Date: Fri, 21 Jul 1995 21:33:50 +1000 From: Bruce Evans Message-Id: <199507211133.VAA31644@godzilla.zeta.org.au> To: freebsd-current@freebsd.org Subject: Re: Hmmmm! New error encountered with cpio while building root.flp Sender: current-owner@freebsd.org Precedence: bulk >Why not change the default to the safe "newc"? cpio is supposed to >read all formats automagically, and Posix does only standardize pax >anyway. POSIX.1 specifies certain tar and cpio formats. Note that gnu tar implements the format specified in an early draft of POSIX.1 and handles the standard format poorly for extraction because it thinks it is nonstandard. Gnu cpio implements the POSIX.1 format. See cpio/README. The handling of rdevs is mostly implementation-defined. Zeroing them for regular files is allowed. Bruce From owner-freebsd-current Fri Jul 21 05:47:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id FAA26988 for current-outgoing; Fri, 21 Jul 1995 05:47:23 -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 FAA26971 ; Fri, 21 Jul 1995 05:47:18 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id FAA27081; Fri, 21 Jul 1995 05:46:39 -0700 To: Karl Denninger cc: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes), karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org Subject: Re: SUP target for -STABLE, and setup for SUP info? In-reply-to: Your message of "Thu, 20 Jul 1995 22:48:26 CDT." <199507210348.WAA00203@Jupiter.mcs.net> Date: Fri, 21 Jul 1995 05:46:39 -0700 Message-ID: <27079.806330799@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk > I guess that -STABLE isn't. Well, perhaps we were overly optimistic with the naming; I think "stabilizing" is a better description since we're obviously not really going to be happy with its stability until we've reached the point where 2.1 can be released, and that's still a month or two away. A lot can happen in that time. > I get the same silent hang on the 1742 machine that I get on the other > releases, and we've added a panic in biodone to the mix. The 2742 driver > problems are not addressed in -STABLE either. We needed to shake this out in -current a little longer before bringing it across. I'll ask Justin what his plans for this code are. > This is getting frustrating, and I'm running out of time and patience. > Perhaps this isn't the path we want to go down with our operating system > choice. > > I'm going to give this another week of effort, and if we don't have it > stable by then I'm tossing in the towel and going to start on the evaluation > process again from scratch. This is costing me far too much sleep. I understand. Please do also understand that we are doing everything we can to work with you on this and don't have many people who are actually paid to do this kind of work. Progress is therefore constrained by whatever free time the members have to devote to it. If do we manage to get these problems worked out for you before you pull the ejection handle, perhaps it's time to think about moving FreeBSD Inc's support-for-money plans forward. If I could afford to hire just ONE serious systems hacker to look into problems like this full-time, it would be a significant help. We just need to figure out how willing the various commercial users like yourself are to to underwrite such an effort. This also isn't an attempt on my part to put the screws to anyone, this is simply an honest assessment of our current state affairs. I would love to be able to throw someone at your problem full-time, but that's a luxury I don't really have with a volunteer crew, nor can I expect people to jump at the crack of a whip. This is problem that isn't going to go away and will, in fact, only get worse as more commercial interests move to FreeBSD. I would welcome your (or anyone else's) suggestions. Jordan From owner-freebsd-current Fri Jul 21 06:27:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA29445 for current-outgoing; Fri, 21 Jul 1995 06:27:50 -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 GAA29425 ; Fri, 21 Jul 1995 06:27:44 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id GAA27268; Fri, 21 Jul 1995 06:27:05 -0700 cc: Karl Denninger , rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes), karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org Subject: Re: SUP target for -STABLE, and setup for SUP info? In-reply-to: Your message of "Fri, 21 Jul 1995 05:46:39 PDT." <27079.806330799@time.cdrom.com> Date: Fri, 21 Jul 1995 06:27:05 -0700 Message-ID: <27266.806333225@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk Please forgive all the typos (I counted 4 in the last two paragraphs alone!) in that last message.. I shouldn't try to address serious issues at 5:46AM, just minutes after waking up.. :-) Jordan From owner-freebsd-current Fri Jul 21 06:28:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA29553 for current-outgoing; Fri, 21 Jul 1995 06:28:54 -0700 Received: from vishnu.alias.net (jpunix.com [198.133.124.1]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id GAA29536 ; Fri, 21 Jul 1995 06:28:45 -0700 Received: (from perry@localhost) by vishnu.alias.net (8.6.11/8.6.6) id IAA12337; Fri, 21 Jul 1995 08:28:42 -0500 Date: Fri, 21 Jul 1995 08:28:41 -0500 (CDT) From: "John A. Perry" To: FreeBSD Questions , FreeBSD Current Subject: getting ports? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I was FTP'ing to get the port for MH and I experienced some add behavior. I went to pub/FreeBSD/2.0.5-RELEASE/ports/mail and found the MH directory where it should be. I then type "get mh.tar.Z" to have the directory structure tarred and compressed and I kept getting the message "mh.tar.Z" does not exist. Is FreeBSD.org using wuftp? I thought they were. Anyway the ability to tar and compress directories for ftp transfer has stopped working. John Perry - KG5RG - perry@jpunix.com - PGP-encrypted e-mail welcome! WWW - http://www.jpunix.com PGP 2.62 key for perry@jpunix.com is on the keyservers. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by mkpgp, a Pine/PGP interface. iQEVAwUBMA+reaghiWHnUu4JAQG1hwf+IZOeTmVgydev/HJZOHtbXT4/6EmlOTbI 8aufi6YDtZRbxJU+IqDHJb6zNRZGSuTHFfCS+DmwYtZ+jYx+RANZzqtz8WtAwWe2 FGuv0gZb6u1FvCK9I1Zj3zWEl3Df0S4Z86FmbVhcgOXcQh3nvelxln+tO+KFlVTQ w85F33jyf6roDliuCOZca6TNTAMn+57ZKttV7lw5HRx331zWtEyXvos3TY/4FSvx zJxfjm0nzXb/tK4mfZTHlTkS0w1dwA38tOslCfAC0XAmpo8D376yXX15svYGfpNl 5W3xMjRuQ+dxcMQhqvZx9X9puKkqVCYbVNW4Z+5ky6hh2Rr+jNd6sg== =1sC6 -----END PGP SIGNATURE----- From owner-freebsd-current Fri Jul 21 10:46:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id KAA14014 for current-outgoing; Fri, 21 Jul 1995 10:46:32 -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 KAA14006 for ; Fri, 21 Jul 1995 10:46:31 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA06208; Fri, 21 Jul 95 11:39:05 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9507211739.AA06208@cs.weber.edu> Subject: Re: what's going on here? (NFSv3 problem?) To: dfr@render.com (Doug Rabson) Date: Fri, 21 Jul 95 11:39:04 MDT Cc: peter@haywire.dialix.com, freebsd-current@freebsd.org In-Reply-To: from "Doug Rabson" at Jul 21, 95 09:22:06 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > No, the bug is that nfs_readdir is making larger protocol requests than > it used to and the server is puking. NFSv3 allows the server to hint at > a size to use. I don't have the rfc for NFSv2 handy so I can't check. > It is possible that we are violating the protocol here. It is also > possible that the SVR4 server is returning crap data. The NFS READDIR is a special case of the getdents call interface. The getdents call interface is not guaranteed to work on objects smaller than a full (512b) directory block, since this is the directory compation boundry in UFS. This is actually the one remaining file system dependency in the directory read code. The typical behaviour is to use the file system block size, or the system page size, whichever is larger, since the directory block is guaranteed by the file system interface to be some power of two value smaller or equal to the page size. The problem is *bound* to occur when the VOP uses entry-at-a-time retrieval, or odd-entry-retrieval over the NFSlink with the current code. The complication in the NFSv3 protocol is the extension that we (well, it was me, when I used to work at Novell) added to the directory entry retrieval interface to return blocks of entries and stat information simultaneously, and which was added to NFSv3 by Sun right after we demonstrated the code doubling the speed of ls in a NUC/NWU (NetWare UNIX Client/WetWare for UNIX) environment (several years ago). The fact is that neither Novell nor I originated this idea: it's been present in AppleTalk and several Intel protocols from day one... a rather old idea, actually. The code hacks for the per entry at a time retrieval for the NFSv2 code *do not work* for buffer sizes larger than the page size, a fact I pointed out when the changes were rolled in (knowing full well that I wanted to do NetWare work on FreeBSD and knowing that NFSv3 was on its way). This isn't even considering the potential race conditions which are caused by the stat operation in the FS itself being seperate from the readdir operation, or by directory compaction occuring between non-block requests. The first race condition can only be resolved by changing the interface; this is probably something that wants to be done anyway, since file operations should probably have stat information associated at all times. The potential error here is that another caller could delte the file before the stat information was obtained and (in the case of only one entry in the return buffer), the directory must be locally retraversed on the server from the last offset. Even then, you are relatively screwed if what is happening is a copy/unlink/rename operation. The second race condition, above, can be handled internally only with an interface other than readdir, or with a substantial change to the operation of readdir, at the very least. The way you do a resyncronization over a (potential) directory compaction is you find the block that the next entry offset is in, then read entries forward until the offset equals or exceeds the offset requested, saving one-behind. If the offset is equal, you return the entry, otherwise you return the entry from the previous offset (assuming that the entry was compacted back). This can result in duplicate entries, which the client must filter out, since it has state information, and it is unacceptable in the search for an exact match to omit the file being searched for. 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. 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". 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 Fri Jul 21 11:44:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id LAA17086 for current-outgoing; Fri, 21 Jul 1995 11:44:19 -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 LAA17075 for ; Fri, 21 Jul 1995 11:44:10 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id TAA12680; Fri, 21 Jul 1995 19:46:19 +0100 Date: Fri, 21 Jul 1995 19:46:16 +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: <9507211739.AA06208@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: > > No, the bug is that nfs_readdir is making larger protocol requests than > > it used to and the server is puking. NFSv3 allows the server to hint at > > a size to use. I don't have the rfc for NFSv2 handy so I can't check. > > It is possible that we are violating the protocol here. It is also > > possible that the SVR4 server is returning crap data. > > The NFS READDIR is a special case of the getdents call interface. > > The getdents call interface is not guaranteed to work on objects > smaller than a full (512b) directory block, since this is the > directory compation boundry in UFS. This is actually the one > remaining file system dependency in the directory read code. > > The typical behaviour is to use the file system block size, or > the system page size, whichever is larger, since the directory > block is guaranteed by the file system interface to be some > power of two value smaller or equal to the page size. > > The problem is *bound* to occur when the VOP uses entry-at-a-time > retrieval, or odd-entry-retrieval over the NFSlink with the current > code. All this is fine. I know perfectly well that NFSv2 tends to encourage non-aligned accesses to directories and also why it can be a bad thing for UFS. AFAIR, the last time this topic came up was when I was modifying the 2.0 NFS server code to work properly for cd9660 filesystems. I added code at that time which, at least, stopped it from jumping into the middle of a directory entry. If a block was compacted between requests, the client may receive duplicate entries or may miss some entries. It will not receive corrupt filenames. I believe that the original problem that brought the subject up was completely different to this. The client had mounted a filesystem with 1024 byte read/write sizes and then tried to read a directory in 8k blocks. The server got scared and returned strange values to the client. This is backed up by the fact that the problem went away when the read/write sizes were increased to 8k. I looked in rfc1094 and didn't see any references to read size applying to the readdir request. Of course, that doesn't mean that some servers don't interpret the rfc that way. > > The complication in the NFSv3 protocol is the extension that we > (well, it was me, when I used to work at Novell) added to the > directory entry retrieval interface to return blocks of entries > and stat information simultaneously, and which was added to NFSv3 > by Sun right after we demonstrated the code doubling the speed > of ls in a NUC/NWU (NetWare UNIX Client/WetWare for UNIX) > environment (several years ago). The fact is that neither Novell > nor I originated this idea: it's been present in AppleTalk and > several Intel protocols from day one... a rather old idea, actually. > > The code hacks for the per entry at a time retrieval for the NFSv2 > code *do not work* for buffer sizes larger than the page size, a > fact I pointed out when the changes were rolled in (knowing full > well that I wanted to do NetWare work on FreeBSD and knowing that > NFSv3 was on its way). This was an NFSv2 mount. > > This isn't even considering the potential race conditions which > are caused by the stat operation in the FS itself being seperate > from the readdir operation, or by directory compaction occuring > between non-block requests. > > The first race condition can only be resolved by changing the > interface; this is probably something that wants to be done > anyway, since file operations should probably have stat information > associated at all times. The potential error here is that another > caller could delte the file before the stat information was obtained > and (in the case of only one entry in the return buffer), the > directory must be locally retraversed on the server from the last > offset. Even then, you are relatively screwed if what is happening > is a copy/unlink/rename operation. > > The second race condition, above, can be handled internally only > with an interface other than readdir, or with a substantial change > to the operation of readdir, at the very least. The way you do > a resyncronization over a (potential) directory compaction is > you find the block that the next entry offset is in, then read > entries forward until the offset equals or exceeds the offset > requested, saving one-behind. If the offset is equal, you return > the entry, otherwise you return the entry from the previous offset > (assuming that the entry was compacted back). This can result in > duplicate entries, which the client must filter out, since it has > state information, and it is unacceptable in the search for an > exact match to omit the file being searched for. 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. > > 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. > > 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. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Fri Jul 21 13:06:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id NAA22005 for current-outgoing; Fri, 21 Jul 1995 13:06:31 -0700 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id NAA21998 ; Fri, 21 Jul 1995 13:06:28 -0700 Received: from Jupiter.mcs.net (Jupiter.mcs.net [192.160.127.89]) by kitten.mcs.com (8.6.10/8.6.9) with ESMTP id PAA11892; Fri, 21 Jul 1995 15:06:24 -0500 Received: (from karl@localhost) by Jupiter.mcs.net (8.6.11/8.6.9) id PAA02125; Fri, 21 Jul 1995 15:06:23 -0500 From: Karl Denninger Message-Id: <199507212006.PAA02125@Jupiter.mcs.net> Subject: Re: SUP target for -STABLE, and setup for SUP info? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 21 Jul 1995 15:06:23 -0500 (CDT) Cc: karl@Mcs.Net, rgrimes@gndrsh.aac.dev.com, karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org In-Reply-To: <27079.806330799@time.cdrom.com> from "Jordan K. Hubbard" at Jul 21, 95 05:46:39 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2778 Sender: current-owner@freebsd.org Precedence: bulk > > This is getting frustrating, and I'm running out of time and patience. > > Perhaps this isn't the path we want to go down with our operating system > > choice. > > > > I'm going to give this another week of effort, and if we don't have it > > stable by then I'm tossing in the towel and going to start on the evaluation > > process again from scratch. This is costing me far too much sleep. > > I understand. Please do also understand that we are doing everything > we can to work with you on this and don't have many people who are > actually paid to do this kind of work. Progress is therefore > constrained by whatever free time the members have to devote to it. > > If do we manage to get these problems worked out for you before you > pull the ejection handle, perhaps it's time to think about moving > FreeBSD Inc's support-for-money plans forward. If I could afford to > hire just ONE serious systems hacker to look into problems like this > full-time, it would be a significant help. We just need to figure out > how willing the various commercial users like yourself are to to > underwrite such an effort. > > This also isn't an attempt on my part to put the screws to anyone, > this is simply an honest assessment of our current state affairs. I > would love to be able to throw someone at your problem full-time, but > that's a luxury I don't really have with a volunteer crew, nor can I > expect people to jump at the crack of a whip. This is problem that > isn't going to go away and will, in fact, only get worse as more > commercial interests move to FreeBSD. I would welcome your (or anyone > else's) suggestions. > > Jordan I'm happy to pay for *actual* support which I receive, but my feel on this is that I am not going to pay for a staffer full-time if the work that he or she produces goes back to *everyone*. That is, I won't pay for everyone *else*'s fix. But I will pay a reasonable support charge *if and only if* I get actual fixes to problems like this in a contemporary fashion. If someone wants to start up a firm that does this kind of thing, I say more power to them. However, my willingness to pay is directly correlated to the quality of the fixes and the timeliness of what we receive. If I'm going to pay big bucks, then I want the fixes (and the rest of that person's time) to myself. If its much more reasonable, then so am I. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-freebsd-current Fri Jul 21 13:43:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id NAA23185 for current-outgoing; Fri, 21 Jul 1995 13:43:51 -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 NAA23177 for ; Fri, 21 Jul 1995 13:43:46 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA06811; Fri, 21 Jul 95 14:36:30 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9507212036.AA06811@cs.weber.edu> Subject: Re: what's going on here? (NFSv3 problem?) To: dfr@render.com (Doug Rabson) Date: Fri, 21 Jul 95 14:36:29 MDT Cc: peter@haywire.dialix.com, freebsd-current@freebsd.org In-Reply-To: from "Doug Rabson" at Jul 21, 95 07:46:16 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > 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. 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. > > 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. 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 Fri Jul 21 17:34:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id RAA01778 for current-outgoing; Fri, 21 Jul 1995 17:34:14 -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 RAA01759 ; Fri, 21 Jul 1995 17:34:07 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id RAA21240; Fri, 21 Jul 1995 17:33:27 -0700 To: Karl Denninger cc: rgrimes@gndrsh.aac.dev.com, karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org Subject: Re: SUP target for -STABLE, and setup for SUP info? In-reply-to: Your message of "Fri, 21 Jul 1995 15:06:23 CDT." <199507212006.PAA02125@Jupiter.mcs.net> Date: Fri, 21 Jul 1995 17:33:27 -0700 Message-ID: <21238.806373207@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk > I'm happy to pay for *actual* support which I receive, but my feel on this > is that I am not going to pay for a staffer full-time if the work that he or > she produces goes back to *everyone*. Sorry if I suggested that you'd be expected to pay for a full-time staffer. Such a staffer would not only be too expensive for a single company to support ($40K/yr for a support contract would be a little excessive, to say the least :-) but it also wouldn't make much sense. You don't NEED somebody on the job for MCSNet full-time, you need someone available for bursts of activity when problems are encountered and then, most likely, you don't need anyone at all for awhile. So it's not very useful to debate whether or not the work of said staffer would be "owned" by a single firm - I'm not talking about that kind of money or that kind of easy accountability for the individual (or, more likely, individuals) in question. It's more likely that the support team will be working multiple problems at once and the fixes they generate may cover multiple overlapping areas of concern for more companies than just your own. > That is, I won't pay for everyone *else*'s fix. But I will pay a reasonable > support charge *if and only if* I get actual fixes to problems like this in > a contemporary fashion. Of course. Such a support contract will only work for you and any other companies participating if fixes are made promptly and competently. When the support team isn't working on problems, I'd expect it to also work on generally improving the system and enhancing it in ways that EVERYONE, and that includes yourself, can benefit from. Otherwise, I don't see much point in establishing such an organization. We're a free software effort and any and all such organizations should be set up with our own unique model somewhere in mind. I don't think that this precludes being accountable or prompt with the commercial partners in any way, especially as there will be a significant motivation on the part of those working on this to make the whole concept work. Most software companies have multiple programmers working for little more than a paycheck which, as any programmer knows, isn't always the most motivating of factors. Being able to work for both a paycheck and some "higher goal" (e.g. the results of your work being touted far and wide for a demonstrably "good cause") would represent the best of all possible worlds for many, and if I can put such an organization together then I think that it would not only work, but also work rather well. > power to them. However, my willingness to pay is directly correlated to the > quality of the fixes and the timeliness of what we receive. Natch. I understand this fully. > If I'm going to pay big bucks, then I want the fixes (and the rest of that > person's time) to myself. If its much more reasonable, then so am I. I think that asking you to pay big bucks would actually be counter-productive to us both. It would raise your expectations unreasonably and also put those in the project in something of a bind as they felt somewhat co-opted by the deal. I think "much more reasonable" is exactly that. Just out of curiousity (and I'll direct this question to any and all listening here, not just Karl), what would you consider "reasonable" and what kind of response time would you expect for it? If I can get some reasonable estimates for the size of the potential customer base and the amount of incoming capital they'd represent, then I think that it's entirely possible that I could turn this from idle conjecture into reality. The Internet has also made it possible to "hire" people to work at home, and as long as their work meets some reasonable standard for response time and quality then I also think that I could put such an organization together with far less overhead than a traditional one with offices, 401K plans, etc. The resultant savings could then be passed back to the customer and/or used to finance longer-term goals for the project. Thoughts? Figures? I think this would be a very significant step forward for FreeBSD, but it's also something that I can't without at least a little help. Jordan From owner-freebsd-current Sat Jul 22 03:10:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id DAA18084 for current-outgoing; Sat, 22 Jul 1995 03:10:37 -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 DAA18078 for ; Sat, 22 Jul 1995 03:10:31 -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 <55369>; Sat, 22 Jul 1995 12:10:21 +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 XAA24371; Thu, 20 Jul 1995 23:11:59 +0200 Message-Id: <199507202111.XAA24371@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: David Greenman cc: current@freebsd.org Subject: Re: cvs strings Date: Thu, 20 Jul 1995 23:11:58 +0200 From: "Julian Stacey " Sender: current-owner@freebsd.org Precedence: bulk > From: David Greenman > > >I had hoped to be able to prune down my current src tree > >by establishing per file symbolic links to the new CD-ROM > >(as I've done on previous FreeBSD CDs) > > > >This time round, many files are just subtly different enough > >to defeat my automatic compare & delete tool, here is a typical example: > > diff -c bin/csh/char.c /pub/cd/src/bin/csh/char.c > > *** bin/csh/char.c Wed May 3 15:38:54 1995 > > --- /cd/src/bin/csh/char.c Fri Sep 23 14:53:46 1994 > > *************** > > *** 30,36 **** > > ! * $Id: char.c,v 1.2 1994/09/24 02:53:46 davidg Exp $ > > --- 30,36 ---- > > ! * char.c,v 1.2 1994/09/24 02:53:46 davidg Exp > > > >These changes seem most unfortunate. > >Can we avoid such slight alterations next time round ? > >It seems wasteful on disc space, sup & ctm bandwidth, > >to put a different stamp on a file that has identical contents. > > > >BTW This is a general CVS policy question with no particular reference > >to davidg, who I guess just happened to be in this example > > > >Those tiny strings changes "$Id: " & " $" convey no extra information to me, > >but prevent people with CD-ROMS saving space. > > This definately tops my "most silly things said" list. Of course, I didn't > make such a gratuitous change. The identifier ($Id$, $Log$, etc...) keywords > are automatically removed as part of the cvs export operation, which is how > the final source tree is created. Sorry, but I _can_ see those strings in my current/src, which is why I asked. I've done a compare & delete of a spare copy of my current src tree (not CVS tree), against the CD-ROM, about half the files are identical, du -s -k shows: freebsd/current/src 113096 freebsd/current_src_reduced_against_cd 42005 I'd expect about 90/95 % identical so soon after a release, ie my current_src_reduced_against_cd should be largely symbolic links, with ~5% files, 95% sym links I don't have a CVS tree here, so have not done a local extract that could have failed, I merely have a ctm src tree, As you say those strings get removed by an export, & one can see them in ctm/src, but not on the CD, how come about half the files are the same, & half are not ? Is the ctm src tree produced by export, could some export in the past have failed to strip half the strings ? Here's another example: diff -c etc/services /pub/cd/freebsd-2.0.5.d2/usr//./src/etc/services *** freebsd/current/src/etc/services Wed May 3 16:19:16 1995 --- /pub/cd/freebsd-2.0.5.d2/usr//./src/etc/services Sat Apr 8 15:02:08 1995 *************** *** 9,15 **** # Kerberos services are for Kerberos v4, and are unofficial. Sites running # v5 should uncomment v5 entries and comment v4 entries. # ! # $Id: services,v 1.11 1995/04/09 03:02:08 ache Exp $ # From: @(#)services 5.8 (Berkeley) 5/9/91 # # WELL KNOWN PORT NUMBERS --- 9,15 ---- # Kerberos services are for Kerberos v4, and are unofficial. Sites running # v5 should uncomment v5 entries and comment v4 entries. # ! # services,v 1.11 1995/04/09 03:02:08 ache Exp # From: @(#)services 5.8 (Berkeley) 5/9/91 # # WELL KNOWN PORT NUMBERS To Summarise: How come 40% of the files are different already ? Why does services have $Id: in CTM tree, but not in CD tree ? Julian --- Julian Stacey jhs@freebsd.org From owner-freebsd-current Sat Jul 22 09:10:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id JAA01003 for current-outgoing; Sat, 22 Jul 1995 09:10:09 -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 JAA00993 for ; Sat, 22 Jul 1995 09:10:08 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.6.11/8.6.11) with SMTP id IAA29105 for ; Sat, 22 Jul 1995 08:30:56 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA25259; Sat, 22 Jul 1995 17:13:20 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id RAA00728 for current@freebsd.org; Sat, 22 Jul 1995 17:30:16 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id MAA21429 for current@freebsd.org; Fri, 21 Jul 1995 12:47:00 +0200 From: J Wunsch Message-Id: <199507211047.MAA21429@uriah.heep.sax.de> Subject: Re: New options for lastcomm(1) To: current@freebsd.org Date: Fri, 21 Jul 1995 12:46:59 +0200 (MET DST) Reply-To: current@freebsd.org In-Reply-To: <199507210926.CAA11990@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jul 21, 95 02:26:15 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: 868 Sender: current-owner@freebsd.org Precedence: bulk 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 agree that the current lastcomm(1) doesn't seem to suffer from featuremania. Comparing to a SysV acctcom(1), even Wolfram's proposal ain't too much. But a good starting point to the very least. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Jul 22 09:10:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id JAA01027 for current-outgoing; Sat, 22 Jul 1995 09:10:12 -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 JAA00997 for ; Sat, 22 Jul 1995 09:10:09 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id CAA09535 for current@freebsd.org; Sun, 23 Jul 1995 02:10:01 +1000 From: michael butler Message-Id: <199507221610.CAA09535@asstdc.scgt.oz.au> Subject: vat_audio.h: No such file .. To: current@freebsd.org Date: Sun, 23 Jul 1995 02:09:58 +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: 125 Sender: current-owner@freebsd.org Precedence: bulk Attempts to compile -current kernel presently fails with ../../i386/i386/conf.c:596: vat_audio.h: No such file .. michael From owner-freebsd-current Sat Jul 22 09:24:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id JAA02033 for current-outgoing; Sat, 22 Jul 1995 09:24:40 -0700 Received: from quirk.com (quirk.com [198.82.204.56]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id JAA02027 for ; Sat, 22 Jul 1995 09:24:38 -0700 Received: (from cstruble@localhost) by quirk.com (8.6.11/8.6.9) id MAA05520 for current@freebsd.org; Sat, 22 Jul 1995 12:24:56 -0400 Message-Id: <199507221624.MAA05520@quirk.com> Subject: 950722 current kernel won't compile To: current@freebsd.org Date: Sat, 22 Jul 1995 12:24:55 -0400 (EDT) From: cstruble@vt.edu Reply-To: cstruble@vt.edu X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 567 Sender: current-owner@freebsd.org Precedence: bulk I'm trying to compile current, and there's a missing header file 'vat_audio.h' used in conf.c. I seem to remember it being removed recently since vat is being replaced by sockets (I don't have the message still around though.) For now I'm just going to create an empty file and chug along. See ya later, Craig -- Craig Struble - Grad Student, Consultant, | World's most versatile C program Student ACM Co-President, Virginia Tech | (*nix version) Email - cstruble@vt.edu | URL - http://acm.vt.edu/~cstruble/ | #include "/dev/tty" From owner-freebsd-current Sat Jul 22 12:09:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id MAA00549 for current-outgoing; Sat, 22 Jul 1995 12:09:09 -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 MAA00495 for ; Sat, 22 Jul 1995 12:09:03 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id KAA29476 for ; Sat, 22 Jul 1995 10:51:04 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA14436 for current@freebsd.org; Sun, 23 Jul 1995 03:41:43 +1000 Date: Sun, 23 Jul 1995 03:41:43 +1000 From: Bruce Evans Message-Id: <199507221741.DAA14436@godzilla.zeta.org.au> To: current@FREEBSD.ORG Subject: ${INSTALL} ${INSTALLFLAGS} Sender: current-owner@FREEBSD.ORG Precedence: bulk Garrett has implemented a -C flag to `install' that says to avoid copying if the target compares equal with the source. We need to use this flag in all Makefiles. I think the right method is: sys.mk: INSTALL ?= install # same as now bsd.own.mk: INSTALL_COMPARE ?= -C bsd.own.mk: INSTALL_COPY ?= -c # replaces COPY bsd.own.mk: INSTALLFLAGS ?= # user options bsd.prog.mk etc: INSTALL += ${INSTALL_COMPARE} ${INSTALL_COPY} \ ${INSTALLFLAGS} # sometimes more Makefiles: ${INSTALL} [-c] ... There is little point in putting `${INSTALL} ${INSTALLFLAGS} [-c]' in all Makefiles. It mainly makes the commands longer. If different options are required then plain `install' can be used. This would ignore any special setting of INSTALL, but special settings have never really worked anyway. Makefiles have to use -c to install source files in case ${INSTALL_COPY} is set to empty. Some currently use ${COPY} in more or less the right places. I have changed 81 Makefiles to use `${INSTALL}' instead of `install'. Complain if you want anything different. Bruce From owner-freebsd-current Sat Jul 22 12:17:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id MAA01097 for current-outgoing; Sat, 22 Jul 1995 12:17:47 -0700 Received: from ctsd1.cts.com (ctsd1.cts.com [192.188.72.181]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id MAA01091 for ; Sat, 22 Jul 1995 12:17:45 -0700 Received: (from root@localhost) by ctsd1.cts.com (8.6.11/8.6.9) id MAA17083 for freebsd-current@freebsd.org; Sat, 22 Jul 1995 12:20:55 -0700 From: Dan Sherwin Message-Id: <199507221920.MAA17083@ctsd1.cts.com> Subject: Re: 950722 current kernel won't compile To: freebsd-current@freebsd.org Date: Sat, 22 Jul 1995 12:20:54 -0700 (PDT) In-Reply-To: <199507221624.MAA05520@quirk.com> from "cstruble@vt.edu" at Jul 22, 95 12:24:55 pm Organization: CTS Network Services Phone: (619)-637-3637 Reply-to: ctsdan@cts.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 940 Sender: current-owner@freebsd.org Precedence: bulk cstruble@vt.edu writes: > > I'm trying to compile current, and there's a missing header file > 'vat_audio.h' used in conf.c. I seem to remember it being removed > recently since vat is being replaced by sockets (I don't have the > message still around though.) > > For now I'm just going to create an empty file and chug along. > See ya later, > Craig > -- > Craig Struble - Grad Student, Consultant, | World's most versatile C program > Student ACM Co-President, Virginia Tech | (*nix version) > Email - cstruble@vt.edu | > URL - http://acm.vt.edu/~cstruble/ | #include "/dev/tty" > I am having the same error. I am about to create an empty file and go as well, but if someone knows a real reason, that would be good. }Dan ___ ____ ___ / / /__ Network | Tel (619) 637-3637 | Mail: ctsdan@cts.com /__ / ___/ Services | Fax (619) 637-3630 | WWW: http://www.cts.com From owner-freebsd-current Sat Jul 22 14:40:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id OAA05273 for current-outgoing; Sat, 22 Jul 1995 14:40:12 -0700 Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id OAA05266 for ; Sat, 22 Jul 1995 14:40:08 -0700 Received: from freebsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1) id AA23614; Sat, 22 Jul 95 23:39:58 +0200 Received: by freebsd.first.gmd.de (XAA12919); Sat, 22 Jul 1995 23:39:33 +0200 From: Gerd Truschinski Message-Id: <199507222139.XAA12919@freebsd.first.gmd.de> Subject: Need some help with 'rxvt' To: current@freebsd.org Date: Sat, 22 Jul 1995 23:39:33 +0159 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 778 Sender: current-owner@freebsd.org Precedence: bulk Hi there, I am running the 950622-SNAP. I jumped over to fvwm and rxvt to some space. But now I have some problems: Every time I run 'more filename' the output of 'more' will disapear after the compleation of the command. I know that this has some- thing to do with the 'alternate screeen' of rxvt. If I 'su', the output of 'more' is readable after the execution of 'more'. But not as a normal user. I don't know where to look further. I.e.: I want to see the last output lines of 'more', 'less' or 'vi'. /gT/ BTW: Is the 'disklabel - newfs a second disk'-problem gone now? -- Gerd Truschinski | Yes, this is the sort of scenario I gt@freebsd.first.gmd.de | think up to amuse myself in the evenings. emma@cs.tu-berlin.de | -- with confirmation from Larisa From owner-freebsd-current Sat Jul 22 16:44:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id QAA09811 for current-outgoing; Sat, 22 Jul 1995 16:44:18 -0700 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id QAA09805 ; Sat, 22 Jul 1995 16:44:17 -0700 Received: from Jupiter.mcs.net (Jupiter.mcs.net [192.160.127.89]) by kitten.mcs.com (8.6.10/8.6.9) with ESMTP id SAA05586; Sat, 22 Jul 1995 18:44:15 -0500 Received: (from karl@localhost) by Jupiter.mcs.net (8.6.11/8.6.9) id SAA05789; Sat, 22 Jul 1995 18:44:13 -0500 From: Karl Denninger Message-Id: <199507222344.SAA05789@Jupiter.mcs.net> Subject: Re: SUP target for -STABLE, and setup for SUP info? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 22 Jul 1995 18:44:13 -0500 (CDT) Cc: karl@Mcs.Net, rgrimes@gndrsh.aac.dev.com, karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org In-Reply-To: <21238.806373207@time.cdrom.com> from "Jordan K. Hubbard" at Jul 21, 95 05:33:27 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1896 Sender: current-owner@freebsd.org Precedence: bulk > I think that asking you to pay big bucks would actually be > counter-productive to us both. It would raise your expectations > unreasonably and also put those in the project in something of a bind > as they felt somewhat co-opted by the deal. I think "much more > reasonable" is exactly that. Just out of curiousity (and I'll direct > this question to any and all listening here, not just Karl), what > would you consider "reasonable" and what kind of response time would > you expect for it? > > If I can get some reasonable estimates for the size of the potential > customer base and the amount of incoming capital they'd represent, > then I think that it's entirely possible that I could turn this from > idle conjecture into reality. The Internet has also made it possible > to "hire" people to work at home, and as long as their work meets some > reasonable standard for response time and quality then I also think > that I could put such an organization together with far less overhead > than a traditional one with offices, 401K plans, etc. The resultant > savings could then be passed back to the customer and/or used to > finance longer-term goals for the project. > > Thoughts? Figures? I think this would be a very significant step > forward for FreeBSD, but it's also something that I can't without at > least a little help. > > Jordan I'd be willing to put a few hundred bucks a year (say, $500) into a support contract if it got me what I considered reasonable turn-around times. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-freebsd-current Sat Jul 22 18:00:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id SAA11210 for current-outgoing; Sat, 22 Jul 1995 18:00:41 -0700 Received: from deep-thought.demos.su (deep-thought.demos.su [192.91.186.133]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id SAA11200 for ; Sat, 22 Jul 1995 18:00:38 -0700 Received: by deep-thought.demos.su id EAA05633; (8.6.11/D) Sun, 23 Jul 1995 04:30:55 +0400 To: current@freebsd.org Cc: pst@shockwave.com Message-ID: Organization: DEMOS Date: Sun, 23 Jul 1995 04:30:54 +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: Errors compiling secure/libtelnet Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1132 Sender: current-owner@freebsd.org Precedence: bulk cc -O2 -m486 -DHAS_CGETENT -DENCRYPTION -DAUTHENTICATION -DKRB4 -DKRB4_ENCPWD -DDES_ENCRYPTION -I/usr/include/kerberosIV -c /usr/src/secure/lib/libtelnet/auth.c -o auth.o /usr/src/secure/lib/libtelnet/auth.c:167: `AUTHTYPE_KRB4_ENCPWD' undeclared here (not in a function) /usr/src/secure/lib/libtelnet/auth.c:167: initializer element for `authenticators[2].type' is not constant /usr/src/secure/lib/libtelnet/auth.c:170: warning: initialization from incompatible pointer type /usr/src/secure/lib/libtelnet/auth.c:171: warning: initialization from incompatible pointer type /usr/src/secure/lib/libtelnet/auth.c:173: warning: initialization from incompatible pointer type *** Error code 1 Stop. AUTHTYPE_KRB4_ENCPWD not declared to but seems to be there. Can anybody who know its value add this define to ? -- 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 Sat Jul 22 18:11:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id SAA11712 for current-outgoing; Sat, 22 Jul 1995 18:11: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 SAA11695 ; Sat, 22 Jul 1995 18:11:30 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id SAA01132; Sat, 22 Jul 1995 18:10:18 -0700 To: Karl Denninger cc: rgrimes@gndrsh.aac.dev.com, karl@mcs.com, current@freebsd.org, peter@haywire.DIALix.COM, freebsd-hackers@freebsd.org Subject: Re: SUP target for -STABLE, and setup for SUP info? In-reply-to: Your message of "Sat, 22 Jul 1995 18:44:13 CDT." <199507222344.SAA05789@Jupiter.mcs.net> Date: Sat, 22 Jul 1995 18:10:18 -0700 Message-ID: <1130.806461818@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk > I'd be willing to put a few hundred bucks a year (say, $500) into a support > contract if it got me what I considered reasonable turn-around times. I had about $600 in mind, but we won't quibble about the $100.. :-) And now the next (and obvious) question - what would you consider to be a reasonable turn-around time? :) Jordan From owner-freebsd-current Sat Jul 22 20:29:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id UAA16625 for current-outgoing; Sat, 22 Jul 1995 20:29:52 -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 UAA16619 for ; Sat, 22 Jul 1995 20:29:50 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id UAA00914 for ; Sat, 22 Jul 1995 20:29:34 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Sat, 22 Jul 1995 22:29:46 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Jul 1995 22:29:49 -0500 To: current@freebsd.org From: rkw@dataplex.net (Richard Wackerbarth) Subject: Where is -STABLE Sender: current-owner@freebsd.org Precedence: bulk I vaguely remember some message referencing -STABLE now being available via sup. Where can I find the supfile that describes the collection? Also, is there an archive of messages to these lists? If so, where is it? ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Sat Jul 22 21:24:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id VAA17967 for current-outgoing; Sat, 22 Jul 1995 21:24:54 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id VAA17961 for ; Sat, 22 Jul 1995 21:24:52 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id aa25517; 23 Jul 95 5:24 +0100 Received: from bagpuss.demon.co.uk by post.demon.co.uk id aa08759; 23 Jul 95 5:24 +0100 Received: (karl@localhost) by bagpuss.demon.co.uk (3.1/3.1) id FAA11274; Sun, 23 Jul 1995 05:24:39 +0100 From: Karl Strickland Message-Id: <199507230424.FAA11274@bagpuss.demon.co.uk> Subject: Re: 950722 current kernel won't compile To: ctsdan@cts.com Date: Sun, 23 Jul 1995 05:24:39 +0100 (BST) Cc: freebsd-current@freebsd.org In-Reply-To: <199507221920.MAA17083@ctsd1.cts.com> from "Dan Sherwin" at Jul 22, 95 12:20:54 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1170 Sender: current-owner@freebsd.org Precedence: bulk > > cstruble@vt.edu writes: > > > > I'm trying to compile current, and there's a missing header file > > 'vat_audio.h' used in conf.c. I seem to remember it being removed > > recently since vat is being replaced by sockets (I don't have the > > message still around though.) > > > > For now I'm just going to create an empty file and chug along. > > See ya later, > > Craig > > -- > > Craig Struble - Grad Student, Consultant, | World's most versatile C program > > Student ACM Co-President, Virginia Tech | (*nix version) > > Email - cstruble@vt.edu | > > URL - http://acm.vt.edu/~cstruble/ | #include "/dev/tty" > > > > I am having the same error. I am about to create an empty file and go as > well, but if someone knows a real reason, that would be good. > > }Dan This is fixed now - Bruce Evans committed a fix to conf.c. Cheers, Karl -- ------------------------------------------+----------------------------------- Mailed using ELM on FreeBSD | Karl Strickland PGP 2.3a Public Key Available. | Internet: karl@bagpuss.demon.co.uk |