From owner-freebsd-current Sun Apr 2 00:06:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA26056 for current-outgoing; Sun, 2 Apr 1995 00:06:39 -0800 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA26050 for ; Sun, 2 Apr 1995 00:06:39 -0800 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.9/8.6.9) with SMTP id AAA00203; Sun, 2 Apr 1995 00:06:25 -0800 Message-Id: <199504020806.AAA00203@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Richard Chang cc: FreeBSD-current@freefall.cdrom.com Subject: Re: sup not working In-reply-to: Your message of "Sat, 01 Apr 1995 23:37:40 PST." Date: Sun, 02 Apr 1995 00:06:24 -0800 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk > > I can't get sup working when I switch from slip to ppp earlier >today while everything under ppp works fine. Is the supserver at >freefall down or is something wrong on my end? > >This is all I get... > >bigbang# sup -vzo supfile >SUP 8.26 (4.3 BSD) for file supfile at Apr 1 23:37:42 >It just sits here and does nothing afterwards... > > Thanks for any help in advance! > >--richardc > Try again after running these commands as root: sysctl -w net.inet.tcp.rfc1323=0 sysctl -w net.inet.tcp.rfc1644=0 > -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Sun Apr 2 00:37:44 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA28039 for current-outgoing; Sun, 2 Apr 1995 00:37:44 -0800 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA28033 for ; Sun, 2 Apr 1995 00:37:43 -0800 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id AAA27034; Sun, 2 Apr 1995 00:37:28 -0800 Date: Sun, 2 Apr 1995 00:37:25 -0800 From: Richard Chang To: "Justin T. Gibbs" cc: FreeBSD-current@freefall.cdrom.com Subject: Re: sup not working In-Reply-To: <199504020806.AAA00203@estienne.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sun, 2 Apr 1995, Justin T. Gibbs wrote: > >bigbang# sup -vzo supfile > >SUP 8.26 (4.3 BSD) for file supfile at Apr 1 23:37:42 > >It just sits here and does nothing afterwards... > Try again after running these commands as root: > > sysctl -w net.inet.tcp.rfc1323=0 > sysctl -w net.inet.tcp.rfc1644=0 Thanks! It works now... What was the original problem anyways? Also, I noticed that sometimes up messes up with some files that is supped but when I tried resupping, it doesn't fix those files.. I even tried to rm -rf /usr/sup and resup and the same thing happened... Is there anyway to have sup make sure I get a exact copy of the file? > > -- > Justin T. Gibbs > ============================================== > TCS Instructional Group - Programmer/Analyst 1 > Cory | Po | Danube | Volga | Parker | Torus > ============================================== > Thanks... -richardc From owner-freebsd-current Sun Apr 2 00:41:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA28082 for current-outgoing; Sun, 2 Apr 1995 00:41:42 -0800 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA28076 for ; Sun, 2 Apr 1995 00:41:41 -0800 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.9/8.6.9) with SMTP id AAA00330; Sun, 2 Apr 1995 00:41:27 -0800 Message-Id: <199504020841.AAA00330@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Richard Chang cc: FreeBSD-current@freefall.cdrom.com Subject: Re: sup not working In-reply-to: Your message of "Sun, 02 Apr 1995 00:37:25 PST." Date: Sun, 02 Apr 1995 00:41:27 -0800 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk > > >On Sun, 2 Apr 1995, Justin T. Gibbs wrote: > >> >bigbang# sup -vzo supfile >> >SUP 8.26 (4.3 BSD) for file supfile at Apr 1 23:37:42 >> >It just sits here and does nothing afterwards... >> Try again after running these commands as root: >> >> sysctl -w net.inet.tcp.rfc1323=0 >> sysctl -w net.inet.tcp.rfc1644=0 > > Thanks! It works now... What was the original problem anyways? FreeBSD supports transaction TCP. Almost no other vendor does. Most terminal servers' SLIP protocols aren't up to snuff with the new protocol and choke. So, if you're sitting behind a SLIP link, you should turn off these features (ala sysctl) and inform your ISP that they should contact their terminal server vendor for patches. >Also, I noticed that sometimes sup messes up with some files that is supped >but when I tried resupping, it doesn't fix those files.. I even tried to >rm -rf /usr/sup and resup and the same thing happened... Is there anyway to >have sup make sure I get a exact copy of the file? I'm working on a checksumming option to sup, but the only way to make it resup a file that it has timestamped is to "touch" the file. > >> >> -- >> Justin T. Gibbs >> ============================================== >> TCS Instructional Group - Programmer/Analyst 1 >> Cory | Po | Danube | Volga | Parker | Torus >> ============================================== >> > > Thanks... > >-richardc > > -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Sun Apr 2 01:17:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA28732 for current-outgoing; Sun, 2 Apr 1995 01:17:19 -0800 Received: from nlsys.demon.co.uk (nlsys.demon.co.uk [158.152.125.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA28726 for ; Sun, 2 Apr 1995 01:17:15 -0800 Received: (from dfr@localhost) by nlsys.demon.co.uk (8.6.10/8.6.9) id LAA00193; Sun, 2 Apr 1995 11:07:41 +0100 Date: Sun, 2 Apr 1995 11:07:41 +0100 (BST) From: Doug Rabson To: "Justin T. Gibbs" cc: current@FreeBSD.org Subject: Re: Bug fixes to aic7xxx driver In-Reply-To: <199503311418.GAA02986@estienne.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Fri, 31 Mar 1995, Justin T. Gibbs wrote: > I just did some rather extensive patching to the aic7xxx driver. I'd > appreciate it if anyone running this driver would pick up the new files > and send me feedback. This fixes the "QOUTCOUNT==0" problem as well as > (I believe) fixes some of the tagged queuing problems of the last release. > > The files you need: > > ftp.cdrom.com:/pub/FreeBSD/FreeBSD-current/src/sys/i386/scsi/* > ftp.cdrom.com:/pub/FreeBSD/FreeBSD-current/src/sys/i386/isa/aic7770.c > ftp.cdrom.com:/pub/FreeBSD/FreeBSD-current/src/sys/pci/aic7870.c > ftp.cdrom.com:/pub/FreeBSD/FreeBSD-current/src/sys/gnu/misc/aic7xxx/* > > Make sure the files you grab are dated the 31st. I'm not sure what time > the sup update happens over there, so be sure you don't pick up the old > copies. I just tried this and it doesn't get past the probe at all. All I get is "cmd failed" messages. I had a brief check in the debugger and ahc_poll and ahcintr are being called. I haven't looked at it in any detail though. -- Doug Rabson Mail: dfr@nlsys.demon.co.uk Phone: +44 181 951 1891 From owner-freebsd-current Sun Apr 2 01:31:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA28988 for current-outgoing; Sun, 2 Apr 1995 01:31:21 -0800 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 BAA28959 for ; Sun, 2 Apr 1995 01:31:06 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA19416; Sun, 2 Apr 1995 11:30:47 +0200 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id LAA07108 for freebsd-current@FreeBSD.org; Sun, 2 Apr 1995 11:30:44 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id KAA00380 for freebsd-current@FreeBSD.org; Sun, 2 Apr 1995 10:35:34 +0200 From: J Wunsch Message-Id: <199504020835.KAA00380@uriah.heep.sax.de> Subject: sio.c Id 1.81 now even worse :-( To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 2 Apr 1995 10:35:33 +0200 (MET DST) 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: 3907 Sender: current-owner@FreeBSD.org Precedence: bulk The problem as reported yesterday ain't fixed. (I gonna re-open the PR, too.) I'm still getting Apr 2 10:06:21 uriah slattach[219]: cannot get carrier state: Inappropriate \ ioctl for device Apr 2 10:06:21 uriah slattach[219]: Waiting for carrier on /dev/cuaa1 (sl-1) If i continue to ifconfig/route add default by hand (worked with sio.c two or three revisions before), and try the first ping across the interface, i get a panic now: > gdb -k kernel /var/crash/vmcore.9 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 1f1000 current pcb at 1c5ba8 panic: b_to_q to a clist with no reserved cblocks #0 boot (arghowto=260) at ../../i386/i386/machdep.c:807 807 dumppcb.pcb_ptd = rcr3(); (kgdb) where #0 boot (arghowto=260) at ../../i386/i386/machdep.c:807 #1 0xf0113945 in panic () #2 0xf010174d in db_panic () #3 0xf0101636 in db_command () #4 0xf01017b5 in db_command_loop () #5 0xf0104108 in db_trap () #6 0xf0188136 in kdb_trap () #7 0xf01924b4 in trap (frame={tf_es = -266600432, tf_ds = -266600432, tf_edi = -266579176, tf_esi = -266579176, tf_ebp = -266649836, tf_isp = -266649864, tf_ebx = 256, tf_edx = -266829007, tf_ecx = 2000, tf_eax = -1, tf_trapno = 3, tf_err = 0, tf_eip = -266828970, tf_cs = -266665976, tf_eflags = 582, tf_esp = -266829023, tf_ss = -267306757}) at ../../i386/i386/trap.c:346 #8 0xf01889d1 in calltrap () #9 0xf011393f in panic () #10 0xf011c5c4 in b_to_q (src=0xf060912c "ÀE", amount=14, clistp=0xf01c5318) at ../../kern/tty_subr.c:400 #11 0xf01ae6d0 in siopoll () at ../../i386/isa/sio.c:1571 #12 0xf01aecdb in comwakeup (chan=0x0) at ../../i386/isa/sio.c:1905 #13 0xf0108640 in softclock () #14 0xf0189d27 in doreti_swi () #15 0xf0191dac in cpu_switch () (kgdb) up 10 #10 0xf011c5c4 in b_to_q (src=0xf060912c "ÀE", amount=14, clistp=0xf01c5318) at ../../kern/tty_subr.c:400 400 panic("b_to_q to a clist with no reserved cblocks"); (kgdb) list 395 * If there are no cblocks assigned to this clist yet, 396 * then get one. 397 */ 398 if (clistp->c_cl == NULL) { 399 if (clistp->c_cbreserved < 1) 400 panic("b_to_q to a clist with no reserved cblocks"); 401 cblockp = cblock_alloc(); 402 clistp->c_cbcount = 1; 403 clistp->c_cf = clistp->c_cl = cblockp->c_info; 404 clistp->c_cc = 0; (kgdb) up #11 0xf01ae6d0 in siopoll () at ../../i386/isa/sio.c:1571 1571 com->delta_error_counts[CE_TTY_BUF_OVERFLOW] (kgdb) list 1566 if ( (tp->t_state & TS_CAN_BYPASS_L_RINT) 1567 && !(tp->t_state & TS_LOCAL)) { 1568 tk_nin += incc; 1569 tk_rawcc += incc; 1570 tp->t_rawcc += incc; 1571 com->delta_error_counts[CE_TTY_BUF_OVERFLOW] 1572 += b_to_q((char *)buf, incc, &tp->t_rawq); 1573 ttwakeup(tp); 1574 if (tp->t_state & TS_TTSTOP 1575 && (tp->t_iflag & IXANY (kgdb) quit > ident ../../i386/isa/sio.c ../../i386/isa/sio.c: $Id: sio.c,v 1.81 1995/04/01 12:01:13 ache Exp $ Is anyone interested in the core dump? I'm resorting to an older kernel now until it's fixed (i really need SLIP). -- 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 Apr 2 03:07:58 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA00181 for current-outgoing; Sun, 2 Apr 1995 03:07:58 -0700 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA00175 for ; Sun, 2 Apr 1995 03:07:56 -0700 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.9/8.6.9) with SMTP id DAA00559; Sun, 2 Apr 1995 03:07:36 -0700 Message-Id: <199504021007.DAA00559@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Doug Rabson cc: current@FreeBSD.org Subject: Re: Bug fixes to aic7xxx driver In-reply-to: Your message of "Sun, 02 Apr 1995 11:07:41 BST." Date: Sun, 02 Apr 1995 03:07:36 -0700 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk >On Fri, 31 Mar 1995, Justin T. Gibbs wrote: > >> I just did some rather extensive patching to the aic7xxx driver. I'd >> appreciate it if anyone running this driver would pick up the new files >> and send me feedback. This fixes the "QOUTCOUNT==0" problem as well as >> (I believe) fixes some of the tagged queuing problems of the last release. >> >> The files you need: >> >> ftp.cdrom.com:/pub/FreeBSD/FreeBSD-current/src/sys/i386/scsi/* >> ftp.cdrom.com:/pub/FreeBSD/FreeBSD-current/src/sys/i386/isa/aic7770.c >> ftp.cdrom.com:/pub/FreeBSD/FreeBSD-current/src/sys/pci/aic7870.c >> ftp.cdrom.com:/pub/FreeBSD/FreeBSD-current/src/sys/gnu/misc/aic7xxx/* >> >> Make sure the files you grab are dated the 31st. I'm not sure what time >> the sup update happens over there, so be sure you don't pick up the old >> copies. > >I just tried this and it doesn't get past the probe at all. All I get is >"cmd failed" messages. I had a brief check in the debugger and ahc_poll >and ahcintr are being called. I haven't looked at it in any detail though. > Did you get the sequencer code that was dated from today? I introduced a bug that was only fixed today. You may also have to disable tagged queuing by #ifdef 0'ing the detection of tagged queuing devices in the ahc_done routine. (try this after you have verified that you have the latest code). >-- >Doug Rabson Mail: dfr@nlsys.demon.co.uk > Phone: +44 181 951 1891 > -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Sun Apr 2 03:56:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA00746 for current-outgoing; Sun, 2 Apr 1995 03:56:06 -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 DAA00734; Sun, 2 Apr 1995 03:55:27 -0700 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id MAA23104; Sun, 2 Apr 1995 12:54:50 +0200 Message-Id: <199504021054.MAA23104@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: bugs@FreeBSD.org, current@FreeBSD.org Subject: Playing audio CD's on FreeBSD Date: Sun, 02 Apr 1995 12:54:49 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk Hi (JMZ?) I have been trying to get some soothing sounds out of my CD-ROM drive for a while now, with little success. My CDROM is a NEC210 SCSI, the SCSI controller is an Adaptec 1542C(something), and it works perfectly in CD9660-mode. Here is a typical session: > bash# cdplay cd0 > CD>status > status track minute second frame > -1 134684768 -272638632 13788 4128 > cdplay: Bad file descriptor > CD>play > cdplay: Bad file descriptor > CD>tochdr > cdplay: Bad file descriptor > CD>tocentry > cdplay: Bad file descriptor > CD>quit At the same time, I get a nasty kernel message repeatedly interspersed with the above. Here it is, extracted from /var/log/messages: > Apr 2 12:38:35 grunt /kernel: cd0(aha0:6:0): ILLEGAL REQUEST csi:30,20,0,0 asc:20,0Invalid command operation code Help! I am no good at this SCSI/CDROM stuff. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Sun Apr 2 04:36:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA02086 for current-outgoing; Sun, 2 Apr 1995 04:36:33 -0700 Received: from nlsys.demon.co.uk (nlsys.demon.co.uk [158.152.125.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA02080 for ; Sun, 2 Apr 1995 04:36:28 -0700 Received: (from dfr@localhost) by nlsys.demon.co.uk (8.6.10/8.6.9) id NAA00132; Sun, 2 Apr 1995 13:23:29 +0100 Date: Sun, 2 Apr 1995 13:23:29 +0100 (BST) From: Doug Rabson To: "Justin T. Gibbs" cc: current@FreeBSD.org Subject: Re: Bug fixes to aic7xxx driver In-Reply-To: <199504021007.DAA00559@estienne.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sun, 2 Apr 1995, Justin T. Gibbs wrote: > > > >I just tried this and it doesn't get past the probe at all. All I get is > >"cmd failed" messages. I had a brief check in the debugger and ahc_poll > >and ahcintr are being called. I haven't looked at it in any detail though. > > > > Did you get the sequencer code that was dated from today? I introduced a > bug that was only fixed today. > > You may also have to disable tagged queuing by #ifdef 0'ing the detection > of tagged queuing devices in the ahc_done routine. (try this after you > have verified that you have the latest code). I just tried this and it works fine, tagged command queueing included. Thanks! The QOUTCNT error is also gone. -- Doug Rabson Mail: dfr@nlsys.demon.co.uk Phone: +44 181 951 1891 From owner-freebsd-current Sun Apr 2 05:40:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA02876 for current-outgoing; Sun, 2 Apr 1995 05:40:28 -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 FAA02863 for ; Sun, 2 Apr 1995 05:40:17 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA28321; Sun, 2 Apr 1995 14:40:00 +0200 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id OAA08376 for freebsd-current@FreeBSD.org; Sun, 2 Apr 1995 14:39:58 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id OAA00530 for freebsd-current@FreeBSD.org; Sun, 2 Apr 1995 14:35:33 +0200 From: J Wunsch Message-Id: <199504021235.OAA00530@uriah.heep.sax.de> Subject: sio & SLIP ok. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 2 Apr 1995 14:35:32 +0200 (MET DST) 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: 448 Sender: current-owner@FreeBSD.org Precedence: bulk Sorry for the confusion, forget my mail about the persisting sio problem. I realized too late that i've only seen Andrey's commit message, but the nightly CTM unpack didn't yet unpack the latest revision of sio.c. Everything works now, and i don't get a panic when routing packets out of the SLIP line. -- 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 Apr 2 05:40:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA02886 for current-outgoing; Sun, 2 Apr 1995 05:40:54 -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 FAA02879 for ; Sun, 2 Apr 1995 05:40:48 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA28308; Sun, 2 Apr 1995 14:39:57 +0200 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id OAA08367 for freebsd-current@FreeBSD.org; Sun, 2 Apr 1995 14:39:55 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id MAA01484 for freebsd-current@FreeBSD.org; Sun, 2 Apr 1995 12:00:15 +0200 From: J Wunsch Message-Id: <199504021000.MAA01484@uriah.heep.sax.de> Subject: Re: sup not working To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 2 Apr 1995 12:00:14 +0200 (MET DST) In-Reply-To: <199504020841.AAA00330@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Apr 2, 95 00:41:27 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: 750 Sender: current-owner@FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote: > > FreeBSD supports transaction TCP. Almost no other vendor does. Most > terminal servers' SLIP protocols aren't up to snuff with the new protocol > and choke. So, if you're sitting behind a SLIP link, you should turn off > these features (ala sysctl) and inform your ISP that they should contact > their terminal server vendor for patches. Don't pass me the conical hat (i don't have any clue what T/TCP might be good for and how i could make use of it), but i'm sitting behind a FreeBSD 1.1.5.1 box as my SLIP dialup point -- so i guess i don't have to disable it, right? -- 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 Apr 2 07:33:24 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA19733 for current-outgoing; Sun, 2 Apr 1995 07:33:24 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA19715 for ; Sun, 2 Apr 1995 07:33:20 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id HAA06876; Sun, 2 Apr 1995 07:37:19 -0700 Date: Sun, 2 Apr 1995 07:37:19 -0700 Message-Id: <199504021437.HAA06876@trout.sri.MT.net> To: Richard Chang Cc: FreeBSD-current@freefall.cdrom.com Subject: Re: sup not working In-Reply-To: References: Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Richard Chang writes: > > I can't get sup working when I switch from slip to ppp earlier > today while everything under ppp works fine. Is the supserver at > freefall down or is something wrong on my end? Hmmm.... > SUP 8.26 (4.3 BSD) for file supfile at Apr 1 23:37:42 ^^^^^^^ > It just sits here and does nothing afterwards... Ahh, you're the victim of an evil April Fool's joke. *grin* Seriously though, the sup server has been hanging an awful lot, so if SUP doesn't work right, dont' be so sure it's not the server hanging. Try again for a few days to see if it works, and if it doesn't then I think a re-post is warranted. Nate From owner-freebsd-current Sun Apr 2 09:56:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA04382 for current-outgoing; Sun, 2 Apr 1995 09:56:55 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA04376 for ; Sun, 2 Apr 1995 09:56:52 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id AAA21838; Mon, 3 Apr 1995 00:56:18 +0800 Date: Mon, 3 Apr 1995 00:56:17 +0800 (CST) From: Brian Tao To: Bruce Evans cc: freebsd-current@FreeBSD.org Subject: Re: New installation notes In-Reply-To: <199504011920.FAA18604@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, 2 Apr 1995, Bruce Evans wrote: > > It depends on the boot manager. A good one should allow booting from > all nonempty partitions on all drives. How about the FreeBSD one? :) Maybe I'll just install Warp's boot manager, that one is quite nice. -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sun Apr 2 10:12:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA04971 for current-outgoing; Sun, 2 Apr 1995 10:12:45 -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 KAA04956 for ; Sun, 2 Apr 1995 10:12:40 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA18410; Mon, 3 Apr 1995 03:09:27 +1000 Date: Mon, 3 Apr 1995 03:09:27 +1000 From: Bruce Evans Message-Id: <199504021709.DAA18410@godzilla.zeta.org.au> To: bde@zeta.org.au, taob@gate.sinica.edu.tw Subject: Re: New installation notes Cc: freebsd-current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> It depends on the boot manager. A good one should allow booting from >> all nonempty partitions on all drives. > How about the FreeBSD one? :) Maybe I'll just install Warp's >boot manager, that one is quite nice. We don't have one, at least not one invented here. I'd like one in the boot blocks, i.e., not in the MBR. Bruce From owner-freebsd-current Sun Apr 2 10:29:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA05431 for current-outgoing; Sun, 2 Apr 1995 10:29:03 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA05425 for ; Sun, 2 Apr 1995 10:29:00 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id BAA21881; Mon, 3 Apr 1995 01:29:13 +0800 Date: Mon, 3 Apr 1995 01:29:09 +0800 (CST) From: Brian Tao cc: FREEBSD-CURRENT-L Subject: Re: New installation notes In-Reply-To: <199504011724.JAA10069@estienne.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sat, 1 Apr 1995, Justin T. Gibbs wrote: > > >to make it work. I suspect it may have something to do with changing > >its IRQ from 12 to 10, and/or pulling out the SB/AWE32 sound card > >(which is on IRQ 5) and the attached NEC Multispin 4x CD-ROM drive. > > Did you ever reattach the Nec 4x? It was either that or a conflicting > IRQ. Not yet. Next week is mostly holidays (there are three one-day holidays in Taiwan that week, go figure), but if the guy is in, I'll go up and try reattaching it. I need to reboot the system with a new kernel anyway to see how the new aic7xxx stuff works, as well as checking out support for his SB16 card and the CD-ROM attached to it. Ah, just finished compiling... 10:55 for a kernel build. Over twice as fast as my 486, *sigh* ... > >sailing once the kernel could recognize the Adaptec. I ran iozone to > >check it out but it could only muster around 1.7MB/sec read/write > >while my 486DX4/100 NCR-equipped system hits 2.5-2.6MB/sec. Both used > > Were you using the exact same drives? The best test would be to place > the controllers in the same machine and test against the same exact drives. > I'm been getting ~5MB/s out of the driver for some time now to a Quantum > Empire 2100. The Pentium has twin Quantum Maverick 540's and my machine (with the NCR controller) has a Quantum Empire 1080. I'll bring my drive up to the Pentium and do another comparison. It is quite noticeably slower for any heavy disk operations. Untarring the kernel source dist and running config(8) are both noticeably faster on my 486. > > BTW, the proud owner is thoroughly impressed with what he can do > >with his machine now. :) In fact, he hinted that wiping out his > >MS-DOS drive and replacing it with more UNIX file space is a definite > >possibility. :) > > Another convert!!! :) *clap* *clap* *clap* :) He had bought Windows NT and was quite disappointed with it. Then the Computing Center spent three days installing Windows for Workgroups, mostly for naught. So one afternoon of work to transform his PC into a real UNIX-breathing, TCP/IP-speaking X11R6 workstation was nothing short of a miracle in his eyes. ;-) Another CC support guy was up there with me, and he was quite impressed with FreeBSD ("Wow, you mean it comes with a C *and* C++ compiler FOR FREE?!?", etc.) so I might have several more converts in a couple of weeks. :) -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sun Apr 2 11:15:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA06494 for current-outgoing; Sun, 2 Apr 1995 11:15:08 -0700 Received: from simon.chi.il.us (simon.chi.il.us [199.245.227.17]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA06487 for ; Sun, 2 Apr 1995 11:15:06 -0700 Received: by simon.chi.il.us (Smail3.1.29.1 #3) id m0rvTFh-000NB2C; Sun, 2 Apr 95 12:15 CDT Message-Id: Date: Sun, 2 Apr 95 12:15 CDT From: steve@simon.chi.il.us (Steven E. Piette) To: gibbs@estienne.CS.Berkeley.EDU, jkh@freefall.cdrom.com Subject: Re: Ethernet interface AUI, UTP and BNC ports Cc: wollman@halloran-eldar.lcs.mit.edu, steve@simon.chi.il.us, current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > From freefall.cdrom.com!owner-freebsd-current Sun Apr 2 05:02:53 1995 > Sender: freefall.cdrom.com!owner-freebsd-current > X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol > To: "Justin T. Gibbs" > cc: Garrett Wollman , > steve@simon.chi.il.us (Steven E. Piette), current@FreeBSD.org > Subject: Re: Ethernet interface AUI, UTP and BNC ports > Date: Sat, 01 Apr 1995 22:38:56 -0800 > From: "Jordan K. Hubbard" > Sender: current-owner@FreeBSD.org > Content-Length: 255 > > > Can you give a rough outline of the work needed so that others can start > > it if you don't have the time? I'm so sick of answering the link2 questions, > > that I'd like to make this happen as soon as possible. > > What's the story with this? > > Jordan > I've started the work and have most of the changes to ifconfig done. I'm waiting on some feedback from Garrett to see if I going in the right direction before starting on the drivers. Steve From owner-freebsd-current Sun Apr 2 11:18:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA06533 for current-outgoing; Sun, 2 Apr 1995 11:18:20 -0700 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA06527 for ; Sun, 2 Apr 1995 11:18:19 -0700 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.9/8.6.9) with SMTP id LAA01567; Sun, 2 Apr 1995 11:17:52 -0700 Message-Id: <199504021817.LAA01567@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: sup not working In-reply-to: Your message of "Sun, 02 Apr 1995 12:00:14 +0200." <199504021000.MAA01484@uriah.heep.sax.de> Date: Sun, 02 Apr 1995 11:17:51 -0700 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk >As Justin T. Gibbs wrote: >> >> FreeBSD supports transaction TCP. Almost no other vendor does. Most >> terminal servers' SLIP protocols aren't up to snuff with the new protocol >> and choke. So, if you're sitting behind a SLIP link, you should turn off >> these features (ala sysctl) and inform your ISP that they should contact >> their terminal server vendor for patches. > >Don't pass me the conical hat (i don't have any clue what T/TCP might >be good for and how i could make use of it), but i'm sitting behind a >FreeBSD 1.1.5.1 box as my SLIP dialup point -- so i guess i don't have >to disable it, right? > It wasn't in FreeBSD until 2.0R+. >-- >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. ;-) -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Sun Apr 2 11:18:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA06542 for current-outgoing; Sun, 2 Apr 1995 11:18:41 -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 LAA06510; Sun, 2 Apr 1995 11:16:59 -0700 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id UAA26848; Sun, 2 Apr 1995 20:16:27 +0200 Message-Id: <199504021816.UAA26848@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: current@FreeBSD.org, bugs@FreeBSD.org Subject: yppush does not compile... Date: Sun, 02 Apr 1995 20:16:27 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk Hi Does this file (yp.h) need to be installed, or does there just need to be a path to it? There are two of them, gnu/libexec/ypxfr/yp.h and gnu/usr/sbin/ypserv/yp.h, which have _lots_ of diffs, but seem to have had the same beginnings. > Script started on Sun Apr 2 20:08:22 1995 > bash# make > cc -O2 -c /a/src/gnu/usr.bin/yppush/yppush.c > /a/src/gnu/usr.bin/yppush/yppush.c:31: yp.h: No such file or directory > *** Error code 1 > > Stop. > bash# exit > exit > > Script done on Sun Apr 2 20:08:28 1995 M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Sun Apr 2 11:26:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA06651 for current-outgoing; Sun, 2 Apr 1995 11:26:42 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA06645 for ; Sun, 2 Apr 1995 11:26:40 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id CAA23174; Mon, 3 Apr 1995 02:26:48 +0800 Date: Mon, 3 Apr 1995 02:26:47 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: New installation notes In-Reply-To: <199504021709.DAA18410@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, 3 Apr 1995, Bruce Evans wrote: > > > How about the FreeBSD one? :) Maybe I'll just install Warp's > >boot manager, that one is quite nice. > > We don't have one, at least not one invented here. I'd like one in the > boot blocks, i.e., not in the MBR. Okay, I'll try using OS/2's fdisk to install one then. -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sun Apr 2 12:58:44 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA09247 for current-outgoing; Sun, 2 Apr 1995 12:58:44 -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 MAA09236 for ; Sun, 2 Apr 1995 12:58:38 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA06501; Sun, 2 Apr 1995 21:58:17 +0200 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id VAA10941 for freebsd-current@FreeBSD.org; Sun, 2 Apr 1995 21:58:16 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id VAA02976 for freebsd-current@FreeBSD.org; Sun, 2 Apr 1995 21:54:25 +0200 From: J Wunsch Message-Id: <199504021954.VAA02976@uriah.heep.sax.de> Subject: Re: sup not working To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 2 Apr 1995 21:54:24 +0200 (MET DST) In-Reply-To: <199504021817.LAA01567@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Apr 2, 95 11:17:51 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: 746 Sender: current-owner@FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote: > > >Don't pass me the conical hat (i don't have any clue what T/TCP might > >be good for and how i could make use of it), but i'm sitting behind a > >FreeBSD 1.1.5.1 box as my SLIP dialup point -- so i guess i don't have > >to disable it, right? > > > > It wasn't in FreeBSD until 2.0R+. Of course. I knew this. The question was whether i have to disable the new feature on my (2.0-current) side, if i'm sitting behind a 1.1.5.1 box at my ``provider''s side. (And the implied question was, too: What does T/TCP buy me? Are there any applications that make use of it?) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Apr 2 13:36:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA10493 for current-outgoing; Sun, 2 Apr 1995 13:36:00 -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 NAA10484 for ; Sun, 2 Apr 1995 13:35:54 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA21554; Sun, 2 Apr 1995 16:35:38 -0400 Date: Sun, 2 Apr 1995 16:35:38 -0400 From: Garrett Wollman Message-Id: <9504022035.AA21554@halloran-eldar.lcs.mit.edu> To: "Justin T. Gibbs" Cc: current@FreeBSD.org Subject: rfc1644 In-Reply-To: <199504012147.NAA11027@estienne.cs.berkeley.edu> References: <199504012147.NAA11027@estienne.cs.berkeley.edu> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > fixes the ftp and remote X hangs over slip for me. Is rfc1644 dependant on > rfc1323 at all? It's not supposed to be. Transaction TCP provides the accelerated open and close; RFC 1323 fixes windowing problems for very long, fast pipes. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Sun Apr 2 13:49:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA11032 for current-outgoing; Sun, 2 Apr 1995 13:49:32 -0700 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA11020 for ; Sun, 2 Apr 1995 13:49:26 -0700 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.9/8.6.9) with SMTP id NAA02187; Sun, 2 Apr 1995 13:48:49 -0700 Message-Id: <199504022048.NAA02187@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: sup not working In-reply-to: Your message of "Sun, 02 Apr 1995 21:54:24 +0200." <199504021954.VAA02976@uriah.heep.sax.de> Date: Sun, 02 Apr 1995 13:48:48 -0700 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk >As Justin T. Gibbs wrote: >> >> >Don't pass me the conical hat (i don't have any clue what T/TCP might >> >be good for and how i could make use of it), but i'm sitting behind a >> >FreeBSD 1.1.5.1 box as my SLIP dialup point -- so i guess i don't have >> >to disable it, right? >> > >> >> It wasn't in FreeBSD until 2.0R+. > >Of course. I knew this. > >The question was whether i have to disable the new feature on my >(2.0-current) side, if i'm sitting behind a 1.1.5.1 box at my >``provider''s side. > >(And the implied question was, too: What does T/TCP buy me? Are >there any applications that make use of it?) Don't know. Try it and let us know. I'm doing a FAQ entry on this topic, and it would be nice to narrow down when the scenarios that cause this problem. > >-- >cheers, J"org > >joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ >Never trust an operating system you don't have sources for. ;-) -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Sun Apr 2 14:02:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA11433 for current-outgoing; Sun, 2 Apr 1995 14:02:46 -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 OAA11424 for ; Sun, 2 Apr 1995 14:02:37 -0700 Received: from masi.ibp.fr (root@masi.ibp.fr [132.227.60.23]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id XAA23202 for ; Sun, 2 Apr 1995 23:02:55 +0200 Received: from ares.ibp.fr (ares.ibp.fr [132.227.64.31]) by masi.ibp.fr (8.6.11/jtpda-5.0) with ESMTP id XAA02276 for ; Sun, 2 Apr 1995 23:00:57 +0200 From: Remy.Card@masi.ibp.fr (Remy CARD) Received: by ares.ibp.fr (8.6.10/jtpda-5.0) id XAA24074 for current@freebsd.org; Sun, 2 Apr 1995 23:00:18 +0200 Message-Id: <199504022100.XAA24074@ares.ibp.fr> Subject: CVS conflict file in the latest sup To: current@FreeBSD.org Date: Sun, 2 Apr 1995 23:00:17 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 457 Sender: current-owner@FreeBSD.org Precedence: bulk Hi, During the latest sup, I got: SUP Upgrade of lib at Sun Apr 2 22:59:18 1995 SUP Fileserver 8.13 (4.3 BSD) 11291 on freefall.cdrom.com at 22:59:18 SUP Requesting changes since Apr 2 05:22:47 1995 SUP Using compressed file transfer ... SUP Receiving file lib/libc/rpc/.#clnt_udp.c.1.1 ... I suppose that .#clnt_udp.c.1.1 has been created by CVS because of a conflict on the clnt_udp.c source file. Could someone please fix this? Thanks Remy From owner-freebsd-current Sun Apr 2 15:19:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14566 for current-outgoing; Sun, 2 Apr 1995 15:19: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 PAA14557 for ; Sun, 2 Apr 1995 15:18:55 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id PAA02612; Sun, 2 Apr 1995 15:18:29 -0700 From: "Rodney W. Grimes" Message-Id: <199504022218.PAA02612@gndrsh.aac.dev.com> Subject: Re: New installation notes To: taob@gate.sinica.edu.tw (Brian Tao) Date: Sun, 2 Apr 1995 15:18:29 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Brian Tao" at Apr 3, 95 01:29:09 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1223 Sender: current-owner@FreeBSD.org Precedence: bulk ... > > >sailing once the kernel could recognize the Adaptec. I ran iozone to > > >check it out but it could only muster around 1.7MB/sec read/write > > >while my 486DX4/100 NCR-equipped system hits 2.5-2.6MB/sec. Both used > > > > Were you using the exact same drives? The best test would be to place > > the controllers in the same machine and test against the same exact drives. > > I'm been getting ~5MB/s out of the driver for some time now to a Quantum > > Empire 2100. > > The Pentium has twin Quantum Maverick 540's and my machine (with > the NCR controller) has a Quantum Empire 1080. I'll bring my drive up > to the Pentium and do another comparison. It is quite noticeably > slower for any heavy disk operations. Untarring the kernel source > dist and running config(8) are both noticeably faster on my 486. There is a very big difference between a Quantum Maverick 540 (3600 RPM, 14mS, 128k cache) and an Empire 1080 (5400RPM, 9.5mS, 512k cache). The two sets of numbers your reported above are very close to the maximum the drives can do. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sun Apr 2 15:37:05 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14816 for current-outgoing; Sun, 2 Apr 1995 15:37:05 -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 PAA14808 for ; Sun, 2 Apr 1995 15:37:03 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id PAA02659; Sun, 2 Apr 1995 15:36:38 -0700 From: "Rodney W. Grimes" Message-Id: <199504022236.PAA02659@gndrsh.aac.dev.com> Subject: Re: CVS conflict file in the latest sup To: Remy.Card@masi.ibp.fr (Remy CARD) Date: Sun, 2 Apr 1995 15:36:38 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: <199504022100.XAA24074@ares.ibp.fr> from "Remy CARD" at Apr 2, 95 11:00:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 864 Sender: current-owner@FreeBSD.org Precedence: bulk > > > Hi, > > During the latest sup, I got: > SUP Upgrade of lib at Sun Apr 2 22:59:18 1995 > SUP Fileserver 8.13 (4.3 BSD) 11291 on freefall.cdrom.com at 22:59:18 > SUP Requesting changes since Apr 2 05:22:47 1995 > SUP Using compressed file transfer > ... > SUP Receiving file lib/libc/rpc/.#clnt_udp.c.1.1 > ... > > I suppose that .#clnt_udp.c.1.1 has been created by CVS because of > a conflict on the clnt_udp.c source file. Could someone please fix this? Arghh.. someone some how managed to patch the sup area version of this file :-(. I have cleaned it up and reran supscan for the sys collection, you should be able to resup and have this cleaned up. Thanks for letting us know about it. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sun Apr 2 15:45:58 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14986 for current-outgoing; Sun, 2 Apr 1995 15:45:58 -0700 Received: from clinet.fi (root@clinet.fi [193.64.6.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA14980 for ; Sun, 2 Apr 1995 15:45:48 -0700 Received: from katiska.clinet.fi (root@katiska.clinet.fi [193.64.6.3]) by clinet.fi (8.6.10/8.6.4) with ESMTP id BAA12038 for ; Mon, 3 Apr 1995 01:45:19 +0300 From: Heikki Suonsivu Received: (hsu@localhost) by katiska.clinet.fi (8.6.10/8.6.4) id BAA06660 for freebsd-current@freefall.cdrom.com; Mon, 3 Apr 1995 01:45:19 +0300 Date: Mon, 3 Apr 1995 01:45:19 +0300 Message-Id: <199504022245.BAA06660@katiska.clinet.fi> To: freebsd-current@freefall.cdrom.com Subject: motd modes? Sender: current-owner@FreeBSD.org Precedence: bulk Currently rc.local sets /etc/motd modes to 644. Would it be more sensible to use 664 and group staff or wheel? From owner-freebsd-current Sun Apr 2 16:05:44 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA15351 for current-outgoing; Sun, 2 Apr 1995 16:05:44 -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 QAA15345 for ; Sun, 2 Apr 1995 16:05:42 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id QAA02779; Sun, 2 Apr 1995 16:03:39 -0700 From: "Rodney W. Grimes" Message-Id: <199504022303.QAA02779@gndrsh.aac.dev.com> Subject: Re: motd modes? To: hsu@clinet.fi (Heikki Suonsivu) Date: Sun, 2 Apr 1995 16:03:39 -0700 (PDT) Cc: freebsd-current@freefall.cdrom.com In-Reply-To: <199504022245.BAA06660@katiska.clinet.fi> from "Heikki Suonsivu" at Apr 3, 95 01:45:19 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 475 Sender: current-owner@FreeBSD.org Precedence: bulk > > > Currently rc.local sets /etc/motd modes to 644. Would it be more sensible > to use 664 and group staff or wheel? It is best to error on the side of secure so this is the default as the system is shipped. It is also one of the reasons this is done in rc.local, it is up to you if you want it to be different. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sun Apr 2 16:53:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA16075 for current-outgoing; Sun, 2 Apr 1995 16:53:10 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA16069 for ; Sun, 2 Apr 1995 16:53:09 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id QAA19310; Sun, 2 Apr 1995 16:52:52 -0700 Date: Sun, 2 Apr 1995 16:52:50 -0700 From: Richard Chang To: FreeBSD-current@freefall.cdrom.com Subject: slip and ppp not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk I don't know what happened... Yesterday sup wasn't working so Justin G. helped me on that one and the machine locked up so I rebooted and now ppp doesn't work at all, somehow it's not getting packets out of the machine.... slip works but when I start it, it says: Apr 2 16:45:31 bigbang slattach[196]: cannot get carrier state: Inappropriate ioctl for device Apr 2 16:45:31 bigbang slattach[196]: Waiting for carrier on /dev/cua00 (sl-1) For ppp, it just doesn't know how to handle hostnames but with ip numbers, it would just say the network is down... Anyone have any ideas? Thanks.. --richardc From owner-freebsd-current Sun Apr 2 18:31:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA18075 for current-outgoing; Sun, 2 Apr 1995 18:31:29 -0700 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA18069 for ; Sun, 2 Apr 1995 18:31:29 -0700 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.9/8.6.9) with SMTP id SAA03029; Sun, 2 Apr 1995 18:31:11 -0700 Message-Id: <199504030131.SAA03029@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Richard Chang cc: FreeBSD-current@freefall.cdrom.com Subject: Re: slip and ppp not working In-reply-to: Your message of "Sun, 02 Apr 1995 16:52:50 PDT." Date: Sun, 02 Apr 1995 18:31:11 -0700 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk > I don't know what happened... Yesterday sup wasn't working so >Justin G. helped me on that one and the machine locked up so I rebooted >and now ppp doesn't work at all, somehow it's not getting packets out of >the machine.... slip works but when I start it, it says: > >Apr 2 16:45:31 bigbang slattach[196]: cannot get carrier state: >Inappropriate ioctl for device >Apr 2 16:45:31 bigbang slattach[196]: Waiting for carrier on /dev/cua00 >(sl-1) > > For ppp, it just doesn't know how to handle hostnames but with ip >numbers, it would just say the network is down... Anyone have any ideas? >Thanks.. > >--richardc The sysctl calls I gave you are not permanent. You must run them out of rc.local so the configuration is maintained across reboots. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Sun Apr 2 18:36:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA18166 for current-outgoing; Sun, 2 Apr 1995 18:36:55 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA18160 for ; Sun, 2 Apr 1995 18:36:54 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id SAA27725; Sun, 2 Apr 1995 18:36:35 -0700 Date: Sun, 2 Apr 1995 18:36:33 -0700 From: Richard Chang To: "Justin T. Gibbs" cc: FreeBSD-current@freefall.cdrom.com Subject: Re: slip and ppp not working In-Reply-To: <199504030131.SAA03029@estienne.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sun, 2 Apr 1995, Justin T. Gibbs wrote: > > I don't know what happened... Yesterday sup wasn't working so > >Justin G. helped me on that one and the machine locked up so I rebooted > >and now ppp doesn't work at all, somehow it's not getting packets out of > >the machine.... slip works but when I start it, it says: > > > >Apr 2 16:45:31 bigbang slattach[196]: cannot get carrier state: > >Inappropriate ioctl for device > >Apr 2 16:45:31 bigbang slattach[196]: Waiting for carrier on /dev/cua00 > >(sl-1) > > > > For ppp, it just doesn't know how to handle hostnames but with ip > >numbers, it would just say the network is down... Anyone have any ideas? > >Thanks.. > > > >--richardc > > The sysctl calls I gave you are not permanent. You must run them out of > rc.local so the configuration is maintained across reboots. > > -- > Justin T. Gibbs > ============================================== > TCS Instructional Group - Programmer/Analyst 1 > Cory | Po | Danube | Volga | Parker | Torus > ============================================== > Hmmm, I tried the sysctl before the ppp and the slip and the same thing happens... --richardc From owner-freebsd-current Sun Apr 2 23:14:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA26029 for current-outgoing; Sun, 2 Apr 1995 23:14:38 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA26018 for ; Sun, 2 Apr 1995 23:14:31 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id OAA24053; Mon, 3 Apr 1995 14:14:37 +0800 Date: Mon, 3 Apr 1995 14:14:36 +0800 (CST) From: Brian Tao cc: freebsd-current@FreeBSD.org Subject: Re: New installation notes In-Reply-To: <199504022218.PAA02612@gndrsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sun, 2 Apr 1995, Rodney W. Grimes wrote: > > There is a very big difference between a Quantum Maverick 540 (3600 RPM, > 14mS, 128k cache) and an Empire 1080 (5400RPM, 9.5mS, 512k cache). The > two sets of numbers your reported above are very close to the maximum > the drives can do. I only looked up the drive specs this morning, after having thought Quantum made only 5400 and 7200 drives. That was pretty much the only explanation I could think of (RPM). But I were to do something like two 'dd if=blah of=/dev/null bs=65536' on files from each drive simultaneously, I should still be able to hit close to the maximum throughput, no? -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sun Apr 2 23:27:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA26794 for current-outgoing; Sun, 2 Apr 1995 23:27:11 -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 XAA26708 for ; Sun, 2 Apr 1995 23:26:36 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA23365; Mon, 3 Apr 1995 08:26:16 +0200 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id IAA13669; Mon, 3 Apr 1995 08:26:15 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id HAA26281; Mon, 3 Apr 1995 07:57:55 +0200 From: J Wunsch Message-Id: <199504030557.HAA26281@uriah.heep.sax.de> Subject: Re: slip and ppp not working To: richardc@CSUA.Berkeley.EDU (Richard Chang) Date: Mon, 3 Apr 1995 07:57:53 +0200 (MET DST) Cc: FreeBSD-current@freefall.cdrom.com In-Reply-To: from "Richard Chang" at Apr 2, 95 04:52: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: 751 Sender: current-owner@FreeBSD.org Precedence: bulk As Richard Chang wrote: > > Apr 2 16:45:31 bigbang slattach[196]: cannot get carrier state: > Inappropriate ioctl for device > Apr 2 16:45:31 bigbang slattach[196]: Waiting for carrier on /dev/cua00 > (sl-1) I've reported this in a problem report on saturday evening (MET). It has been fixed with sys/i386/i386/sio.c version 1.84. You can perhaps try to run the startup command (normally run by slattach) manually, but beware: one of the interim versions of sio was broken enough to cause an immediate panic at the first outgoing IP packet (b_t_q not on a clist). See my mails to -current for this. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Apr 3 01:03:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA29530 for current-outgoing; Mon, 3 Apr 1995 01:03:41 -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 BAA29518 for ; Mon, 3 Apr 1995 01:03:37 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id BAA03823; Mon, 3 Apr 1995 01:03:08 -0700 From: "Rodney W. Grimes" Message-Id: <199504030803.BAA03823@gndrsh.aac.dev.com> Subject: Re: New installation notes To: taob@gate.sinica.edu.tw (Brian Tao) Date: Mon, 3 Apr 1995 01:03:08 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Brian Tao" at Apr 3, 95 02:14:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2096 Sender: current-owner@FreeBSD.org Precedence: bulk > > On Sun, 2 Apr 1995, Rodney W. Grimes wrote: > > > > There is a very big difference between a Quantum Maverick 540 (3600 RPM, > > 14mS, 128k cache) and an Empire 1080 (5400RPM, 9.5mS, 512k cache). The > > two sets of numbers your reported above are very close to the maximum > > the drives can do. > > I only looked up the drive specs this morning, after having > thought Quantum made only 5400 and 7200 drives. That was pretty much > the only explanation I could think of (RPM). Quantum makes 3600, 4500, 5400 and 7200 RPM drives. They have only being making 5400 and 7200 RPM drives for a little over a year (just like every one else). > But I were to do > something like two 'dd if=blah of=/dev/null bs=65536' on files from > each drive simultaneously, I should still be able to hit close to the > maximum throughput, no? Depends on what maximum throughput you are trying to hit. If it is for the SCSI bus/controller a much better test would be to read the same ``disk cache size'' block of data repeatedly from the raw device. repeat 1000 dd if=/dev/rsd0c of=/dev/null bs=size_of_drive_cache count=1 but dd's verbose output slows this way down :-(. I have done dual drive concurrent iozones using 3MB/sec drives and saw a very small difference in the numbers for each drive compared to running them seperately (ie, the bottleneck was really the drives and not the SCSI bus, controller or PCI bus.) This was using a NCR 53C825 based controller running 2 DEC 3053L fast scsi drives (not wide). One needs to be very carefull when doing benchmarks to understand what it is you are really measureing. And to attempt to make the test measure what you really want it to measure. I image a carefully written C program could do the ``repeat 1000 dd'' above and obtain close to SCSI bus bandwidth if that is what you wanted to measure. (I also suspect in this case the real bottleneck would be the disk controller itself). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Mon Apr 3 01:21:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA00120 for current-outgoing; Mon, 3 Apr 1995 01:21:32 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA00100 for ; Mon, 3 Apr 1995 01:21:30 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0rvhNn-000K0iC; Mon, 3 Apr 95 01:21 WET DST Message-Id: Date: Mon, 3 Apr 95 01:21 WET DST From: pete@pelican.com (Pete Carah) To: current@FreeBSD.org Subject: Re: cvs commit: ports/games Makefile In-Reply-To: <199504030109.SAA08610@silvia.HIP.Berkeley.EDU> Organization: Pelican Consulting Sender: current-owner@FreeBSD.org Precedence: bulk In article <199504030109.SAA08610@silvia.HIP.Berkeley.EDU> Satoshi writes: >Since you're sup'ing, my guess is that your supfile is old and doesn't >have the ports-graphics entry. (That's where xpm was moved from >ports-x11 a while ago.) Given this, what is the current list of sup packages, both system and ports? It is hard to keep up with... I just added ports-graphics... -- Pete From owner-freebsd-current Mon Apr 3 01:53:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA00865 for current-outgoing; Mon, 3 Apr 1995 01:53:33 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA00857 for ; Mon, 3 Apr 1995 01:53:29 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: current@freefall.cdrom.com Subject: Thinking about CTM and the installation.. Date: Mon, 03 Apr 1995 01:53:27 -0700 Message-ID: <856.796899207@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk Ok, here's the scenario: Developer installs latest 2.1R using the CDROM for speed and ease-of-use. Since developer IS a developer, they select "src" as one of the distributions and come up with the whole thing on their disk. Then they proceed further into the post-install setup menu and they select Using Current Sources->Using CTM->Register With CTM. Now what? They get the *entire* source tree again via mail so that they can be sync'd up? That'd suck! At least sup, again, would merely update the timestamps after seeing that the files were the same. Is it possible to do something similar with CTM? Ideally, you'd want to connect to CTM for the first time and say (completely transparently, mind you) "I have 2.1R - give me everything that changed after 2.1R came out and keep me up-to-date from now on!" and it would just work. C'mon, CTM fans! This is the chance for your wonderful tool to get serious mainstream use, but we need to make it sing and dance just a little more to truly be a "plug n play" part of the installation (and it really SHOULD be - it's so close as it is now!).. Thanks..! Jordan From owner-freebsd-current Mon Apr 3 05:05:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA04774 for current-outgoing; Mon, 3 Apr 1995 05:05:16 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA04763 for ; Mon, 3 Apr 1995 05:05:14 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Mon, 3 Apr 1995 07:04:53 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Apr 1995 07:04:54 -0500 To: "Rodney W. Grimes" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: hackers@FreeBSD.org, current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk Rod Grimes writes : >> >> nate 95/04/02 18:13:51 >> >> Modified: sys/i386/conf Makefile.i386 >> Log: >> Added -I/usrinclude to the tail end of the INCLUDES line. This hack >> will cause kernel compiles to work even if the src/includes directory >> doesn't exist but still do the 'Right Thing' and pull files from the >> source tree if it does exist. >> >> Reviewed by: Bruce Evans > >Humm.. now what happens when these unknowing fools update there >/usr/src/sys tree and don't update /usr/include to match. They are >going to get kernel compiles that fall over, and we are going to >get bug reports about strange things happening :-(. I concur. This change is, IMHO, BAD. I will AGAIN suggest that we go the opposite direction. I've thought a lot about this structure and have implemented much of it on my own system. There are more details that I have omitted here, but this is the jist of my proposal. Responses welcome ... The source tree should be fully self contained and ALL references MUST be relative to the root of that tree. Further, the "obj" links are removed from the source tree and replaced by a parallel object tree that grows from the root. This allows us ALL of the following: 1) The compilation of a system does not "trash" the current operating system. 2) The source tree (and much of the object tree) can be read-only. 3) One system can support multiple DIFFERENT versions of the tree at the same time. 4) "Make world" reduces to little more than a simple "make all" at the top of the tree. Redundant remakes of the libraries are eliminated. 5) Cross compilation for other platforms becomes possible. The COST? Each compilation environment MUST have a variable designating the ROOT of that environment. (Unless you want the default root "/usr") Now, the question.... Do we (as a community) want this? Who is in charge here? I'll be happy to get it working. But to do so, I'll need the support of ALL the comitters. Basically, I would have to "own" all the Makefiles, make, and the .mk files. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Mon Apr 3 05:33:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA05395 for current-outgoing; Mon, 3 Apr 1995 05:33:08 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA05389 for ; Mon, 3 Apr 1995 05:33:05 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Mon, 3 Apr 1995 07:32:45 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Apr 1995 07:32:44 -0500 To: current@freefall.cdrom.com From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Thinking about CTM and the installation.. Sender: current-owner@FreeBSD.org Precedence: bulk "Jordan K. Hubbard" writes: >Ok, here's the scenario: > >Developer installs latest 2.1R using the CDROM [snip] >Select Using CTM->Register With CTM. Now what? >They get the *entire* source tree again via mail so that they can be >sync'd up? >That'd suck! At least sup, again, would merely update the timestamps >after seeing that the files were the same. Is it possible to do >something similar with CTM? 1) Signing up with CTM should set up the CTM tree structure and register you for FUTURE mailings. 2) The CDROM should have the appropriate flags to indicate the CTM level of that set of sources. 3) The missing part is the set of CTM updates that occurred between the time the CD was mastered and the present time. Do we need an automated ftp-by-mail to have those updates also sent? ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Mon Apr 3 07:08:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA07429 for current-outgoing; Mon, 3 Apr 1995 07:08:21 -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 HAA07423 for ; Mon, 3 Apr 1995 07:08:04 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA25922 for current@freebsd.org; Tue, 4 Apr 1995 00:04:46 +1000 Date: Tue, 4 Apr 1995 00:04:46 +1000 From: Bruce Evans Message-Id: <199504031404.AAA25922@godzilla.zeta.org.au> To: current@FreeBSD.org Subject: time(1) exit status for killed processes Sender: current-owner@FreeBSD.org Precedence: bulk time(1) exits with status (st >> 8) when the process being timed exits with status `st'. This causes it to exit with status 0 when the process is killed by a signal. Is this bug traditional? I noticed it because a process that executed `time foo' assumed that input from the file written by `foo' didn't need to be validated, and copied nonexistent input to stdout forever. Bruce From owner-freebsd-current Mon Apr 3 07:24:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA07980 for current-outgoing; Mon, 3 Apr 1995 07:24:41 -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 HAA07918 for ; Mon, 3 Apr 1995 07:24:25 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA26234; Tue, 4 Apr 1995 00:18:47 +1000 Date: Tue, 4 Apr 1995 00:18:47 +1000 From: Bruce Evans Message-Id: <199504031418.AAA26234@godzilla.zeta.org.au> To: rgrimes@gndrsh.aac.dev.com, taob@gate.sinica.edu.tw Subject: Re: New installation notes Cc: freebsd-current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> But I were to do >> something like two 'dd if=blah of=/dev/null bs=65536' on files from >> each drive simultaneously, I should still be able to hit close to the >> maximum throughput, no? Probably not. On my system (DX2/66 VLB BT445C), one 7200rpm drive seems to hit a limit at 5.4MB/sec and reading another 3600rpm drive at the same time reduces the total throughput. >One needs to be very carefull when doing benchmarks to understand >what it is you are really measureing. And to attempt to make the >test measure what you really want it to measure. I image a carefully >written C program could do the ``repeat 1000 dd'' above and obtain >close to SCSI bus bandwidth if that is what you wanted to measure. >(I also suspect in this case the real bottleneck would be the disk >controller itself). Yes :-(. For the BT445C, repeatedly reading the same 512-byte block is almost exactly as slow as reading sequential 512-byte blocks. The speed depends on the drive too. I get about 180K/sec for a slow drive and 300K/sec for a fast drive. An Ultrastor 34F controller is 40% slower. Bruce From owner-freebsd-current Mon Apr 3 08:50:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA11425 for current-outgoing; Mon, 3 Apr 1995 08:50:33 -0700 Received: from palmer.demon.co.uk (root@palmer.demon.co.uk [158.152.50.150]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA11419 for ; Mon, 3 Apr 1995 08:50:30 -0700 Received: from localhost (gary@localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.9/8.6.9) with SMTP id QAA00877 ; Mon, 3 Apr 1995 16:48:22 +0100 X-Authentication-Warning: palmer.demon.co.uk: Host localhost didn't use HELO protocol To: Pete Carah cc: current@FreeBSD.org Subject: Re: cvs commit: ports/games Makefile In-reply-to: Your message of "Mon, 03 Apr 1995 01:21:00 +0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <873.796924100.1@palmer.demon.co.uk> Date: Mon, 03 Apr 1995 16:48:21 +0100 Message-ID: <874.796924101@palmer.demon.co.uk> From: Gary Palmer Sender: current-owner@FreeBSD.org Precedence: bulk In message , Pete Carah writes: >Given this, what is the current list of sup packages, both system and >ports? It is hard to keep up with... I just added ports-graphics... ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/FAQ/extras/* are the files that you want. Gary From owner-freebsd-current Mon Apr 3 10:17:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA13055 for current-outgoing; Mon, 3 Apr 1995 10:17:56 -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 KAA13049 for ; Mon, 3 Apr 1995 10:17:52 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA30146 for current@freebsd.org; Tue, 4 Apr 1995 03:14:27 +1000 Date: Tue, 4 Apr 1995 03:14:27 +1000 From: Bruce Evans Message-Id: <199504031714.DAA30146@godzilla.zeta.org.au> To: current@FreeBSD.org Subject: f77 broken Sender: current-owner@FreeBSD.org Precedence: bulk Links of programs compiled by f77 are broken in much the same way as for g++. ___main is not linked if the following program is linked dynamically: stop end Bruce From owner-freebsd-current Mon Apr 3 11:42:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA15286 for current-outgoing; Mon, 3 Apr 1995 11:42:54 -0700 Received: from balboa.eng.uci.edu (balboa.eng.uci.edu [128.200.61.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA15280 for ; Mon, 3 Apr 1995 11:42:53 -0700 Received: from localhost.uci.edu by balboa.eng.uci.edu with SMTP id AA13248 (5.65c/IDA-1.4.4 for freebsd-current@freebsd.org); Mon, 3 Apr 1995 11:42:24 -0700 Message-Id: <199504031842.AA13248@balboa.eng.uci.edu> To: freebsd-current@FreeBSD.org Subject: slice code Date: Mon, 03 Apr 1995 11:42:23 -0700 From: Steven Wallace Sender: current-owner@FreeBSD.org Precedence: bulk I am having problems with the new slice code that was introduced. The problem is related to the braindammaged DOS partitioning due to the 1024 cylinder limit. My Quantum 1080S has 1028 cylinders in it. Before the slice code, I allocated the first 1024 cylinders in the partition. However, in the disklabel, I did not want those 4 MB to go to waste so I extended the BSD partitions beyond that to the real drive size. Since you only need first BSD partition inside the 1024 cylinders this does not cause any probs. Now with the slice code, this no longer works. I had to change the size of my BSD partition to the real drive size. Unfortunately, that no longer fits in 1024 cylinders and it wrapps to end at cylinder #4 (I have also tried specifying the end cylinder at 1023). Now when I boot, I get 'No Operating System' error message. I now have to use a BSD floppy to boot the disk. Instead of having to change the size of the partition, the slice code should not reject disklabel entries that are not inside any other partitions. So only if a disklabel entry used an area of a disk that was covered by another slice it should be rejected. It also would be nice to use the real disk size in determining if an entry went beyond the physical drive limit not the unreliable BIOS/DOS partition info. Steven From owner-freebsd-current Mon Apr 3 12:58:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA17394 for current-outgoing; Mon, 3 Apr 1995 12:58:31 -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 MAA17388 for ; Mon, 3 Apr 1995 12:58:18 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA00223; Tue, 4 Apr 1995 05:56:23 +1000 Date: Tue, 4 Apr 1995 05:56:23 +1000 From: Bruce Evans Message-Id: <199504031956.FAA00223@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, swallace@ece.uci.edu Subject: Re: slice code Sender: current-owner@FreeBSD.org Precedence: bulk >My Quantum 1080S has 1028 cylinders in it. Before the slice code, >I allocated the first 1024 cylinders in the partition. However, >in the disklabel, I did not want those 4 MB to go to waste so I extended >the BSD partitions beyond that to the real drive size. Since you only >need first BSD partition inside the 1024 cylinders this does not cause >any probs. >Now with the slice code, this no longer works. I had to change the size >of my BSD partition to the real drive size. Unfortunately, that no >longer fits in 1024 cylinders and it wrapps to end at cylinder #4 >(I have also tried specifying the end cylinder at 1023). >Now when I boot, I get 'No Operating System' error message. I now >have to use a BSD floppy to boot the disk. Apparently the BIOS is even fussier than the slice code. What exactly did you put in the partition table? >Instead of having to change the size of the partition, the slice >code should not reject disklabel entries that are not inside any other >partitions. So only if a disklabel entry used an area of a disk >that was covered by another slice it should be rejected. It also This isn't workable in general. Consider slices for different OS's, each with a magic internal label covering sectors outside the slice. >would be nice to use the real disk size in determining if an entry >went beyond the physical drive limit not the unreliable BIOS/DOS partition >info. Now the size is max(real disk size according to drive, disk size according to unreliable partition info) It would be better to use the reliable partition info here :-). (C/H/S values are unreliable and linear sector numbers are reliable). There is a bug setting the number of cylinders reported in the dummy label on /dev/rsdN to match the unreliable partition info: it isn't changed from the value reported by the drive, so it is usually wrong if the H/S values are changed to match the unreliable partition info (1980/13/80 becomes 1980/64/32 for one of my drives; it should become 1015+/64/32). Bruce From owner-freebsd-current Mon Apr 3 13:12:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA17821 for current-outgoing; Mon, 3 Apr 1995 13:12:43 -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 NAA17812 for ; Mon, 3 Apr 1995 13:12:41 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA22783; Mon, 3 Apr 1995 16:12:08 -0400 Date: Mon, 3 Apr 1995 16:12:08 -0400 From: Garrett Wollman Message-Id: <9504032012.AA22783@halloran-eldar.lcs.mit.edu> To: rkw@dataplex.net (Richard Wackerbarth) Cc: current@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 In-Reply-To: References: Sender: current-owner@FreeBSD.org Precedence: bulk < Further, the "obj" links are removed > from the source tree and replaced by a parallel object tree that grows from > the root. I VERY VERY VERY VERY much DISlike this. -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 Apr 3 13:18:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA17936 for current-outgoing; Mon, 3 Apr 1995 13:18:08 -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 NAA17929 for ; Mon, 3 Apr 1995 13:18:06 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA22790; Mon, 3 Apr 1995 16:16:29 -0400 Date: Mon, 3 Apr 1995 16:16:29 -0400 From: Garrett Wollman Message-Id: <9504032016.AA22790@halloran-eldar.lcs.mit.edu> To: steve@simon.chi.il.us (Steven E. Piette) Cc: current@FreeBSD.org Subject: Re: Ethernet interface AUI, UTP and BNC ports In-Reply-To: References: Sender: current-owner@FreeBSD.org Precedence: bulk < I've started the work and have most of the changes to ifconfig done. I'm waiting > on some feedback from Garrett to see if I going in the right direction before > starting on the drivers. I think I deleted your message. Send code and I'll tell you what I think. -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 Apr 3 13:23:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA18091 for current-outgoing; Mon, 3 Apr 1995 13:23:49 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA18085 for ; Mon, 3 Apr 1995 13:23:45 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id OAA03089; Mon, 3 Apr 1995 14:22:25 -0600 Date: Mon, 3 Apr 1995 14:22:25 -0600 From: Nate Williams Message-Id: <199504032022.OAA03089@trout.sri.MT.net> In-Reply-To: Garrett Wollman "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 3, 4:12pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Garrett Wollman , rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > > Further, the "obj" links are removed > > from the source tree and replaced by a parallel object tree that grows from > > the root. > > I VERY VERY VERY VERY much DISlike this. *Jordan mode on* C'mon now Garrett. Don't hold back. Tell us what you really think. Nate From owner-freebsd-current Mon Apr 3 13:36:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA18825 for current-outgoing; Mon, 3 Apr 1995 13:36: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 NAA18818 for ; Mon, 3 Apr 1995 13:36:12 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id MAA04965; Mon, 3 Apr 1995 12:35:32 -0700 From: "Rodney W. Grimes" Message-Id: <199504031935.MAA04965@gndrsh.aac.dev.com> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Mon, 3 Apr 1995 12:35:31 -0700 (PDT) Cc: rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <9504032012.AA22783@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Apr 3, 95 04:12:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 713 Sender: current-owner@FreeBSD.org Precedence: bulk > > < > > Further, the "obj" links are removed > > from the source tree and replaced by a parallel object tree that grows from > > the root. > > I VERY VERY VERY VERY much DISlike this. I agree with Garrett on this one, it makes it a pain to go look at the obj directory when you are in one of the src directories. But from other postings by Richard this is one of many options on how obj can be handled, and one of those options is the current symlink to the obj dir. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Mon Apr 3 14:28:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA19765 for current-outgoing; Mon, 3 Apr 1995 14:28:26 -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 OAA19744; Mon, 3 Apr 1995 14:28:00 -0700 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id XAA05114; Mon, 3 Apr 1995 23:27:27 +0200 Message-Id: <199504032127.XAA05114@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: current@FreeBSD.org, bugs@FreeBSD.org Subject: Funnies in the SCSI kernel code... Date: Mon, 03 Apr 1995 23:27:26 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk Hi What is going on here? [Next line is line 56 of /sys/scsi/sd.c] > #define SECSIZE 512 > #define SDOUTSTANDING 4 > #define SD_RETRIES 4 > #define MAXTRANSFER 8 /* 1 page at a time */ > > #define SDUNITSHIFT 3 > #define SDUNIT(DEV) SH3_UNIT(DEV) +++++ > #define SDSETUNIT(DEV, U) SH3SETUNIT((DEV), (U)) ===== > #define PARTITION(dev) dkpart(dev) > #define SDUNIT(dev) dkunit(dev) +++++ > > /* XXX introduce a dkmodunit() macro for this. */ > #define SDSETUNIT(DEV, U) \ ===== > makedev(major(DEV), dkmakeminor((U), dkslice(DEV), dkpart(DEV))) +++++ Multiple definition of SDUNIT ===== Multiple definition of SDSETUNIT If they were the same, frankly I wouldn't give a damn. What gives? M M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Mon Apr 3 14:33:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA19897 for current-outgoing; Mon, 3 Apr 1995 14:33:29 -0700 Received: from mail.barrnet.net (MAIL.BARRNET.NET [131.119.245.10]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA19890 for ; Mon, 3 Apr 1995 14:33:26 -0700 Received: from dataplex.net by mail.barrnet.net (8.6.10/BARRNET-Len-Rose) id OAA10733; Mon, 3 Apr 1995 14:33:04 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Mon, 3 Apr 1995 16:32:59 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Apr 1995 16:33:00 -0500 To: "Rodney W. Grimes" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: wollman@halloran-eldar.lcs.mit.edu, current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> I VERY VERY VERY VERY much DISlike this. OK Garrett and Rod -- Address MY concerns while retaining the current obj links. 1) The bulk of the source will be on CDROM. 2) I am compiling on a production machine that is shared by other users. I'll install the result on another machine via NFS. 3) I need to maintain multiple versions of the world. In particular, I have a 2-Snap, my modifications to that "release", a -current, and the version that I am actually trying to test. Although I do have more disk space than most users, I cannot afford to keep duplicate trees of everything. 4) I have no idea what "Joe" is doing with the source, but he is also "using" it. We cannot get in each other's way. >I agree with Garrett on this one, it makes it a pain to go look at >the obj directory when you are in one of the src directories. At least you gave a reason. :) >But from other postings by Richard this is one of many options on how >obj can be handled, and one of those options is the current symlink >to the obj dir. True. It can also work that way, but I would not make it the default. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Mon Apr 3 14:40:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA20026 for current-outgoing; Mon, 3 Apr 1995 14:40:02 -0700 Received: from obiwan.pmr.com (obiwan.pmr.com [199.98.84.130]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA20020 for ; Mon, 3 Apr 1995 14:40:00 -0700 Received: by obiwan.pmr.com (Smail3.1.29.1 #4) id m0rvtqo-00030gC; Mon, 3 Apr 95 16:39 CDT Message-Id: From: bob@obiwan.pmr.com (Bob Willcox) Subject: Proper procedure to partition/label disk now? To: freebsd-current@freefall.cdrom.com (freebsd-current) Date: Mon, 3 Apr 1995 16:39:58 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 339 Sender: current-owner@FreeBSD.org Precedence: bulk What is the correct way to partition and disklabel a disk now that the slice code is in -current? I have a disk that I just low-level formated (so it has *nothing* on it) that I would like to partition and disklabel for FreeBSD. How do I go about this? Thanks, -- Bob Willcox bob@obiwan.pmr.com (or obiwan%bob@uunet.uu.net) Austin, TX From owner-freebsd-current Mon Apr 3 14:59:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA20621 for current-outgoing; Mon, 3 Apr 1995 14:59:31 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA20612; Mon, 3 Apr 1995 14:59:29 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: rkw@dataplex.net (Richard Wackerbarth) cc: current@freefall.cdrom.com Subject: Re: Thinking about CTM and the installation.. In-reply-to: Your message of "Mon, 03 Apr 95 07:32:44 CDT." Date: Mon, 03 Apr 1995 14:59:29 -0700 Message-ID: <20610.796946369@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > 1) Signing up with CTM should set up the CTM tree structure and register > you for FUTURE mailings. > 2) The CDROM should have the appropriate flags to indicate the CTM level of > that set of sources. > 3) The missing part is the set of CTM updates that occurred between the > time the CD was mastered and the present time. Do we need an automated > ftp-by-mail to have those updates also sent? No, I don't think so.. Truly, I don't think that the problem is badly understood or anything - most of us know EXACTLY what's missing from CTM and even how to solve it. It's just finding the time for actually doing the work involved that is the major problem right now! :-( Jordan From owner-freebsd-current Mon Apr 3 16:05:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA22858 for current-outgoing; Mon, 3 Apr 1995 16:05:15 -0700 Received: from pluto.ops.NeoSoft.com (root@pluto.ops.NeoSoft.COM [198.64.212.23]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA22850 for ; Mon, 3 Apr 1995 16:05:12 -0700 Received: from metal.ops.neosoft.com (root@glenn-slip55.nmt.edu [129.138.5.155]) by pluto.ops.NeoSoft.com (8.6.10/8.6.10) with ESMTP id SAA09018 for ; Mon, 3 Apr 1995 18:04:51 -0500 Received: (from smace@localhost) by metal.ops.neosoft.com (8.6.11/8.6.10) id RAA00336 for current@freebsd.org; Mon, 3 Apr 1995 17:04:47 -0600 Date: Mon, 3 Apr 1995 17:04:47 -0600 From: Scott Mace Message-Id: <199504032304.RAA00336@metal.ops.neosoft.com> To: current@FreeBSD.org Subject: a few patches... Sender: current-owner@FreeBSD.org Precedence: bulk I would like to add a config option to enable as disable securelevel. the securelevel and chflags features are a major security helper IMHO. Also, on a totally unrelated note, I've found on at least 2 scsi drives I've used I need a pause right before the extended probe kicks off. (bt_inquire_setup_information) The minimal pause I've experimentally found is DELAY(450000). This is with the bt driver. I've had this patch in my set of "local" patches forever, but when I brought it up before, noone wanted it committed. Oh the horrors of yet another pause (which is nothing compared the the SCSI_WAIT stuff). The reason I'm bringing this up again is because I found _another_ drive that needs this little pause. So, what does everyone think? Scott From owner-freebsd-current Mon Apr 3 16:32:05 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA23589 for current-outgoing; Mon, 3 Apr 1995 16:32:05 -0700 Received: from obiwan.pmr.com (obiwan.pmr.com [199.98.84.130]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA23583 for ; Mon, 3 Apr 1995 16:32:04 -0700 Received: by obiwan.pmr.com (Smail3.1.29.1 #4) id m0rvvbF-00030nC; Mon, 3 Apr 95 18:32 CDT Message-Id: From: bob@obiwan.pmr.com (Bob Willcox) Subject: aic7xxx.c: Target Busy console messages To: freebsd-current@freefall.cdrom.com (freebsd-current) Date: Mon, 3 Apr 1995 18:32:01 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1112 Sender: current-owner@FreeBSD.org Precedence: bulk I have noticed that with my new AHA-2740 controller card I get repetitive ahc0: Target Busy Messages on the console when accessing my Exabyte 8200 tape drive. Is this message important? (The bt742a.c driver appears to not issue a message for a busy status.) From the Exabyte EXB-8200 User's Manual: "Busy status indicates the EXB-8200 is in the busy state. The EXB-8200 is in a busy state when it is performing an internal operation that prevents it from accepting another command until the operation is complete. The EXB-8200 returns Busy status for a command request until the busy state is released. After the busy state is released, the initiator must reissue the command to the EXB-8200. When the busy state is released, selection operation and commands can be executed normally." >From this, it sounds to me that this is a rather normal condition and that the driver should simply reissue the command (periodically) until successful. Is this true of other devices as well? Comments? -- Bob Willcox bob@obiwan.pmr.com (or obiwan%bob@uunet.uu.net) Austin, TX From owner-freebsd-current Mon Apr 3 17:30:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA24728 for current-outgoing; Mon, 3 Apr 1995 17:30:56 -0700 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA24722 for ; Mon, 3 Apr 1995 17:30:54 -0700 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.11/8.6.9) with SMTP id RAA08552; Mon, 3 Apr 1995 17:30:33 -0700 Message-Id: <199504040030.RAA08552@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: bob@obiwan.pmr.com (Bob Willcox) cc: freebsd-current@freefall.cdrom.com (freebsd-current) Subject: Re: aic7xxx.c: Target Busy console messages In-reply-to: Your message of "Mon, 03 Apr 1995 18:32:01 CDT." Date: Mon, 03 Apr 1995 17:30:32 -0700 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk >I have noticed that with my new AHA-2740 controller card I get repetitive > >ahc0: Target Busy > >Messages on the console when accessing my Exabyte 8200 tape drive. Did the probe say that it was a tagged queuing device? Does the device actually work regardless of the messages? >Is this message important? (The bt742a.c driver appears to not >issue a message for a busy status.) From the Exabyte EXB-8200 >User's Manual: > > "Busy status indicates the EXB-8200 is in the busy state. The > EXB-8200 is in a busy state when it is performing an internal > operation that prevents it from accepting another command until > the operation is complete. > > The EXB-8200 returns Busy status for a command request until > the busy state is released. After the busy state is released, > the initiator must reissue the command to the EXB-8200. When > the busy state is released, selection operation and commands > can be executed normally." > >>From this, it sounds to me that this is a rather normal condition >and that the driver should simply reissue the command (periodically) >until successful. Is this true of other devices as well? It does reissue the command. It just doesn't happen that often so I log it to the console. > >Comments? > >-- >Bob Willcox >bob@obiwan.pmr.com (or obiwan%bob@uunet.uu.net) >Austin, TX -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Mon Apr 3 17:38:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA24939 for current-outgoing; Mon, 3 Apr 1995 17:38:42 -0700 Received: from obiwan.pmr.com (obiwan.pmr.com [199.98.84.130]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA24932 for ; Mon, 3 Apr 1995 17:38:40 -0700 Received: by obiwan.pmr.com (Smail3.1.29.1 #4) id m0rvwdc-000308C; Mon, 3 Apr 95 19:38 CDT Message-Id: From: bob@obiwan.pmr.com (Bob Willcox) Subject: Re: aic7xxx.c: Target Busy console messages To: gibbs@estienne.CS.Berkeley.EDU (Justin T. Gibbs) Date: Mon, 3 Apr 1995 19:38:32 -0500 (CDT) Cc: freebsd-current@freefall.cdrom.com In-Reply-To: <199504040030.RAA08552@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Apr 3, 95 05:30:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1031 Sender: current-owner@FreeBSD.org Precedence: bulk Justin T. Gibbs wrote: > > >I have noticed that with my new AHA-2740 controller card I get repetitive > > > >ahc0: Target Busy > > > >Messages on the console when accessing my Exabyte 8200 tape drive. > > Did the probe say that it was a tagged queuing device? Does the > device actually work regardless of the messages? No, it doesn't support tagged queueing (doesn't even support synchronous xfers). Seems to work ok with dump and restore, though I am having problems with dd and haven't really sorted them out just yet. > > > >>From this, it sounds to me that this is a rather normal condition > >and that the driver should simply reissue the command (periodically) > >until successful. Is this true of other devices as well? > > It does reissue the command. It just doesn't happen that often so I log > it to the console. It happens quite often with this device :-( I seem to be getting 10-12 of them whenever I run dump or restore to it. -- Bob Willcox bob@obiwan.pmr.com (or obiwan%bob@uunet.uu.net) Austin, TX From owner-freebsd-current Mon Apr 3 19:43:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA29495 for current-outgoing; Mon, 3 Apr 1995 19:43:36 -0700 Received: from simon.chi.il.us (simon.chi.il.us [199.245.227.17]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA29489 for ; Mon, 3 Apr 1995 19:43:33 -0700 Received: by simon.chi.il.us (Smail3.1.29.1 #3) id m0rvyZF-000NB4C; Mon, 3 Apr 95 21:42 CDT Message-Id: Date: Mon, 3 Apr 95 21:42 CDT From: steve@simon.chi.il.us (Steven E. Piette) To: gibbs@estienne.CS.Berkeley.EDU, jkh@freefall.cdrom.com Subject: Re: Ethernet interface AUI, UTP and BNC ports Cc: wollman@halloran-eldar.lcs.mit.edu, steve@simon.chi.il.us, current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > From freefall.cdrom.com!jkh Sun Apr 2 05:02:45 1995 > To: "Justin T. Gibbs" > cc: Garrett Wollman , > steve@simon.chi.il.us (Steven E. Piette), current@freebsd.org > Subject: Re: Ethernet interface AUI, UTP and BNC ports > Date: Sat, 01 Apr 1995 22:38:56 -0800 > From: "Jordan K. Hubbard" > > > Can you give a rough outline of the work needed so that others can start > > it if you don't have the time? I'm so sick of answering the link2 questions, > > that I'd like to make this happen as soon as possible. > > What's the story with this? > > Jordan > Besides if_ep (3C5x9) and some devices in if_ed what other devices support on the fly physical port selection that will need hacking once ifconfig stops using the LINK flags. (A quick check for IFF_LINK turns up if_ze) Steve From owner-freebsd-current Mon Apr 3 20:59:44 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA01558 for current-outgoing; Mon, 3 Apr 1995 20:59:44 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA01552 for ; Mon, 3 Apr 1995 20:59:43 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id UAA18799; Mon, 3 Apr 1995 20:57:54 -0700 Date: Mon, 3 Apr 1995 20:57:51 -0700 From: Richard Chang To: Joerg Wunsch cc: FreeBSD-current@freefall.cdrom.com Subject: Re: slip and ppp not working In-Reply-To: <199504030557.HAA26281@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Mon, 3 Apr 1995, J Wunsch wrote: > As Richard Chang wrote: > > > > Apr 2 16:45:31 bigbang slattach[196]: cannot get carrier state: > > Inappropriate ioctl for device > > Apr 2 16:45:31 bigbang slattach[196]: Waiting for carrier on /dev/cua00 > > (sl-1) > > I've reported this in a problem report on saturday evening (MET). > It has been fixed with sys/i386/i386/sio.c version 1.84. > > You can perhaps try to run the startup command (normally run by > slattach) manually, but beware: one of the interim versions of sio was > broken enough to cause an immediate panic at the first outgoing IP > packet (b_t_q not on a clist). > > See my mails to -current for this. > > -- > 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. ;-) > Oh, I see.... But I never rebuilt my soucres or a new kernel and it worked fine before I rebooted.... Hmmm, does this affect ppp also? --richardc From owner-freebsd-current Mon Apr 3 21:12:24 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01895 for current-outgoing; Mon, 3 Apr 1995 21:12:24 -0700 Received: from feta.cisco.com (feta.cisco.com [171.69.1.158]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA01876; Mon, 3 Apr 1995 21:12:15 -0700 Received: from [171.69.126.217] (sl-chary-15.cisco.com [171.69.126.217]) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id VAA17562; Mon, 3 Apr 1995 21:10:14 -0700 X-Sender: pst@feta.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 00:10:18 -0400 To: jkh@FreeBSD.org, phk@FreeBSD.org From: pst@cisco.com (Paul Traina) Subject: READ BEFORE SUPPING: critical change to login/su Cc: current@FreeBSD.org, cvs-committers@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk Unfortunately, it looks like when someone changed libmd to no longer be share, we had an unforseen breakage of skey. Apparently, the linker does not resolve undefined symbols of shared libraries at link time, and libskey.so.2.0 makes references to stuff found in libmd.a. The modules in libmd.a that skey requires were not getting linked into the actual programs that used skey, so when someone actually invoked skey based programs like keyinit(1) there were unresolved runtime references (bloody amazing this wasn't caught earlier). Anyway, the "proper" fix here is to do away with libskey.so.2.0, as it's really not a good idea for the skey stuff to be shared anyway, which means that libskey.a and libmd.a will be linked in the old fashioned way and the right things will happen. Jordan/Paul (I am not making the change, I have retired :-)) add a "NOPIC=yes" line to libskey/Makefile so that .so files are no longer generated remove /usr/lib/libskey.so.* relink/install: login, su, ftpd, rexecd, key, keyinit You need to do this stuff in that order. If you do NOT relink/install login and su, you will be screwed as they will look for libskey.so.2.0 which is no longer there, so do it immediately after you rm libskey.so.* Regards, Paul From owner-freebsd-current Tue Apr 4 00:06:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA05530 for current-outgoing; Tue, 4 Apr 1995 00:06:53 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA05523; Tue, 4 Apr 1995 00:06:52 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Scott Mace cc: current@FreeBSD.org Subject: Re: a few patches... In-reply-to: Your message of "Mon, 03 Apr 95 17:04:47 MDT." <199504032304.RAA00336@metal.ops.neosoft.com> Date: Tue, 04 Apr 1995 00:06:51 -0700 Message-ID: <5522.796979211@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I would like to add a config option to enable as disable securelevel. > the securelevel and chflags features are a major security helper IMHO. Are you saying you also want to come up secure? No installing over kernels and things except when up single? Hmmmmm... Hmmmmmmmmmmmmm! David? When did we say we were going to cut over after the "grace period" on this one? :-) Personally, I think it's not a bad idea for 2.1. I think it highly likely that there is already going to be a BIG SIGN saying "READ ALL OF THIS BEFORE PROCEEDING OR DIE!!" (or something to that effect) right at the beginning of 2.1. This file will contain stuff you _really_ want the users to read, for example the fact that system files are immutable by default and, while FAR more secure, not entirely without cost. There would probably be a number of people a lot safer because of it if we made it a default.. > Also, on a totally unrelated note, I've found on at least 2 scsi drives > I've used I need a pause right before the extended probe kicks off. > (bt_inquire_setup_information) The minimal pause I've experimentally > found is DELAY(450000). This is with the bt driver. I've had this patch > in my set of "local" patches forever, but when I brought it up before, > noone wanted it committed. Oh the horrors of yet another pause (which Indeed! The horror! I dunno.. Is this a known catagorical deficiency in certain drives? JOrdan From owner-freebsd-current Tue Apr 4 00:20:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA05717 for current-outgoing; Tue, 4 Apr 1995 00:20:07 -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 AAA05711 for ; Tue, 4 Apr 1995 00:20:04 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id XAA06445; Mon, 3 Apr 1995 23:19:24 -0700 From: "Rodney W. Grimes" Message-Id: <199504040619.XAA06445@gndrsh.aac.dev.com> Subject: Re: a few patches... To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Mon, 3 Apr 1995 23:19:24 -0700 (PDT) Cc: smace@metal-mail.neosoft.com, current@FreeBSD.org In-Reply-To: <5522.796979211@freefall.cdrom.com> from "Jordan K. Hubbard" at Apr 4, 95 00:06:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2599 Sender: current-owner@FreeBSD.org Precedence: bulk > > > I would like to add a config option to enable as disable securelevel. > > the securelevel and chflags features are a major security helper IMHO. > > Are you saying you also want to come up secure? No installing over > kernels and things except when up single? > > Hmmmmm... Hmmmmmmmmmmmmm! David? When did we say we were going to > cut over after the "grace period" on this one? :-) > > Personally, I think it's not a bad idea for 2.1. I think it highly > likely that there is already going to be a BIG SIGN saying "READ ALL > OF THIS BEFORE PROCEEDING OR DIE!!" (or something to that effect) > right at the beginning of 2.1. This file will contain stuff you > _really_ want the users to read, for example the fact that system > files are immutable by default and, while FAR more secure, not > entirely without cost. > > There would probably be a number of people a lot safer because of it > if we made it a default.. Did you find an archive format to use for the bindist's that preserve this information?? Tar doesn't, I think I remeber seeing Brunce say that cpio -H newc did, but I can't verify it right now since my 2.x box is down. I am currently building and installing my own releases for customers machines due to the permission problems in this and other areas with the last few snap shots :-(. > > Also, on a totally unrelated note, I've found on at least 2 scsi drives > > I've used I need a pause right before the extended probe kicks off. > > (bt_inquire_setup_information) The minimal pause I've experimentally > > found is DELAY(450000). This is with the bt driver. I've had this patch > > in my set of "local" patches forever, but when I brought it up before, > > noone wanted it committed. Oh the horrors of yet another pause (which > > Indeed! The horror! > > I dunno.. Is this a known catagorical deficiency in certain drives? Can you again tell us more about how the failure manifests itself, and what model drives is this that is causing this. This seems very strange to me that there is a problem related to attached devices here, as we are asking the controller what it found at this stage, we are not suppose to be talking to devices. You may have slow devices that have not recovered from the SCSI bus reset, so the controller has not finished regathering this info. If that is the case then the real fix is to use SCSI_DELAY to allow your SCSI devices to become ready after a reset. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Tue Apr 4 03:29:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA09540 for current-outgoing; Tue, 4 Apr 1995 03:29:38 -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 DAA09533; Tue, 4 Apr 1995 03:29:14 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA17738; Tue, 4 Apr 1995 20:25:01 +1000 Date: Tue, 4 Apr 1995 20:25:01 +1000 From: Bruce Evans Message-Id: <199504041025.UAA17738@godzilla.zeta.org.au> To: jkh@FreeBSD.org, phk@FreeBSD.org, pst@cisco.com Subject: Re: READ BEFORE SUPPING: critical change to login/su Cc: current@FreeBSD.org, cvs-committers@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Unfortunately, it looks like when someone changed libmd to no longer be >share, we had an unforseen breakage of skey. >Apparently, the linker does not resolve undefined symbols of shared libraries >at link time, and libskey.so.2.0 makes references to stuff found in libmd.a. >The modules in libmd.a that skey requires were not getting linked into the >actual programs that used skey, so when someone actually invoked skey based >programs like keyinit(1) there were unresolved runtime references >(bloody amazing this wasn't caught earlier). `ld -Bdynamic' currently has the evil behaviour of not reporting unresolved references. This stops incorrectly ordered lists of libraries from being detected at link time. The unresolved references aren't reported until the reference is used (maybe never). The problem is masked if all libraries are shared because standard ordering doesn't apply (another bug). >Jordan/Paul (I am not making the change, I have retired :-)) I missed your retirement speech :-). Bruce From owner-freebsd-current Tue Apr 4 04:24:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA10549 for current-outgoing; Tue, 4 Apr 1995 04:24:01 -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 EAA10543 for ; Tue, 4 Apr 1995 04:23:49 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA18870; Tue, 4 Apr 1995 21:21:22 +1000 Date: Tue, 4 Apr 1995 21:21:22 +1000 From: Bruce Evans Message-Id: <199504041121.VAA18870@godzilla.zeta.org.au> To: rkw@dataplex.net, wollman@halloran-eldar.lcs.mit.edu Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> Further, the "obj" links are removed >> from the source tree and replaced by a parallel object tree that grows from >> the root. >I VERY VERY VERY VERY much DISlike this. What about a parallel object tree that is union mounted over the source? Assume that union mounts have no bugs. I think this would be nice for development but bad for portability. Bruce From owner-freebsd-current Tue Apr 4 04:38:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA10777 for current-outgoing; Tue, 4 Apr 1995 04:38:26 -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 EAA10771 for ; Tue, 4 Apr 1995 04:38:03 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA19165; Tue, 4 Apr 1995 21:31:33 +1000 Date: Tue, 4 Apr 1995 21:31:33 +1000 From: Bruce Evans Message-Id: <199504041131.VAA19165@godzilla.zeta.org.au> To: bob@obiwan.pmr.com, freebsd-current@freefall.cdrom.com Subject: Re: Proper procedure to partition/label disk now? Sender: current-owner@FreeBSD.org Precedence: bulk >What is the correct way to partition and disklabel a disk now that >the slice code is in -current? I have a disk that I just low-level >formated (so it has *nothing* on it) that I would like to partition >and disklabel for FreeBSD. How do I go about this? For using the whole disk for FreeBSD, just run disklabel. The man page may actually be complete now that the 'd' partition isn't special. This assumes that the disk really is clean, without misleading junk in the partition table. Partitioning and labeling can be practiced on virtual (vn) drives. See old commit mail. Bruce From owner-freebsd-current Tue Apr 4 05:42:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA11672 for current-outgoing; Tue, 4 Apr 1995 05:42:46 -0700 Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA11666 for ; Tue, 4 Apr 1995 05:42:43 -0700 Received: from gilberto.physik.rwth-aachen.de by campino.informatik.rwth-aachen.de (4.1/campino-6) id AA15727; Tue, 4 Apr 95 14:41:24 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.8/8.6.9) id OAA26842 for freebsd-current@freefall.cdrom.com; Tue, 4 Apr 1995 14:46:48 +0200 Date: Tue, 4 Apr 1995 14:46:48 +0200 From: "Christoph P. Kukulies" Message-Id: <199504041246.OAA26842@gilberto.physik.rwth-aachen.de> To: freebsd-current@freefall.cdrom.com Subject: file: table is full Sender: current-owner@FreeBSD.org Precedence: bulk With a Apr 3 kernel I'm suddenly getting these: Apr 4 13:33:42 blues /kernel: file: table is full during a make world. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Mon Apr 3 17:10:12 MET DST 1995 root@blues:/usr/src/sys/compile/BLUESGUS i386 From owner-freebsd-current Tue Apr 4 06:25:24 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA12413 for current-outgoing; Tue, 4 Apr 1995 06:25:24 -0700 Received: from obiwan.pmr.com (obiwan.pmr.com [199.98.84.130]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id GAA12406 for ; Tue, 4 Apr 1995 06:25:22 -0700 Received: by obiwan.pmr.com (Smail3.1.29.1 #4) id m0rw8bd-00030UC; Tue, 4 Apr 95 08:25 CDT Message-Id: From: bob@obiwan.pmr.com (Bob Willcox) Subject: Re: Proper procedure to partition/label disk now? To: bde@zeta.org.au (Bruce Evans) Date: Tue, 4 Apr 1995 08:25:16 -0500 (CDT) Cc: freebsd-current@freefall.cdrom.com In-Reply-To: <199504041131.VAA19165@godzilla.zeta.org.au> from "Bruce Evans" at Apr 4, 95 09:31:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2080 Sender: current-owner@FreeBSD.org Precedence: bulk Bruce Evans wrote: > > >What is the correct way to partition and disklabel a disk now that > >the slice code is in -current? I have a disk that I just low-level > >formated (so it has *nothing* on it) that I would like to partition > >and disklabel for FreeBSD. How do I go about this? > > For using the whole disk for FreeBSD, just run disklabel. The man > page may actually be complete now that the 'd' partition isn't > special. This assumes that the disk really is clean, without > misleading junk in the partition table. Ok, I've done that. When I mount the filesystem (after having newfs'd it) I get the following messages: Apr 4 08:14:27 luke /kernel: sd2: invalid primary partition table: no magic Apr 4 08:14:27 luke /kernel: sd2: raw partition size != slice size Apr 4 08:14:27 luke /kernel: sd2: start 0, end 782599, size 782600 Apr 4 08:14:27 luke /kernel: sd2c: start 0, end 782335, size 782336 The first two seem to be complaining about the lack of a partition table. Here is the disklabel for the drive: # /dev/rsd2c: type: SCSI disk: IBM0661 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 382 sectors/unit: 782600 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 4 partitions: # size offset fstype [fsize bsize bps/cpg] a: 782336 0 4.2BSD 1024 8192 16 # (Cyl. 0 - 381) c: 782336 0 unused 0 0 # (Cyl. 0 - 381) d: 782336 0 unused 0 0 # (Cyl. 0 - 381) > > Partitioning and labeling can be practiced on virtual (vn) drives. > See old commit mail. Ok, but this is simply a test drive so I have no problems practicing on it :-) I'm trying to understand how to do all of this stuff now for when I convert my primary system from 1.1.5.1 to 2.1. (It currently has 13 disks on it and lots of data I don't want to lose.) -- Bob Willcox bob@obiwan.pmr.com (or obiwan%bob@uunet.uu.net) Austin, TX From owner-freebsd-current Tue Apr 4 07:29:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA13351 for current-outgoing; Tue, 4 Apr 1995 07:29:27 -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 HAA13339 for ; Tue, 4 Apr 1995 07:29:22 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA23867; Wed, 5 Apr 1995 00:22:40 +1000 Date: Wed, 5 Apr 1995 00:22:40 +1000 From: Bruce Evans Message-Id: <199504041422.AAA23867@godzilla.zeta.org.au> To: jkh@freefall.cdrom.com, rgrimes@gndrsh.aac.dev.com Subject: Re: a few patches... Cc: current@FreeBSD.org, smace@metal-mail.neosoft.com Sender: current-owner@FreeBSD.org Precedence: bulk >> > I would like to add a config option to enable as disable securelevel. >> > the securelevel and chflags features are a major security helper IMHO. >> >> Are you saying you also want to come up secure? No installing over >> kernels and things except when up single? >> >> Hmmmmm... Hmmmmmmmmmmmmm! David? When did we say we were going to >> cut over after the "grace period" on this one? :-) >> >> Personally, I think it's not a bad idea for 2.1. I think it highly Optionally. >Did you find an archive format to use for the bindist's that preserve >this information?? Tar doesn't, I think I remeber seeing Brunce say >that cpio -H newc did, but I can't verify it right now since my 2.x box >is down. None of tar, cpio or pax call chflags(), so they can't restore flags. Bruce From owner-freebsd-current Tue Apr 4 07:48:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA13757 for current-outgoing; Tue, 4 Apr 1995 07:48:48 -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 HAA13751 for ; Tue, 4 Apr 1995 07:48:37 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA24580; Wed, 5 Apr 1995 00:45:57 +1000 Date: Wed, 5 Apr 1995 00:45:57 +1000 From: Bruce Evans Message-Id: <199504041445.AAA24580@godzilla.zeta.org.au> To: bde@zeta.org.au, bob@obiwan.pmr.com Subject: Re: Proper procedure to partition/label disk now? Cc: freebsd-current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> For using the whole disk for FreeBSD, just run disklabel. The man >> page may actually be complete now that the 'd' partition isn't >> special. This assumes that the disk really is clean, without >> misleading junk in the partition table. >Ok, I've done that. When I mount the filesystem (after having >newfs'd it) I get the following messages: >Apr 4 08:14:27 luke /kernel: sd2: invalid primary partition table: no magic >Apr 4 08:14:27 luke /kernel: sd2: raw partition size != slice size >Apr 4 08:14:27 luke /kernel: sd2: start 0, end 782599, size 782600 >Apr 4 08:14:27 luke /kernel: sd2c: start 0, end 782335, size 782336 These messages are only warnings. Should they be removed? The first one says that there is apparently no partition table. `disklabel -B' would write a suitable partition table. The message should never be printed for bootable disks. The last 3 say that you made the raw partition size smaller than the disk size. This is a strange thing to do because the raw partition is supposed to cover the whole disk. There is no reason to round it to a cylinder boundary. >Here is the disklabel for the drive: ># /dev/rsd2c: >... >sectors/unit: 782600 >... >4 partitions: ># size offset fstype [fsize bsize bps/cpg] > a: 782336 0 4.2BSD 1024 8192 16 # (Cyl. 0 - 381) > c: 782336 0 unused 0 0 # (Cyl. 0 - 381) > d: 782336 0 unused 0 0 # (Cyl. 0 - 381) The sectors/unit value isn't rounded. Good. Perhaps it should be checked instead of the 'c' partition size. No, I just remembered why not. Old labels have to be converted, and the sectors/unit value is guaranteed to be wrong (being for the whole disk ond not for the BSD slice) except when there is only one slice, so the 'c' partition size has to be trusted. The 'd' partition shouldn't be necessary. Bruce From owner-freebsd-current Tue Apr 4 07:49:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA13767 for current-outgoing; Tue, 4 Apr 1995 07:49:49 -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 HAA13761 for ; Tue, 4 Apr 1995 07:49:42 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id PAA01969; Tue, 4 Apr 1995 15:11:20 +0100 Date: Tue, 4 Apr 1995 15:11:18 +0100 (BST) From: Doug Rabson To: current@FreeBSD.org Subject: LINT settings Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk I just put a new SoundBlaster16 + CD in my machine. All the FreeBSD drivers appear to work fine (well I can play .au files and mount the CDROM). One extremely minor point is that the default port setting for the sbmidi0 device in LINT is 0x300 whereas the default on the card was 0x330 (both on the card and in the manual). -- Doug Rabson, RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Tue Apr 4 08:22:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA14222 for current-outgoing; Tue, 4 Apr 1995 08:22:43 -0700 Received: from linc.cis.upenn.edu (root@LINC.CIS.UPENN.EDU [158.130.12.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA14208; Tue, 4 Apr 1995 08:21:18 -0700 Received: from aurora.cis.upenn.edu (AURORA.CIS.UPENN.EDU [158.130.6.3]) by linc.cis.upenn.edu (8.6.10/UPenn 1.4) with SMTP id LAA10494; Tue, 4 Apr 1995 11:20:54 -0400 Posted-Date: Tue, 4 Apr 1995 11:20:48 -0400 (EDT) Date: Tue, 4 Apr 1995 11:20:48 -0400 (EDT) From: "William A. Arbaugh" To: Paul Traina Cc: jkh@FreeBSD.org, phk@FreeBSD.org, current@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: READ BEFORE SUPPING: critical change to login/su In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Tue, 4 Apr 1995, Paul Traina wrote: > Apparently, the linker does not resolve undefined symbols of shared libraries > at link time, and libskey.so.2.0 makes references to stuff found in libmd.a. > The modules in libmd.a that skey requires were not getting linked into the > actual programs that used skey, so when someone actually invoked skey based > programs like keyinit(1) there were unresolved runtime references > (bloody amazing this wasn't caught earlier). > I reported it last week to hackers. Would bugs or current been more appropriate? > Anyway, the "proper" fix here is to do away with libskey.so.2.0, as it's > really not a good idea for the skey stuff to be shared anyway, which means > that libskey.a and libmd.a will be linked in the old fashioned way and > the right things will happen. > Shouldn't the linker be fixed to handle the unresolved symbols from a shared library. I agree that skey shouldn't be a shared library, but that really isn't fixing the real problem though. Someone may stumble onto this again with another program that uses a mix of shared and static libraries. bill ----------------------------------------------------------------------- Bill Arbaugh email: waa@aurora.cis.upenn.edu office: Moore 102 phone: (215) 573-3639 FAX: (215) 573-2232 ------------------------------------------------------------------------ From owner-freebsd-current Tue Apr 4 09:01:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA14762 for current-outgoing; Tue, 4 Apr 1995 09:01:53 -0700 Received: from dolphin.mikom.csir.co.za (some.schmuck.lame.delegated.to.RAIN.PSG.COM [146.64.28.40]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA14756 for ; Tue, 4 Apr 1995 09:01:44 -0700 Received: (from jhay@localhost) by dolphin.mikom.csir.co.za (8.6.11/8.6.6) id SAA01937 for current@FreeBSD.ORG; Tue, 4 Apr 1995 18:01:43 +0200 From: John Hay Message-Id: <199504041601.SAA01937@dolphin.mikom.csir.co.za> Subject: kernel make fail in kern_subr.c To: current@FreeBSD.org (FreeBSD-current) Date: Tue, 4 Apr 1995 18:01:42 +0200 (SAT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 777 Sender: current-owner@FreeBSD.org Precedence: bulk Hi, With the latest changes to kern_subr.c make fails. I have looked and some "UIO_" stuff is defined in sys/uio.h but not this one. cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -nostdinc -I. -I../.. -I../../sys -I../../../include -DANGEL -DI586_CPU -DI486_CPU -DDODUMP -DGWETHER -DBOUNCE_BUFFERS -DUCONSOLE -DCOMPAT_43 -DPROCFS -DMFS -DFFS -DINET -DMATH_EMULATE -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../kern/kern_subr.c ../../kern/kern_subr.c: In function `uiomove': ../../kern/kern_subr.c:93: `UIO_NOCOPY' undeclared (first use this function) ../../kern/kern_subr.c:93: (Each undeclared identifier is reported only once ../../kern/kern_subr.c:93: for each function it appears in.) *** Error code 1 Stop. -- John Hay -- jhay@mikom.csir.co.za From owner-freebsd-current Tue Apr 4 09:04:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA14783 for current-outgoing; Tue, 4 Apr 1995 09:04:57 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA14769; Tue, 4 Apr 1995 09:03:29 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id KAA06084; Tue, 4 Apr 1995 10:07:09 -0600 Date: Tue, 4 Apr 1995 10:07:09 -0600 From: Nate Williams Message-Id: <199504041607.KAA06084@trout.sri.MT.net> In-Reply-To: "William A. Arbaugh" "Re: READ BEFORE SUPPING: critical change to login/su" (Apr 4, 11:20am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "William A. Arbaugh" , Paul Traina Subject: Re: READ BEFORE SUPPING: critical change to login/su Cc: current@FreeBSD.org, cvs-committers@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > > Apparently, the linker does not resolve undefined symbols of shared libraries > > at link time, and libskey.so.2.0 makes references to stuff found in libmd.a. > > The modules in libmd.a that skey requires were not getting linked into the > > actual programs that used skey, so when someone actually invoked skey based > > programs like keyinit(1) there were unresolved runtime references > > (bloody amazing this wasn't caught earlier). The reason it wasn't caught earlier is because the linker depended on certain characteristics of linking which I changed. > Shouldn't the linker be fixed to handle the unresolved symbols from a > shared library. Yes. > I agree that skey shouldn't be a shared library, but > that really isn't fixing the real problem though. Someone may stumble > onto this again with another program that uses a mix of shared and static > libraries. I am planning on fixing this, but the whole shared lib/linker code is very new to me. If anyone feels like jumping in feel free to do so since my time is limited due to work commitments. (though sleep will become less important as the release date looms closer). Having two sets of eyes looking through the code certainly can't hurt. Nate From owner-freebsd-current Tue Apr 4 09:06:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA14802 for current-outgoing; Tue, 4 Apr 1995 09:06:25 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA14796 for ; Tue, 4 Apr 1995 09:06:23 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0rwB78-000K0jC; Tue, 4 Apr 95 09:05 WET DST Message-Id: From: pete@pelican.com (Pete Carah) Subject: secure mode question To: current@FreeBSD.org Date: Tue, 4 Apr 1995 09:05:57 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 342 Sender: current-owner@FreeBSD.org Precedence: bulk The talk of enabling secure mode brings up a question - secure mode is all fine and good, but it appears to require single-user to rotate log files. That is not really acceptable for a busy system - what do the berkeley folks do about that? Given a solution to that, I'd use secure mode on my gateway (once it is on 2.x), for one. -- Pete From owner-freebsd-current Tue Apr 4 09:28:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA15108 for current-outgoing; Tue, 4 Apr 1995 09:28:53 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA15102 for ; Tue, 4 Apr 1995 09:28:48 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id AAA00291; Wed, 5 Apr 1995 00:28:43 +0800 Date: Wed, 5 Apr 1995 00:28:43 +0800 (CST) From: Brian Tao cc: freebsd-current@FreeBSD.org Subject: Re: New installation notes In-Reply-To: <199504030803.BAA03823@gndrsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Mon, 3 Apr 1995, Rodney W. Grimes wrote: > > > But I were to do > > something like two 'dd if=blah of=/dev/null bs=65536' on files from > > each drive simultaneously, I should still be able to hit close to the > > maximum throughput, no? > > Depends on what maximum throughput you are trying to hit. The disk-to-bus throughput per disk. If the drives are only capable of about 2 megabytes per second, then assuming the aic7xxx driver and the AHA-2940 can handle far in excess of that, I should be able to push close to 4 megabytes per second through the bus? > I have done dual drive concurrent iozones using 3MB/sec drives and > saw a very small difference in the numbers for each drive compared > to running them seperately (ie, the bottleneck was really the drives > and not the SCSI bus, controller or PCI bus.) Right, this is what I want to determine. The bottleneck won't be the Pentium CPU, the PCI bus or the SCSI controller. I figure it's the disk, but I want to make sure it isn't the driver. -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Tue Apr 4 10:02:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA15375 for current-outgoing; Tue, 4 Apr 1995 10:02:29 -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 KAA15369 for ; Tue, 4 Apr 1995 10:02:27 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id KAA06221; Tue, 4 Apr 1995 10:02:01 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id KAA00162; Tue, 4 Apr 1995 10:02:01 -0700 Message-Id: <199504041702.KAA00162@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: John Hay cc: current@FreeBSD.org (FreeBSD-current) Subject: Re: kernel make fail in kern_subr.c In-reply-to: Your message of "Sat, 04 Apr 95 18:01:42 +0200." <199504041601.SAA01937@dolphin.mikom.csir.co.za> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 04 Apr 1995 10:01:58 -0700 Sender: current-owner@FreeBSD.org Precedence: bulk >Hi, > >With the latest changes to kern_subr.c make fails. I have looked and some >"UIO_" stuff is defined in sys/uio.h but not this one. > >cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -nostdinc -I. -I../.. -I../../sys -I../../../include -DANGEL -DI586_CPU -DI486_CPU -DDODUMP -DGWETHER -DBOUNCE_BUFFERS -DUCONSOLE -DCOMPAT_43 -DPROCFS -DMFS -DFFS -DINET -DMATH_EMULATE -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../kern/kern_subr.c >../../kern/kern_subr.c: In function `uiomove': >../../kern/kern_subr.c:93: `UIO_NOCOPY' undeclared (first use this function) >../../kern/kern_subr.c:93: (Each undeclared identifier is reported only once >../../kern/kern_subr.c:93: for each function it appears in.) >*** Error code 1 Oops. Thanks - I forgot to commit the change. -DG From owner-freebsd-current Tue Apr 4 10:11:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA15460 for current-outgoing; Tue, 4 Apr 1995 10:11:32 -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 KAA15446 for ; Tue, 4 Apr 1995 10:10:24 -0700 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id TAA08834 for ; Tue, 4 Apr 1995 19:08:35 +0200 Message-Id: <199504041708.TAA08834@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: current@FreeBSD.org Subject: UNION File System... Date: Tue, 04 Apr 1995 19:08:35 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk Hi What is the current state of usefulness of UFS? Thanks M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Tue Apr 4 10:34:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA15773 for current-outgoing; Tue, 4 Apr 1995 10:34:23 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA15767 for ; Tue, 4 Apr 1995 10:34:21 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id KAA17124 for ; Tue, 4 Apr 1995 10:31:28 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 12:33:54 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 12:33:58 -0500 To: nate@sneezy.sri.com (Nate Williams) From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >But, *IF* both the src dist and /usr/include directories exist, the >include files are pulled out of /usr/src/include if they exist and >/usr/include next. (Which should never happen since /usr/src/include >should always contain all of the necessary include files which aren't in >the /usr/src/sys tree) I think that this is bogus behavior. If a file is missing from /usr/src/include, I don't want it to be "magically" found. Under your scheme, I will never be able to test a distribution tree for completeness on my production system. Further, a user who does not have the entire source distribution could "create" the includes by either copying or linking in /usr/include. Therefore, I think that your change MUST be retracted. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 10:56:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA17454 for current-outgoing; Tue, 4 Apr 1995 10:56:45 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA17440 for ; Tue, 4 Apr 1995 10:56:35 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id LAA06600; Tue, 4 Apr 1995 11:58:51 -0600 Date: Tue, 4 Apr 1995 11:58:51 -0600 From: Nate Williams Message-Id: <199504041758.LAA06600@trout.sri.MT.net> In-Reply-To: rkw@dataplex.net (Richard Wackerbarth) "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 4, 12:33pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > >But, *IF* both the src dist and /usr/include directories exist, the > >include files are pulled out of /usr/src/include if they exist and > >/usr/include next. (Which should never happen since /usr/src/include > >should always contain all of the necessary include files which aren't in > >the /usr/src/sys tree) > > I think that this is bogus behavior. > > If a file is missing from /usr/src/include, I don't want it to be > "magically" found. First of all, there are only two include files that are used that aren't in /usr/src/sys (for the genassym program and for one source file), so it's not a critical problem, and second of all if you don't want to worry about /usr/include stuff being picked up, do a 'mv /usr/include /usr/include.old' before building your kernel. This is more work for you, but penalizing you (minority) is much better than penalizing most folks who want to download the kernel sources and built custom kernels. > Under your scheme, I will never be able to test a > distribution tree for completeness on my production system. Okay, show me a better solution which doesn't *require* that people have /usr/src/include exist and that doesn't require a lot of work for the release engineer. > Further, a user who does not have the entire source distribution could > "create" the includes by either copying or linking in /usr/include. *BLECH* BSD systems have *never* (and should *never*) require that you have the complete source tree installed just to build a kernel. Making them go through alot of trouble to build a kernel is a waste of their time. Many, many more people build kernels w/out src trees than people who build kernels w/src trees. We are trying to make the system *easier* to use for the avg. user w/out penalizing the developer. Show me a solution that does that and it'll get into the tree. If it doesn't provide both, then it's not a complete solution. I wanted to provide a ENVIRONMENT variable which was set to provide /usr/src/include protection, but it was show down. Nate From owner-freebsd-current Tue Apr 4 11:34:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA19277 for current-outgoing; Tue, 4 Apr 1995 11:34:23 -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 LAA19264 for ; Tue, 4 Apr 1995 11:34:16 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id KAA07885; Tue, 4 Apr 1995 10:33:05 -0700 From: "Rodney W. Grimes" Message-Id: <199504041733.KAA07885@gndrsh.aac.dev.com> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: nate@trout.sri.MT.net (Nate Williams) Date: Tue, 4 Apr 1995 10:33:05 -0700 (PDT) Cc: rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <199504041758.LAA06600@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 11:58:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1514 Sender: current-owner@FreeBSD.org Precedence: bulk > > > >But, *IF* both the src dist and /usr/include directories exist, the > > >include files are pulled out of /usr/src/include if they exist and > > >/usr/include next. (Which should never happen since /usr/src/include > > >should always contain all of the necessary include files which aren't in > > >the /usr/src/sys tree) > > > > I think that this is bogus behavior. > > > > If a file is missing from /usr/src/include, I don't want it to be > > "magically" found. > > First of all, there are only two include files that are used that aren't > in /usr/src/sys (for the genassym program and for one source file), so > it's not a critical problem, and second of all if you don't want to > worry about /usr/include stuff being picked up, do a 'mv /usr/include > /usr/include.old' before building your kernel. The rule for genassym's should be changed such that it always uses /usr/include/stdio.h, that is the correct file to use, period, as it is going to be linked and run against /usr/lib/libc.a at the time the kernel is compiled. This will be extreamly important for cross compilation in the future. ... For now I am willing to live with what Nate did do the impact it has on our standard user base to do otherwise. We do need to look at better ways for fixing this, but as Nate said, until then this is a reasonable way to solve the problem. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Tue Apr 4 12:28:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA20933 for current-outgoing; Tue, 4 Apr 1995 12:28:37 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA20927 for ; Tue, 4 Apr 1995 12:28:32 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id MAA17798 for ; Tue, 4 Apr 1995 12:25:37 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 14:28:04 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 14:28:06 -0500 To: Nate Williams From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >*BLECH* BSD systems have *never* (and should *never*) require that you >have the complete source tree installed just to build a kernel. Making >them go through alot of trouble to build a kernel is a waste of their >time. Many, many more people build kernels w/out src trees than people >who build kernels w/src trees. We are trying to make the system >*easier* to use for the avg. user w/out penalizing the developer. > >Show me a solution that does that and it'll get into the tree. If it >doesn't provide both, then it's not a complete solution. I wanted to >provide a ENVIRONMENT variable which was set to provide /usr/src/include >protection, but it was show down. But I totally support the ENVIRONMENT variable. That is THE ONLY WAY you can have your cake and .... For those who want the "simple" approach, the defaults can pick up /usr/include. Actually, the general case is a more complex. You are doing two different things and they each need to be self contained. 1) You are building "tools" with which you will later build a system, and 2) You are building a system that will then be installed (on another machine) In case 1) the includes are those appropriate for the current system/libraries, and in case 2) the includes belong to the target system. In general, they are NOT the same. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 12:42:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA21245 for current-outgoing; Tue, 4 Apr 1995 12:42:02 -0700 Received: from dream.demos.su (dream.demos.su [192.91.186.135]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA21238 for ; Tue, 4 Apr 1995 12:41:58 -0700 Received: by dream.demos.su id XAA06084; (8.6.8/D) Tue, 4 Apr 1995 23:41:19 +0400 To: freebsd-current@freefall.cdrom.com Message-ID: Organization: Demos, Moscow, Russia Date: Tue, 4 Apr 1995 23:41:19 +0400 X-Mailer: Mail/@ [v2.22 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Strange kernel printf... Lines: 30 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 881 Sender: current-owner@FreeBSD.org Precedence: bulk I got strange printf on each kernel reboot, it comes to console and log both. Here piece of dmesg output: [skipped] bpf: ed0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16450 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16450 pca0 ^^^^^^^^^^^^^!!!!!! Watch this !!!!!!! pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in [skipped] I examine pcaudio.c and don't find any additional printf there except "pca0: PC speaker audio driver". Wrom where this magic "pca0" can come? Any ideas? Does anybody see it too? -- 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 Tue Apr 4 12:50:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA21377 for current-outgoing; Tue, 4 Apr 1995 12:50:21 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA21371 for ; Tue, 4 Apr 1995 12:50:16 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id NAA07051; Tue, 4 Apr 1995 13:53:56 -0600 Date: Tue, 4 Apr 1995 13:53:56 -0600 From: Nate Williams Message-Id: <199504041953.NAA07051@trout.sri.MT.net> In-Reply-To: rkw@dataplex.net (Richard Wackerbarth) "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 4, 2:28pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > >*BLECH* BSD systems have *never* (and should *never*) require that you > >have the complete source tree installed just to build a kernel. Making > >them go through alot of trouble to build a kernel is a waste of their > >time. Many, many more people build kernels w/out src trees than people > >who build kernels w/src trees. We are trying to make the system > >*easier* to use for the avg. user w/out penalizing the developer. > > > >Show me a solution that does that and it'll get into the tree. If it > >doesn't provide both, then it's not a complete solution. I wanted to > >provide a ENVIRONMENT variable which was set to provide /usr/src/include > >protection, but it was show down. > > But I totally support the ENVIRONMENT variable. That is THE ONLY WAY you > can have your cake and .... In defense of why it wasn't done, I think we have too many 'Environment' variable as it is. As has been stated so many times, our documentation stinks and adding yet-another kernel-Environ. variable makes things more confused. > For those who want the "simple" approach, the defaults can pick up > /usr/include. > Actually, the general case is a more complex. > You are doing two different things and they each need to be self contained. > > 1) You are building "tools" with which you will later build a system, and > 2) You are building a system that will then be installed (on another machine) > > In case 1) the includes are those appropriate for the current > system/libraries, and in case 2) the includes belong to the target system. > In general, they are NOT the same. Find a way for everything to work AND that is agreeable to the core folks and I'll commit it. Nate From owner-freebsd-current Tue Apr 4 13:55:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA23215 for current-outgoing; Tue, 4 Apr 1995 13:55:18 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA23209 for ; Tue, 4 Apr 1995 13:55:14 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA18525; Tue, 4 Apr 95 14:45:56 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504042045.AA18525@cs.weber.edu> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: nate@trout.sri.MT.net (Nate Williams) Date: Tue, 4 Apr 95 14:45:55 MDT Cc: rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <199504041758.LAA06600@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 11:58:51 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > *BLECH* BSD systems have *never* (and should *never*) require that you > have the complete source tree installed just to build a kernel. Making > them go through alot of trouble to build a kernel is a waste of their > time. Many, many more people build kernels w/out src trees than people > who build kernels w/src trees. We are trying to make the system > *easier* to use for the avg. user w/out penalizing the developer. I'm glad you said this. When will the binary link kit be available? I've often thought that it should be possible to configure devices in and out of the kernel without regenerating more than a single object file containing the device switches. The really nice thing about this, of course, is that multiport board drivers and Adaptec drivers using Adaptec code, and (potentially) the Intel supplied-for-MACH binary math coprocesser emulator could all be supplied without sources in full conformance to the non disclosure agreements required to obtain them. To make the nay-sayers happy, putting the source in escrow with the condition that a non-disclosure be signed to obtain it should be sufficient to not vest too much in a driver writer as a single point of failure. That's just a legal niceity, however, and the main point, that it be *possible*, is the important thing. Actually, sufficient reliance on a devfs, loadable modules, and soft autoconfiguration with a "save" for "/kernel -c" boot should make it totally unnecessary to have a link kit to get a new kernel configuration anyway. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Apr 4 14:14:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA23585 for current-outgoing; Tue, 4 Apr 1995 14:14:01 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA23579 for ; Tue, 4 Apr 1995 14:14:00 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id OAA19273 for ; Tue, 4 Apr 1995 14:11:06 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 16:13:25 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 16:13:28 -0500 To: "Rodney W. Grimes" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >The rule for genassym's should be changed such that it always uses >/usr/include/stdio.h, that is the correct file to use, period, as >it is going to be linked and run against /usr/lib/libc.a at the time >the kernel is compiled. This will be extreamly important for cross >compilation in the future. Actually, cross compilation is why it is WRONG!. There are two genassym's. One will be run on "this" machine to generate a kernel for "that" machine and the other is a version which will be in the distribution which is installed on "that" machine and used to rebuild the kernel. Since the two versions are linked against different libraries, it is important that thare is NO ABSOLUTE reference to any file. All references MUST be RELATIVE to the environment in which the code will be executed. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 14:24:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA23736 for current-outgoing; Tue, 4 Apr 1995 14:24:11 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA23730 for ; Tue, 4 Apr 1995 14:24:06 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id PAA07392; Tue, 4 Apr 1995 15:27:44 -0600 Date: Tue, 4 Apr 1995 15:27:44 -0600 From: Nate Williams Message-Id: <199504042127.PAA07392@trout.sri.MT.net> In-Reply-To: terry@cs.weber.edu (Terry Lambert) "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 4, 2:45pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: terry@cs.weber.edu (Terry Lambert) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: rkw@dataplex.net, current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > > *BLECH* BSD systems have *never* (and should *never*) require that you > > have the complete source tree installed just to build a kernel. Making > > them go through alot of trouble to build a kernel is a waste of their > > time. Many, many more people build kernels w/out src trees than people > > who build kernels w/src trees. We are trying to make the system > > *easier* to use for the avg. user w/out penalizing the developer. > > I'm glad you said this. > > When will the binary link kit be available? What does the binary link bit by the avg. user that downloading the source tree doesn't? Most of the sources have conditional code in them which makes a binary link kit less useful than a source-code kernel kit. And, it also is less sexy to get .o files when users can get sources. :) > The really nice thing about this, of course, is that multiport > board drivers and Adaptec drivers using Adaptec code, and (potentially) > the Intel supplied-for-MACH binary math coprocesser emulator could > all be supplied without sources in full conformance to the non > disclosure agreements required to obtain them. This can still be done. Read the docs on config on how to provide binary-only modules. It's fairly easy to setup, and it's how Ultrix is distributed currently. But, the issue of binary modules is a political one not a technical one. I'll let you deal with the bigger problem rather than attacking straw men. Nate From owner-freebsd-current Tue Apr 4 14:37:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA23941 for current-outgoing; Tue, 4 Apr 1995 14:37:04 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA23935 for ; Tue, 4 Apr 1995 14:36:57 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id PAA07441; Tue, 4 Apr 1995 15:40:34 -0600 Date: Tue, 4 Apr 1995 15:40:34 -0600 From: Nate Williams Message-Id: <199504042140.PAA07441@trout.sri.MT.net> In-Reply-To: rkw@dataplex.net (Richard Wackerbarth) "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 4, 4:13pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rkw@dataplex.net (Richard Wackerbarth), "Rodney W. Grimes" Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > >The rule for genassym's should be changed such that it always uses > >/usr/include/stdio.h, that is the correct file to use, period, as > >it is going to be linked and run against /usr/lib/libc.a at the time > >the kernel is compiled. This will be extreamly important for cross > >compilation in the future. > > Actually, cross compilation is why it is WRONG!. > > There are two genassym's. No, there is *one* genassym. > One will be run on "this" machine to generate a > kernel for "that" machine and the other is a version which will be in the > distribution which is installed on "that" machine and used to rebuild the > kernel. But only one is created per kernel build. You aren't going to get a cross-compilation environment to work if leave everything in the same directory. Genassym is used *once* during a kernel compile to build a program 'on the host machine' which generates kernel files 'for the target machine' kernel. Where genassym is built is a moot point? > Since the two versions are linked against different libraries, it is > important that thare is NO ABSOLUTE reference to any file. All references > MUST be RELATIVE to the environment in which the code will be executed. One version is built on the cross. machine, and another version is built on the host machine. Genassym won't run on the cross machine if it's compiled and linked with include files and libraries that exist for the target machine, and vice-versa. Nate From owner-freebsd-current Tue Apr 4 15:21:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA24481 for current-outgoing; Tue, 4 Apr 1995 15:21:38 -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 PAA24474 for ; Tue, 4 Apr 1995 15:21:35 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id OAA08375; Tue, 4 Apr 1995 14:20:56 -0700 From: "Rodney W. Grimes" Message-Id: <199504042120.OAA08375@gndrsh.aac.dev.com> Subject: Re: Strange kernel printf... To: ache@astral.msk.su (Andrey A. Chernov, Black Mage) Date: Tue, 4 Apr 1995 14:20:56 -0700 (PDT) Cc: freebsd-current@freefall.cdrom.com In-Reply-To: from "Andrey A. Chernov, Black Mage" at Apr 4, 95 11:41:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1150 Sender: current-owner@FreeBSD.org Precedence: bulk > > I got strange printf on each kernel reboot, it comes to console > and log both. > Here piece of dmesg output: > > [skipped] > bpf: ed0 attached > sio0 at 0x3f8-0x3ff irq 4 on isa > sio0: type 16450 > sio1 at 0x2f8-0x2ff irq 3 on isa > sio1: type 16450 > pca0 > ^^^^^^^^^^^^^!!!!!! Watch this !!!!!!! > pca0: PC speaker audio driver > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: NEC 765 > fd0: 1.44MB 3.5in > fd1: 1.2MB 5.25in > [skipped] > > I examine pcaudio.c and don't find any additional printf there > except "pca0: PC speaker audio driver". > Wrom where this magic "pca0" can come? > Any ideas? > Does anybody see it too? I beleive this is coming from some bad logic in isa.c that has gone through several changes in attempts to get it to print ``on isa'' for certain devices that use funny I/O addresses. It now under certain conditins prints nothing :-(., but atleast the newline is there :-) :-). I've been meaning to get in there and fix it, but if you would, please do. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Tue Apr 4 15:25:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA24574 for current-outgoing; Tue, 4 Apr 1995 15:25:54 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA24562 for ; Tue, 4 Apr 1995 15:25:52 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id PAA19925 for ; Tue, 4 Apr 1995 15:22:57 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 17:25:23 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 17:25:25 -0500 To: Nate Williams From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com Sender: current-owner@FreeBSD.org Precedence: bulk Nate Williams writes: >Where genassym is built is a moot point? > >> Since the two versions are linked against different libraries, it is >> important that thare is NO ABSOLUTE reference to any file. All references >> MUST be RELATIVE to the environment in which the code will be executed. > >One version is built on the cross. machine, and another version is built >on the host machine. Not necessarily. I should be able to build Genassym on th host machine, later to be run on the cross machine. There is no portion of the systen that I should not be able to pre-compile and then install. That way, a future "make" does not need to un-necessarily recompile those things that have not changed. Genassym is logically no different that say gcc. It is a tool that I will need to compile a new kernel. > Genassym won't run on the cross machine if it's compiled and linked > with include files and libraries that exist for the target machine, > and vice-versa. Precisely why I insist that there are two contexts in which the code be able to be compiled. In fact, this applies to ALL of the "tools", and that includes much of the system. Therefore, I conclude that ALL sources need to be "evaluated" in the context of an environment, as described by an environment variable. That variable would describe not only which sources, but also which includes to use. It would also describe the appropriate libraries to be linked and the "tools" to use in the creation. What I would propose is that we establish a variable TREE (I am open to other names) which designates a directory that contains everything needed. It would have a directory of tools (bin), headers (inc[lude]), sources (src), objects (obj), libraries (lib), and a destination directory (root). Any of these could be populated with symbolic links to another tree. In particular, I would allow this to be done at the directory level rather than just at the file level. This is not to say that these links are required, but that they are allowed and the system works when they are used. The one other thing that might be desirable would be a (link to) a top-level Makefile. In the default case, the "simple" user could simply use "/usr" as his tree. If ${TREE} is not defined, the default rule would provide it. Therefore, the simple user would not be affected. It is only the Makefiles that are impacted. So far, the ONLY reason expressed ("I don't like it" isn't a reason) against such a scheme is that I propose to keep the object in a parallel tree rather than using the "obj" links presently used. Actually, the current scheme already builds such a tree in /usr/obj. There is a "rule" to make appropriate links to that tree so that "make" (and some hackers) can find the objects. I propose to simply change the structure so that make does not DEPEND on those links, but rather tracks its object tree from its root. The "make obj rule" can then remain optionally available for those who wish to maintain the status quo and have only one environment. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 15:33:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA24795 for current-outgoing; Tue, 4 Apr 1995 15:33:31 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA24788; Tue, 4 Apr 1995 15:33:30 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Doug Rabson cc: current@FreeBSD.org Subject: Re: LINT settings In-reply-to: Your message of "Tue, 04 Apr 95 15:11:18 BST." Date: Tue, 04 Apr 1995 15:33:30 -0700 Message-ID: <24787.797034810@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I just put a new SoundBlaster16 + CD in my machine. All the FreeBSD > drivers appear to work fine (well I can play .au files and mount the > CDROM). One extremely minor point is that the default port setting for > the sbmidi0 device in LINT is 0x300 whereas the default on the card was > 0x330 (both on the card and in the manual). I think it was set this way to avoid SCSI controller clash.. Hmmmmmm. Suggestions? Jordan From owner-freebsd-current Tue Apr 4 15:44:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA25095 for current-outgoing; Tue, 4 Apr 1995 15:44:38 -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 PAA25089 for ; Tue, 4 Apr 1995 15:44:34 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id OAA08472; Tue, 4 Apr 1995 14:43:59 -0700 From: "Rodney W. Grimes" Message-Id: <199504042143.OAA08472@gndrsh.aac.dev.com> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: rkw@dataplex.net (Richard Wackerbarth) Date: Tue, 4 Apr 1995 14:43:59 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Apr 4, 95 04:13:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1362 Sender: current-owner@FreeBSD.org Precedence: bulk > > >The rule for genassym's should be changed such that it always uses > >/usr/include/stdio.h, that is the correct file to use, period, as > >it is going to be linked and run against /usr/lib/libc.a at the time > >the kernel is compiled. This will be extreamly important for cross > >compilation in the future. > > Actually, cross compilation is why it is WRONG!. You had better go understand genassym a bit more before you start in on this.... > There are two genassym's. One will be run on "this" machine to generate a > kernel for "that" machine and the other is a version which will be in the > distribution which is installed on "that" machine and used to rebuild the > kernel. Your never going to be able to put a genassym in the distribution that will last longer than a day with our kernel sources, and it would not work for all the possible kernel config options that a kernel can have. > Since the two versions are linked against different libraries, it is > important that thare is NO ABSOLUTE reference to any file. All references > MUST be RELATIVE to the environment in which the code will be executed. Drop this issue for now, until you have actually made what you are saying work. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Tue Apr 4 15:50:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA25238 for current-outgoing; Tue, 4 Apr 1995 15:50:35 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA25232 for ; Tue, 4 Apr 1995 15:50:34 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id PAA20031 for ; Tue, 4 Apr 1995 15:47:39 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 17:49:54 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 17:49:56 -0500 To: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Sender: current-owner@FreeBSD.org Precedence: bulk Rodney Grimes writes: >You are missing a very important fact about genassym, it *IS* heavly >dependent upon the kernel configuration file. Your not going to be able >to make a version of the binary genassym that will work for all kernel >builds. It must be built and run on the ``hosted'' system, it is >meaningless to build a ``targeted'' system version of it. But the same could be said about any "tool" used to make a kernel. I see absolutely no reason why you should treat the correct production of a genassym that ends up on the target machine any differently from say gcc. I should be able to precompile EVERYTHING and then recompile ONLY those elements that depend on something that has changed. So maybe that means that genassym gets recompiled almost anytime I change the kernel. Maybe it doesn't. "Make" should properly take care of it in either case. There should not be a special case for this one tool. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 15:51:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA25251 for current-outgoing; Tue, 4 Apr 1995 15:51:04 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA25245 for ; Tue, 4 Apr 1995 15:50:59 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id QAA07754; Tue, 4 Apr 1995 16:54:41 -0600 Date: Tue, 4 Apr 1995 16:54:41 -0600 From: Nate Williams Message-Id: <199504042254.QAA07754@trout.sri.MT.net> In-Reply-To: rkw@dataplex.net (Richard Wackerbarth) "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 4, 5:25pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com Sender: current-owner@FreeBSD.org Precedence: bulk > >Where genassym is built is a moot point? > > > >> Since the two versions are linked against different libraries, it is > >> important that thare is NO ABSOLUTE reference to any file. All references > >> MUST be RELATIVE to the environment in which the code will be executed. > > > >One version is built on the cross. machine, and another version is built > >on the host machine. > > Not necessarily. I should be able to build Genassym on th host machine, > later to be run on the cross machine. Huh? If you can build it on the host machine, then do it there. Doing part of the kernel compile on the cross machine and part of it on the target machine is just silly. > There is no portion of the systen > that I should not be able to pre-compile and then install. That way, a > future "make" does not need to un-necessarily recompile those things that > have not changed. 'genassym' is a temporary program used in the kernel compile process. It exists solely for kernel compiles. It can be called a 'tool', but it's a very poor definition since it's only used once. > Genassym is logically no different that say gcc. It is a tool that I will > need to compile a new kernel. But genassym is not built separately. It is built as *part* of the kernel compile process. I'm goint to shutup now since the point of the arguement is lost. I have *much* better things to do than argue about what tools should be built by the cross compiler and what should be built native. We are both arguing about something which is such a trivial bug in the system which affects < .01% of the users, when there are bugs that affect 90-100% of the users. You want to completely throw away the entire build process as it is now. That's *NOT* going to happen anytime soon. > So far, the ONLY reason expressed ("I don't like it" isn't a reason) > against such a scheme is that I propose to keep the object in a parallel > tree rather than using the "obj" links presently used. 1) Is really any better than what we have for the majority of the users. There are much bigger fish to fry, but you are welcome to go off and do this yourself. 2) Is it feasible? 3) Will you do all the work required to make it work right No more on this topic from me. (The group sighs with relief) Nate From owner-freebsd-current Tue Apr 4 16:27:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA26186 for current-outgoing; Tue, 4 Apr 1995 16:27:14 -0700 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA26178 for ; Tue, 4 Apr 1995 16:27:11 -0700 Received: from starkhome.UUCP (root@localhost) by sbstark.cs.sunysb.edu (8.6.9/8.6.9) with UUCP id TAA09701 for current@freebsd.org; Tue, 4 Apr 1995 19:26:42 -0400 Received: by starkhome.cs.sunysb.edu (8.6.11/1.34) id TAA00272; Tue, 4 Apr 1995 19:23:57 -0400 Date: Tue, 4 Apr 1995 19:23:57 -0400 From: starkhome!gene@sbstark.cs.sunysb.edu (Gene Stark) Message-Id: <199504042323.TAA00272@starkhome.cs.sunysb.edu> To: current@FreeBSD.org Subject: April 3 kernel breakage Sender: current-owner@FreeBSD.org Precedence: bulk Under a kernel built with April 3 sources many things fail miserably with signal 11: Apr 4 19:16:01 starkhome /kernel: pid 42: ifconfig: uid 0: exited on signal 11 Apr 4 19:16:01 starkhome /kernel: pid 48: ifconfig: uid 0: exited on signal 11 Apr 4 19:16:01 starkhome /kernel: pid 54: ifconfig: uid 0: exited on signal 11 Apr 4 19:16:01 starkhome /kernel: pid 73: savecore: uid 0: exited on signal 11 Apr 4 19:16:01 starkhome /kernel: pid 74: kvm_mkdb: uid 0: exited on signal 11 This even occurs after completing a full "make world" and then rebuilding the kernel. I tried running gdb on "savecore" and it was dying within a call to strcmp(). Did I miss some incredibly important bootstrapping procedure recently? - Gene From owner-freebsd-current Tue Apr 4 16:36:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA26399 for current-outgoing; Tue, 4 Apr 1995 16:36:36 -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 QAA26389 for ; Tue, 4 Apr 1995 16:36:30 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id QAA07103; Tue, 4 Apr 1995 16:36:02 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id QAA00195; Tue, 4 Apr 1995 16:36:02 -0700 Message-Id: <199504042336.QAA00195@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: Mark Murray cc: current@FreeBSD.org Subject: Re: UNION File System... In-reply-to: Your message of "Tue, 04 Apr 95 19:08:35 +0200." <199504041708.TAA08834@grunt.grondar.za> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 04 Apr 1995 16:36:00 -0700 Sender: current-owner@FreeBSD.org Precedence: bulk >What is the current state of usefulness of UFS? It's completely broken. -DG From owner-freebsd-current Tue Apr 4 16:36:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA26416 for current-outgoing; Tue, 4 Apr 1995 16:36:54 -0700 Received: from mpp.com (dialup-4-42.gw.umn.edu [128.101.96.42]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA26406 for ; Tue, 4 Apr 1995 16:36:49 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id SAA01357; Tue, 4 Apr 1995 18:31:52 -0500 From: Mike Pritchard Message-Id: <199504042331.SAA01357@mpp.com> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: nate@trout.sri.MT.net (Nate Williams) Date: Tue, 4 Apr 1995 18:31:52 -0500 (CDT) Cc: rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <199504041758.LAA06600@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 11:58:51 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: 1372 Sender: current-owner@FreeBSD.org Precedence: bulk > > Further, a user who does not have the entire source distribution could > > "create" the includes by either copying or linking in /usr/include. > > *BLECH* BSD systems have *never* (and should *never*) require that you > have the complete source tree installed just to build a kernel. Making > them go through alot of trouble to build a kernel is a waste of their > time. Many, many more people build kernels w/out src trees than people > who build kernels w/src trees. We are trying to make the system > *easier* to use for the avg. user w/out penalizing the developer. > > Show me a solution that does that and it'll get into the tree. If it > doesn't provide both, then it's not a complete solution. I wanted to > provide a ENVIRONMENT variable which was set to provide /usr/src/include > protection, but it was show down. > > Nate Ok, how about conditionally adding /usr/include to the -I list. E.g. in the kernel makefile do: .if !exist /usr/src/include CFLAGS +=-I/usr/include .endif (or whatever the correct makefile syntax is) If I have /usr/src/include installed then my kernel build uses the include files from my source tree. If I simply downloaded just the kernel sources, then it will pick up the include files from /usr/include. -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-current Tue Apr 4 16:45:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA26701 for current-outgoing; Tue, 4 Apr 1995 16:45:32 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA26694 for ; Tue, 4 Apr 1995 16:45:27 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA08194; Tue, 4 Apr 1995 17:49:08 -0600 Date: Tue, 4 Apr 1995 17:49:08 -0600 From: Nate Williams Message-Id: <199504042349.RAA08194@trout.sri.MT.net> In-Reply-To: Mike Pritchard "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 4, 6:31pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Mike Pritchard Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: rkw@dataplex.net, current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > Ok, how about conditionally adding /usr/include to the -I list. > E.g. in the kernel makefile do: > > .if !exist /usr/src/include > CFLAGS +=-I/usr/include > .endif Hmm, a spruced up variant on that would do the trick. What do other folks think? > "Go that way. Really fast. If something gets in your way, turn" Ahh, skiing. :-) Nate From owner-freebsd-current Tue Apr 4 17:14:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA27154 for current-outgoing; Tue, 4 Apr 1995 17:14:51 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA27148 for ; Tue, 4 Apr 1995 17:14:49 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id RAA20540 for ; Tue, 4 Apr 1995 17:11:54 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 19:14:11 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 19:14:14 -0500 To: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net From: rkw@dataplex.net (Richard Wackerbarth) Subject: Genassym Sender: current-owner@FreeBSD.org Precedence: bulk OK! I have an "out" that I think might satisfy all of our demands. 1) ALWAYS force genassym to reference /usr/include for its library headers. 2) NEVER include the objects or binaries of any of the kernel or kernel specific tools in any distribution. REQUIRE that they be recompiled when used on any machine. After all, as Nate points out, genassym is a "tool" to be executed on the host machine and not something that runs on the target. I haven't looked at genassym, but assume that it uses the sys headers only as input text, or equivalently, conditional conpilation flags. If it makes any assumptions about kernel data structures, etc. it will eventually break in cross platform compilation. :( -- OR -- Allow me to specify a correct cross-compilation environment and move genassym to the "tools" portion of that structure. In that case, the correct files will be automatically referenced. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 18:16:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA28319 for current-outgoing; Tue, 4 Apr 1995 18:16:27 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA28313 for ; Tue, 4 Apr 1995 18:16:24 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA24717; Tue, 4 Apr 95 19:09:28 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504050109.AA24717@cs.weber.edu> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: nate@trout.sri.MT.net (Nate Williams) Date: Tue, 4 Apr 95 19:09:28 MDT Cc: rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <199504042127.PAA07392@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 03:27:44 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > What does the binary link bit by the avg. user that downloading the > source tree doesn't? Most of the sources have conditional code in them > which makes a binary link kit less useful than a source-code kernel kit. One source tree worth of disk space. 8-). The need to install 'ld' but not 'cc' if it's done right. 8-) > And, it also is less sexy to get .o files when users can get sources. :) Well, yeah... there is that. }B-). > > The really nice thing about this, of course, is that multiport > > board drivers and Adaptec drivers using Adaptec code, and (potentially) > > the Intel supplied-for-MACH binary math coprocesser emulator could > > all be supplied without sources in full conformance to the non > > disclosure agreements required to obtain them. > > This can still be done. Read the docs on config on how to provide > binary-only modules. It's fairly easy to setup, and it's how Ultrix is > distributed currently. Yeah; the problem is that it isn't really as "drop-in" as System V at this point. It ought to bea able to beat up System V. 8-). Basically, there's no place to just drop your binary files in. This is kinda out of it until the device and device driver writer kernel exported interfaces are cleaned up to the point that no one will screw with them for long enough that a binary driver could live through a couple of releases without changes. The main problem is one of synchronizing developement efforts between multiple object sources when any *BSD is an "also ran" that doesn't get a commercial driver until the write happens to hit a lull in their tech support calls to let them work on it. 8-(. > But, the issue of binary modules is a political one not a technical one. > I'll let you deal with the bigger problem rather than attacking straw > men. Sigh. 8-(. You are right that it is political; I tried to abate that somewhat with the "escrow" argument for people who would like to make the code available but can't because of the non-disclosure. Given a choice between code that runs my hardware with no sources and no code to run my hardware, I know which I'd choose, politically incorrect though that might be. 8-(. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Apr 4 19:24:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA29666 for current-outgoing; Tue, 4 Apr 1995 19:24:37 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA29655 for ; Tue, 4 Apr 1995 19:24:15 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 21:23:18 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 21:23:21 -0500 To: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net From: rkw@dataplex.net (Richard Wackerbarth) Subject: NOTICE: If you care, speak now! Cc: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk I WANT to make a significant change to the way new systems get built. The purpose is to reduce unnecessary recompilations, allow read-only source trees, and prepare for cross-compilation. Is this something that the community will accept? Your support or opposition is requested. Silence will be considered acceptance. I have a structure that will allow: The "upside": 1) The environment of the host system is NOT disturbed by the "making" of a new release. 2) The source and object files MAY be shared by multiple releases without impacting each other. 3) The tree MAY be on read-only media. If you wish to change only a part of the tree, only the affected parts need be on writeable media. 4) Redundant compiles are eliminated. "make all" folled by a second "make all" will not cause anything to be recompiled. (The compressed man pages are another, but related, issue) The "downside": 1) To build a new kernel, etc. you must place it in a proper "tree" structure. That tree can be rooted anywhere you wish. ( This could be handled by a script or possibly special "make" targets.) 2) Unless you are in a "proper" tree, you must either do a make from the root of the tree OR predefine the TREE environmental variable. An "aside": The default behavior would be for a proper tree rooted at /usr. In this case, the behavior would be sililar to the current operation. "Obj" links could optionally be added and would work IF you have only one version of the tree. They would be "for reference only" and not used to build the system. =============== PROPOSED PLAN OF ATTACK For this to happen, I will require the cooperation of ALL comitters. We will need a "standard" for "correct" Makefiles. Once it is determined, anyone who changes a Makefile would make the alterations to meet the specification. In order to implement this, I propose 1) By Thursday, I will distribute a proposed "standard" for the make files. 2) By Monday, we will agree to the standard. 3) I'll make changes to the .mk files to make them accept both the present Makefiles as well as those that conform to the new standard. 4) Over some period (depending on complexity/manpower) we convert ALL Makefiles to the new standard. 5) I then commit new .mk files which implement the new structure. ================= OK, gang, I've "argued" this for a few days. So far, I have heard from only a very few. Garrett "objects", but has not stated ANY reason. Nate and Rodney seem to think it won't work, but only because they think that Genassym is "special". I interpret their comments as "It's OK if it doesn't break anything". Rodney writes: >Drop this issue for now, until you have actually made what you are >saying work. It DOES work if you allow me my TREE variable (or require that I cd there to type "make"). Just remember that genassym is a "tool" and gets made in the tool environment which would be the same as /usr except that I prefer to indirect it one level so that I don't clobber a "good" version of a tool with a bad one that I just modified. Nate writes: >1) Is really any better than what we have for the majority of the users. It does not affect most "users". It only changes the "standard" by which "conforming" Makefiles are written and the .mk files to support them. >2) Is it feasible? Only it there is an authority that can reject Makefiles that do not conform to the agreed standard. >3) Will you do all the work required to make it work right I already have done much of it on my own system. The problem is that there was too much "I don't want to do it that way" for me to feel that this group could reach ANY standard. The entire Make system NEEDS to be redone. The warts have overwelmed the substance. Everyone would benefit from a cleaner system. "Make world" would become much faster because we have not yet gotten to the case of true cross compilation. There is a lot of unnecessary duplication because the source tree is being used to make both tools and a target when they are, in fact, the same. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 19:35:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA29937 for current-outgoing; Tue, 4 Apr 1995 19:35:53 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA29927 for ; Tue, 4 Apr 1995 19:35:49 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id UAA08889; Tue, 4 Apr 1995 20:39:14 -0600 Date: Tue, 4 Apr 1995 20:39:14 -0600 Message-Id: <199504050239.UAA08889@trout.sri.MT.net> To: rkw@dataplex.net (Richard Wackerbarth) Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net, "Jordan K. Hubbard" Subject: Re: NOTICE: If you care, speak now! In-Reply-To: References: Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Richard Wackerbarth writes: > I WANT to make a significant change to the way new systems get built. > The purpose is to reduce unnecessary recompilations, allow read-only source > trees, and prepare for cross-compilation. > > Is this something that the community will accept? Your support or > opposition is requested. Silence will be considered acceptance. Okay, my response is: Not now. After 2.1 is released. Nate From owner-freebsd-current Tue Apr 4 19:40:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA00277 for current-outgoing; Tue, 4 Apr 1995 19:40:03 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA00270 for ; Tue, 4 Apr 1995 19:40:02 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id TAA05699; Tue, 4 Apr 1995 19:39:34 -0700 From: Poul-Henning Kamp Message-Id: <199504050239.TAA05699@ref.tfs.com> Subject: Re: NOTICE: If you care, speak now! To: rkw@dataplex.net (Richard Wackerbarth) Date: Tue, 4 Apr 1995 19:39:33 -0700 (PDT) Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net, jkh@freefall.cdrom.com In-Reply-To: from "Richard Wackerbarth" at Apr 4, 95 09:23:21 pm Content-Type: text Content-Length: 476 Sender: current-owner@FreeBSD.org Precedence: bulk > I WANT to make a significant change to the way new systems get built. > The purpose is to reduce unnecessary recompilations, allow read-only source > trees, and prepare for cross-compilation. Rich, nice, but I doubt your timing is good. This seems to be too extensive for 2.1 at this time. -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant' From owner-freebsd-current Tue Apr 4 19:58:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA00574 for current-outgoing; Tue, 4 Apr 1995 19:58:04 -0700 Received: from obiwan.pmr.com (obiwan.pmr.com [199.98.84.130]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA00568 for ; Tue, 4 Apr 1995 19:58:00 -0700 Received: by obiwan.pmr.com (Smail3.1.29.1 #4) id m0rwLHu-000300C; Tue, 4 Apr 95 21:57 CDT Message-Id: From: bob@obiwan.pmr.com (Bob Willcox) Subject: Re: Proper procedure to partition/label disk now? To: bde@zeta.org.au (Bruce Evans) Date: Tue, 4 Apr 1995 21:57:46 -0500 (CDT) Cc: bde@zeta.org.au, freebsd-current@freefall.cdrom.com In-Reply-To: <199504041445.AAA24580@godzilla.zeta.org.au> from "Bruce Evans" at Apr 5, 95 00:45:57 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2641 Sender: current-owner@FreeBSD.org Precedence: bulk Bruce Evans wrote: > > >> For using the whole disk for FreeBSD, just run disklabel. The man > >> page may actually be complete now that the 'd' partition isn't > >> special. This assumes that the disk really is clean, without > >> misleading junk in the partition table. > > >Ok, I've done that. When I mount the filesystem (after having > >newfs'd it) I get the following messages: > > >Apr 4 08:14:27 luke /kernel: sd2: invalid primary partition table: no magic > >Apr 4 08:14:27 luke /kernel: sd2: raw partition size != slice size > >Apr 4 08:14:27 luke /kernel: sd2: start 0, end 782599, size 782600 > >Apr 4 08:14:27 luke /kernel: sd2c: start 0, end 782335, size 782336 > > These messages are only warnings. Should they be removed? The first one I fear that they are going to be a concern to users as they convert from 1.1.5 or 2.0 to 2.1. Lots of folks will think something is broken when they see these messages. > says that there is apparently no partition table. `disklabel -B' would > write a suitable partition table. The message should never be printed > for bootable disks. The last 3 say that you made the raw partition > size smaller than the disk size. This is a strange thing to do because > the raw partition is supposed to cover the whole disk. There is no > reason to round it to a cylinder boundary. I did the ``disklabel -B'' and got rid of the first message. The disklabel was created in the pre-2.1 style using the ficticious geometry popular during that era. What would really be nice would be a facility for labeling disks similar to what sysinstall provides. The manual calculations are a real pain. > > >Here is the disklabel for the drive: > > ># /dev/rsd2c: > >... > >sectors/unit: 782600 > >... > >4 partitions: > ># size offset fstype [fsize bsize bps/cpg] > > a: 782336 0 4.2BSD 1024 8192 16 # (Cyl. 0 - 381) > > c: 782336 0 unused 0 0 # (Cyl. 0 - 381) > > d: 782336 0 unused 0 0 # (Cyl. 0 - 381) > > The sectors/unit value isn't rounded. Good. Perhaps it should be checked > instead of the 'c' partition size. No, I just remembered why not. Old > labels have to be converted, and the sectors/unit value is guaranteed > to be wrong (being for the whole disk ond not for the BSD slice) except > when there is only one slice, so the 'c' partition size has to be trusted. > > The 'd' partition shouldn't be necessary. Yeah, this is an artifact of the disktab entry I used to create the label. -- Bob Willcox bob@obiwan.pmr.com (or obiwan%bob@uunet.uu.net) Austin, TX From owner-freebsd-current Tue Apr 4 20:05:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA00691 for current-outgoing; Tue, 4 Apr 1995 20:05:48 -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 UAA00685 for ; Tue, 4 Apr 1995 20:05:44 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id UAA07653; Tue, 4 Apr 1995 20:05:18 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id UAA00156; Tue, 4 Apr 1995 20:05:17 -0700 Message-Id: <199504050305.UAA00156@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: rkw@dataplex.net (Richard Wackerbarth) cc: current@FreeBSD.org Subject: Re: NOTICE: If you care, speak now! In-reply-to: Your message of "Tue, 04 Apr 95 21:23:21 CDT." From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 04 Apr 1995 20:05:15 -0700 Sender: current-owner@FreeBSD.org Precedence: bulk >Just remember that genassym is a "tool" and gets made in the tool >environment which would be the same as /usr except that I prefer to >indirect it one level so that I don't clobber a "good" version of a tool >with a bad one that I just modified. Umm, genassym isn't a tool. Not only is it highly dependant on the host machine's idea of type sizes, but it must be rebuilt whenever any header file it depends on is changed...very important that this be done as part of the kernel build sequence (i.e. it shouldn't be part of the regular source tree). ...Perhaps I don't understand what you mean above. -DG From owner-freebsd-current Tue Apr 4 20:25:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA01215 for current-outgoing; Tue, 4 Apr 1995 20:25: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 UAA01209 for ; Tue, 4 Apr 1995 20:25:07 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id TAA09355; Tue, 4 Apr 1995 19:24:11 -0700 From: "Rodney W. Grimes" Message-Id: <199504050224.TAA09355@gndrsh.aac.dev.com> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: nate@trout.sri.MT.net (Nate Williams) Date: Tue, 4 Apr 1995 19:24:10 -0700 (PDT) Cc: pritc003@maroon.tc.umn.edu, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <199504042349.RAA08194@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 05:49:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 776 Sender: current-owner@FreeBSD.org Precedence: bulk > > > Ok, how about conditionally adding /usr/include to the -I list. > > E.g. in the kernel makefile do: > > > > .if !exist /usr/src/include > > CFLAGS +=-I/usr/include > > .endif Reasonable for now, until the all singing all dancing cross platform build stuff hits us. Probably a little cleaner than what we have in there now. > Hmm, a spruced up variant on that would do the trick. What do other > folks think? > > > "Go that way. Really fast. If something gets in your way, turn" > > Ahh, skiing. :-) No, ``YaHOoooo... skydiving...'' just don't try to turn when the ground comes, then it is time to pull. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Tue Apr 4 20:50:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA01722 for current-outgoing; Tue, 4 Apr 1995 20:50:48 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA01714 for ; Tue, 4 Apr 1995 20:50:46 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id UAA21172 for ; Tue, 4 Apr 1995 20:47:39 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 22:50:05 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 22:50:08 -0500 To: Poul-Henning Kamp From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: NOTICE: If you care, speak now! Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk Poul-Henning Kamp writes: >nice, but I doubt your timing is good. This seems to be too extensive >for 2.1 at this time. 1) I've been working on this idea for some time. The changes to do a 90% job are really pretty minor. 2) There are no changes to any of the code, just the makefiles and .mk files. Debugging is very simple. -- Either everything compiles or it doesn't. If you have a proper /usr/src and /usr/obj with the "make obj" links installed, you would not notice any difference. 3) This is no more of a change than the changes to "install" that are being so widely advocated. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 20:58:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA01880 for current-outgoing; Tue, 4 Apr 1995 20:58:08 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA01874 for ; Tue, 4 Apr 1995 20:58:07 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id UAA20191; Tue, 4 Apr 1995 20:57:41 -0700 Date: Tue, 4 Apr 1995 20:57:38 -0700 From: Richard Chang To: FreeBSD-current@freefall.cdrom.com Subject: slip and ppp not working (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Just an update, slip works fine now after I did a make world on current as of 4/3/95 9PM PDT.. But ppp still doesn't work, pppd starts but when I did telnet hostname, it would just say Hostname lookup not found but it works fine with slip, any ideas? This same setup worked fine with the 3/30/95 -current... --richardc I don't know what happened... Yesterday sup wasn't working so Justin G. helped me on that one and the machine locked up so I rebooted and now ppp doesn't work at all, somehow it's not getting packets out of the machine.... slip works but when I start it, it says: Apr 2 16:45:31 bigbang slattach[196]: cannot get carrier state: Inappropriate ioctl for device Apr 2 16:45:31 bigbang slattach[196]: Waiting for carrier on /dev/cua00 (sl-1) For ppp, it just doesn't know how to handle hostnames but with ip numbers, it would just say the network is down... Anyone have any ideas? Thanks.. --richardc From owner-freebsd-current Tue Apr 4 21:04:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01942 for current-outgoing; Tue, 4 Apr 1995 21:04:02 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA01936 for ; Tue, 4 Apr 1995 21:03:58 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id WAA09298; Tue, 4 Apr 1995 22:07:41 -0600 Date: Tue, 4 Apr 1995 22:07:41 -0600 Message-Id: <199504050407.WAA09298@trout.sri.MT.net> To: rkw@dataplex.net (Richard Wackerbarth) Cc: Poul-Henning Kamp , current@FreeBSD.org Subject: Re: NOTICE: If you care, speak now! In-Reply-To: References: Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Richard Wackerbarth writes: > >nice, but I doubt your timing is good. This seems to be too extensive > >for 2.1 at this time. > > 1) I've been working on this idea for some time. The changes to do a 90% > job are really pretty minor. The first 90% of the time you spend on a project take up 90% of the time. The other 10% of the project takes up the remaining 90% of the time. It's always the last 10% of the job that scares me the most. > 2) There are no changes to any of the code, just the makefiles and .mk files. > Debugging is very simple. -- Either everything compiles or it doesn't. > If you have a proper /usr/src and /usr/obj with the "make obj" links > installed, you would not notice any difference. That is the kind of extensive changes that shouldn't be made this late in the game. > 3) This is no more of a change than the changes to "install" that are being > so widely advocated. Huh? The install change affects *one* utility, but the changes you are advocating effect the entire build process, and from the sounds of it every Makefile. And, as a rebuttal, even though the install changes are to one tool, because of the significance of the tool those changes might not make it into the release. Nate From owner-freebsd-current Tue Apr 4 21:04:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01955 for current-outgoing; Tue, 4 Apr 1995 21:04:13 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA01948; Tue, 4 Apr 1995 21:04:12 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: rkw@dataplex.net (Richard Wackerbarth) cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.mt.net Subject: Re: NOTICE: If you care, speak now! In-reply-to: Your message of "Tue, 04 Apr 95 21:23:21 CDT." Date: Tue, 04 Apr 1995 21:04:11 -0700 Message-ID: <1947.797054651@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I WANT to make a significant change to the way new systems get built. > The purpose is to reduce unnecessary recompilations, allow read-only source > trees, and prepare for cross-compilation. > > Is this something that the community will accept? Your support or > opposition is requested. Silence will be considered acceptance. Let me pick a general bone with you about this, Richard. For the last few months, you've talked in very grand and sweeping terms about the structure you've evolved, but no one else has really had a chance to truly react to any of the SPECIFICS of it because you don't actually have it RUNNING anywhere! So you send instead out these long missive and everyone goes "Hmmm. Sounds interesting. Sounds complex. I'd have to see it in action!" and then they put it aside. You get get frustrated at the total lack of feedback, everyone is frustrated with you for hearing a lot of fairly good sounding ideas but having no MEAT to chew on, and so it goes! If you're really serious about this, then before you commit *anything* you need to bring it up on a machine completely and totally so that others can run test builds with it and make comments. I'm sorry, but until I actually *KNOW* and can *SEE* your changes doing everything they're supposed to do on a real live box then I can't support them and I doubt that many others will step forward and do so either. If it's just the question of a box to work on, I think thud could be more than happily "sacrificed" to the cause. Nobody sups its /usr/src tree, and it can be torn down and recreated at a moment's notice if things get totally screwed up. OK? > I already have done much of it on my own system. The problem is that there > was too much "I don't want to do it that way" for me to feel that this > group could reach ANY standard. The entire Make system NEEDS to be redone. > The warts have overwelmed the substance. Everyone would benefit from a > cleaner system. "Make world" would become much faster because we have not > yet gotten to the case of true cross compilation. There is a lot of > unnecessary duplication because the source tree is being used to make both > tools and a target when they are, in fact, the same. There's no question that we could all benefit significantly from a cleaner environment, we just have to see it before we're going to "buy" it! You're otherwise asking us to accept major upheaval sight-unseen! :-) Jordan From owner-freebsd-current Tue Apr 4 21:07:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA02007 for current-outgoing; Tue, 4 Apr 1995 21:07:32 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA01995; Tue, 4 Apr 1995 21:07:30 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: nate@sneezy.sri.com (Nate Williams) cc: rkw@dataplex.net (Richard Wackerbarth), current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.mt.net Subject: Re: NOTICE: If you care, speak now! In-reply-to: Your message of "Tue, 04 Apr 95 20:39:14 MDT." <199504050239.UAA08889@trout.sri.MT.net> Date: Tue, 04 Apr 1995 21:07:30 -0700 Message-ID: <1993.797054850@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > Okay, my response is: > > Not now. After 2.1 is released. Since it's *never* a good time to do these things, I'll be more flexible: 1. Do what I requested before and bring the entire system up on a public test box, first. Let us all do a few make worlds and examine it. 2. If it looks really good and doesn't break things significantly, I say go for it. My reasoning is that 2.1's make brokenness is already pretty well known, and if it's easier to switch horses than give the old one I've got a face-lift, then I'm interested. It's that comparison that I'm waiting to now see with my own eyes. Jordan From owner-freebsd-current Tue Apr 4 21:14:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA02173 for current-outgoing; Tue, 4 Apr 1995 21:14:43 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA02167 for ; Tue, 4 Apr 1995 21:14:36 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id WAA09370; Tue, 4 Apr 1995 22:18:09 -0600 Date: Tue, 4 Apr 1995 22:18:09 -0600 From: Nate Williams Message-Id: <199504050418.WAA09370@trout.sri.MT.net> In-Reply-To: Mike Pritchard "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 4, 6:31pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Mike Pritchard Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: rkw@dataplex.net, current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > Ok, how about conditionally adding /usr/include to the -I list. > E.g. in the kernel makefile do: > > .if !exist /usr/src/include > CFLAGS +=-I/usr/include > .endif > > (or whatever the correct makefile syntax is) > > If I have /usr/src/include installed then my kernel build uses the include > files from my source tree. If I simply downloaded just the kernel sources, > then it will pick up the include files from /usr/include. Thanks Mike. I used your ideas to cleanup the tree, which should now cause all nay-sayers to agree that given the current constraints, it *should* do the right thing. Basically, this allows folks who don't have the srcdist installed (basically the src/include directory) to pick up any necessary includes from /usr/include. However, if src/includes exists, then it will be used and /usr/include will never enter the picture. This means if you have an incomplete src/include tree you're hosed, but I guess if it's incomplete you're hosed anyway. Richard, is this an 'acceptable' solution? (I know it's not the best solution, but we don't have that yet) Nate From owner-freebsd-current Tue Apr 4 22:20:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03567 for current-outgoing; Tue, 4 Apr 1995 22:20:12 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03561 for ; Tue, 4 Apr 1995 22:20:11 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id WAA21349 for ; Tue, 4 Apr 1995 22:17:16 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Wed, 5 Apr 1995 00:19:42 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Apr 1995 00:19:45 -0500 To: Nate Williams From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Richard, is this an 'acceptable' solution? (I know it's not the best >solution, but we don't have that yet) Actually, I can live with either solution as a temporary measure. The recognition that it is "stopgap" rather than "correct" is the important feature to me. What I don't want to see is the propogation of a wrong philosophy. My whole point is that none of the code is written for a single static environment. We need to make sure that we are moving in the direction of environment based references. When you want to make a "tool" to use now, the execution environment is the HOST system. When you make that same tool to be included in a release, the execution environment is that of the TARGET. However, the source code for that tool is exactly the same. Only the libraries and, by extension, the include files that define their interface are changed. "Make"ing in these different environments will in general produce different results -- results that should end up in different places. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 22:22:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03607 for current-outgoing; Tue, 4 Apr 1995 22:22:45 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03601 for ; Tue, 4 Apr 1995 22:22:44 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id WAA21353 for ; Tue, 4 Apr 1995 22:19:48 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Wed, 5 Apr 1995 00:21:59 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Apr 1995 00:22:03 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: NOTICE: If you care, speak now! Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net Sender: current-owner@FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: >Since it's *never* a good time to do these things, I'll be more flexible: >1. Do what I requested before and bring the entire system up on a public >test box, first. Let us all do a few make worlds and examine it. >2. If it looks really good and doesn't break things significantly, I say >go for it. Thanks for the encouragement. >If you're really serious about this, then before you commit *anything* >you need to bring it up on a machine completely and totally so that >others can run test builds with it and make comments. I'm sorry, but >until I actually *KNOW* and can *SEE* your changes doing everything >they're supposed to do on a real live box then I can't support them >and I doubt that many others will step forward and do so either. I have no problem with your reluctance to "accept" something "sight unseen". I do have a problem with trying to do something with virtually no feedback from the intended "users". If you will read my proposals, I am asking for an agreement that the group will support a change toward the goals that I have stated. If that is achieved, I then ask for acceptance of a specific methodology. I would expect the actual changes to be accepted only after others have adequately reviewed the work. Personally, I see little reason to have more than a very few "targets" at the top level. Make "all", "install", and "distribution" are about all that I see as significant. The important change is that the compiles (for the distribution version, not the "tools" subset) will all be done WITHOUT REFERENCE to the host system. I also want to eliminate the "one user" restrictions and/or the necessity to have a modifiable tree. >If it's just the question of a box to work on. A machine is the least of my problems... I have plenty of compute power and disk space. Remember that one of my "goals" is to avoid messing with the host's environment. At the moment I can accomplish all of this except for the .mk files. >There's no question that we could all benefit significantly from a >cleaner environment, we just have to see it before we're going to >"buy" it! You're otherwise asking us to accept major upheaval >sight-unseen! :-) No, I don't feel that to be the case. As you noted, I've not said much about the details because 1) I was working on those details to make sure that they would work, and 2) I wasn't getting much feedback. This post was intended to either get a commitment to the IDEA and GOALS or prove that I have been wasting my time on something that would never be accepted. You will notice that my proposal is to first gain a consensus and then to intruduce the changes in stages. The way I have worked it out, I can make a few trivial changes that "permit the new syntax" without actually changing anything. Then when the makefiles are ready, a new set of .mk files implements the real changes in the tree structure. Then we go back and clean out all the wasteful parts of the build process. I quote from my previous post: =============== PROPOSED PLAN OF ATTACK For this to happen, I will require the cooperation of ALL comitters. We will need a "standard" for "conforming" Makefiles. Once it is determined, anyone who changes a Makefile would make the alterations to meet the specification. In order to implement this, I propose 1) By Thursday, I will distribute a proposed "standard" for the make files. 2) By Monday, we will agree to the standard. 3) I'll make changes to the .mk files to make them accept both the present Makefiles as well as those that conform to the new standard. 4) Over some period (depending on complexity/manpower) we convert ALL Makefiles to the new standard. 5) I then commit new .mk files which implement the new structure. ================= ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Tue Apr 4 22:34:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03759 for current-outgoing; Tue, 4 Apr 1995 22:34:51 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03753 for ; Tue, 4 Apr 1995 22:34:47 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id XAA09555; Tue, 4 Apr 1995 23:38:29 -0600 Date: Tue, 4 Apr 1995 23:38:29 -0600 Message-Id: <199504050538.XAA09555@trout.sri.MT.net> To: rkw@dataplex.net (Richard Wackerbarth) Cc: "Jordan K. Hubbard" , current@FreeBSD.org Subject: Re: NOTICE: If you care, speak now! In-Reply-To: References: Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Richard Wackerbarth writes: > >If you're really serious about this, then before you commit *anything* ^^^^^^^^^^^^^^^^^ > >you need to bring it up on a machine completely and totally so that > >others can run test builds with it and make comments. I'm sorry, but > >until I actually *KNOW* and can *SEE* your changes doing everything > >they're supposed to do on a real live box then I can't support them > >and I doubt that many others will step forward and do so either. > In order to implement this, I propose > 1) By Thursday, I will distribute a proposed "standard" for the make files. > 2) By Monday, we will agree to the standard. > 3) I'll make changes to the .mk files to make them accept both the present > Makefiles as well as those that conform to the new standard. Before we agree to something, we need to *see* it in action. That means we need to see a prototype before we can accept it as a standard. Then, after a period of time which includes people beating on it and Jordan agrees it's a 'Good thing' it will be agreed, and step 3 can occur. No offense, but it's really easy to find a solution that doesn't 'quite' work. The direction it heads is better, but if it doesn't do everything it needs to do it's not a complete solution. Show it off on thud first, and then we can see the wonderfulness of your solution. :-) Nate From owner-freebsd-current Tue Apr 4 23:00:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA04085 for current-outgoing; Tue, 4 Apr 1995 23:00:07 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA04079 for ; Tue, 4 Apr 1995 23:00:06 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id WAA21421 for ; Tue, 4 Apr 1995 22:57:05 -0700 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id HAA26095; Wed, 5 Apr 1995 07:52:30 +0200 Message-Id: <199504050552.HAA26095@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: Mark Murray , current@FreeBSD.org Subject: Re: UNION File System... Date: Wed, 05 Apr 1995 07:52:29 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk > >What is the current state of usefulness of UFS? > > It's completely broken. Thanks. Damn. Anyone working on it? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Tue Apr 4 23:03:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA04188 for current-outgoing; Tue, 4 Apr 1995 23:03:39 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA04181 for ; Tue, 4 Apr 1995 23:03:37 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA27763; Tue, 4 Apr 95 23:56:26 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504050556.AA27763@cs.weber.edu> Subject: Re: NOTICE: If you care, speak now! To: nate@sneezy.sri.com Date: Tue, 4 Apr 95 23:56:26 MDT Cc: rkw@dataplex.net, phk@ref.tfs.com, current@FreeBSD.org In-Reply-To: <199504050407.WAA09298@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 10:07:41 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > 3) This is no more of a change than the changes to "install" that are being > > so widely advocated. > > Huh? The install change affects *one* utility, but the changes you are > advocating effect the entire build process, and from the sounds of it > every Makefile. And, as a rebuttal, even though the install changes are > to one tool, because of the significance of the tool those changes might > not make it into the release. Oh, ho, he's got you, Nate! That one utility is used to install all the binaries on the system. 8-). What Richard say he wants to change will affect how you build every binary on the system (he's already said it's mostly .mk files). I'm with Jordan on this one (but you should still add -p to install for suid programs and header file "builds" no matte what happens). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Apr 4 23:04:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA04216 for current-outgoing; Tue, 4 Apr 1995 23:04:54 -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 XAA04209 for ; Tue, 4 Apr 1995 23:04:52 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id XAA07984; Tue, 4 Apr 1995 23:04:25 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id XAA00134; Tue, 4 Apr 1995 23:04:24 -0700 Message-Id: <199504050604.XAA00134@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: Mark Murray cc: current@FreeBSD.org Subject: Re: UNION File System... In-reply-to: Your message of "Wed, 05 Apr 95 07:52:29 +0200." <199504050552.HAA26095@grunt.grondar.za> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 04 Apr 1995 23:04:24 -0700 Sender: current-owner@FreeBSD.org Precedence: bulk >> >What is the current state of usefulness of UFS? >> >> It's completely broken. > >Thanks. Damn. Anyone working on it? The author and others. I can't give any assurances that it will be working in 2.1R; it's not a requirement for the release. -DG From owner-freebsd-current Tue Apr 4 23:17:24 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA04446 for current-outgoing; Tue, 4 Apr 1995 23:17:24 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA04440 for ; Tue, 4 Apr 1995 23:17:23 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA27830; Wed, 5 Apr 95 00:10:57 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504050610.AA27830@cs.weber.edu> Subject: Re: NOTICE: If you care, speak now! To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 5 Apr 95 0:10:56 MDT Cc: jkh@freefall.cdrom.com, current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net In-Reply-To: from "Richard Wackerbarth" at Apr 5, 95 00:22:03 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > I have no problem with your reluctance to "accept" something "sight unseen". > I do have a problem with trying to do something with virtually no feedback > from the intended "users". If you will read my proposals, I am asking for > an agreement that the group will support a change toward the goals that I > have stated. If that is achieved, I then ask for acceptance of a specific > methodology. I would expect the actual changes to be accepted only after > others have adequately reviewed the work. I think you will find that *nobody* is against this proposal. There is a general consensus that we need to build from a CDROM, that we need to make it rebuild as little as possible, and that we would like to have a cross-compilation environment if we can get one to make it easier to roll in support for other architectures. I think that everyone is so vehemently for something like this that we all have rather stong opinions on "the right way to do it" (as evidenced by the recent "install" 'hoo-raw'). So it's more like "proposal is obvious; what have you got to demo?". The most formal any architectural committee gets is the comittee of two on the VM system -- they have the rest of us beat hands down. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Apr 4 23:58:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA06676 for current-outgoing; Tue, 4 Apr 1995 23:58:31 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA06667; Tue, 4 Apr 1995 23:58:29 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: rkw@dataplex.net (Richard Wackerbarth) cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.mt.net Subject: Re: NOTICE: If you care, speak now! In-reply-to: Your message of "Wed, 05 Apr 95 00:22:03 CDT." Date: Tue, 04 Apr 1995 23:58:29 -0700 Message-ID: <6663.797065109@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I have no problem with your reluctance to "accept" something "sight unseen". > I do have a problem with trying to do something with virtually no feedback > from the intended "users". If you will read my proposals, I am asking for > an agreement that the group will support a change toward the goals that I > have stated. If that is achieved, I then ask for acceptance of a specific > methodology. I would expect the actual changes to be accepted only after > others have adequately reviewed the work. Hmmmmm. I begin to see the problem. I'll put it as directly as I can: We don't work that way. That's not to say that we don't work that way in other situations, or that some of us wouldn't be perfectly happy to see a FreeBSD organization so complete and dedicated to that kind of focused "discuss-design-discuss-develop" R&D strategy that such things were possible. But many months of learning, often the hard way, that free software development moves my somewhat different rules has made us wary. So many people have yelled "fire!" in the crowded theatre that nobody wants to really leave their seats until they're SURE there's a fire. There's also the small problem of TIME. There is never enough of it, and even sending email in these kinds of exchanges takes up oh so much of it! We're not all blessed with the kind of surplus time required to truly go through the full process you describe, no matter how much sense it might make. You can forget it! Nobody is going to agree unanimously, nobody is going to agree to put much time into it when they've already got massively full plates, nobody is even going to WANT to read long missives about boring makefile variables and obscure architectural decisions. I may pretend an occasional interest myself, but it will be a transparent sham that fools no one - I will be clearly busy working on OTHER things. So what's a poor boy to do, you ask? Just Do It, as they say in the Addidas commercials. Go off and do what you think is right then present it for inspection, fully (or close to fully) working and let its users decide to champion it or not. If you've truly done good stuff, then everyone will drown out the detractors FOR YOU in their hoots of admiration and delight and your changes will make it into the tree, complete with marching bad and occasional messages saying "Cool!" plopping into your mailbox. Try and hash it out in painful and contentious detail first and you'll only scuttle your project before getting it out of the dock. People influence by DOING around here, not by talking. And so on that note, I'll shut up and actually try to do some bl**dy WORK done this week! It's been an Email Picnic In Hell!! :-) Jordan From owner-freebsd-current Wed Apr 5 00:22:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA09183 for current-outgoing; Wed, 5 Apr 1995 00:22:56 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA09174; Wed, 5 Apr 1995 00:22:55 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: rkw@dataplex.net (Richard Wackerbarth), current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.mt.net Subject: Re: NOTICE: If you care, speak now! In-reply-to: Your message of "Tue, 04 Apr 95 23:58:29 PDT." <6663.797065109@freefall.cdrom.com> Date: Wed, 05 Apr 1995 00:22:55 -0700 Message-ID: <9173.797066575@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk [from my own posting] > the detractors FOR YOU in their hoots of admiration and delight and > your changes will make it into the tree, complete with marching bad ^^^ I really must learn to proof-read my postings.. Then again, perhaps my small slip is rather more descriptive of most marching bands! :-) Jordan From owner-freebsd-current Wed Apr 5 01:34:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA11415 for current-outgoing; Wed, 5 Apr 1995 01:34:33 -0700 Received: from mpp.com (dialup-3-178.gw.umn.edu [134.84.101.178]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA11406 for ; Wed, 5 Apr 1995 01:34:26 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id DAA03477; Wed, 5 Apr 1995 03:27:19 -0500 From: Mike Pritchard Message-Id: <199504050827.DAA03477@mpp.com> Subject: Re: NOTICE: If you care, speak now! To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 5 Apr 1995 03:27:18 -0500 (CDT) Cc: current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Apr 4, 95 09:23:21 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: 3941 Sender: current-owner@FreeBSD.org Precedence: bulk > I WANT to make a significant change to the way new systems get built. > ... > 1) The environment of the host system is NOT disturbed by the "making" of a > new release. > 2) The source and object files MAY be shared by multiple releases without > impacting each other. > 3) The tree MAY be on read-only media. If you wish to change only a part of > the tree, only the affected parts need be on writeable media. > 4) Redundant compiles are eliminated. "make all" folled by a second "make > all" will not cause anything to be recompiled. (The compressed man pages > are another, but related, issue) > > The "downside": > > 1) To build a new kernel, etc. you must place it in a proper "tree" > structure. That tree can be rooted anywhere you wish. ( This could be > handled by a script or possibly special "make" targets.) > 2) Unless you are in a "proper" tree, you must either do a make from the > root of the tree OR predefine the TREE environmental variable. > > An "aside": > ... > "Obj" links could optionally be added and would work IF you have only one > version of the tree. They would be "for reference only" and not used to > build the system. > Richard Wackerbarth There may be a way to do what I am asking below right now, but I haven' t really seen a way to do this, so forgive me if I'm wrong (and tell me how to do it if it can be done!). Right now I don't really see a way to do any type of kernel development without actually changing the sources out in /usr/src/sys, unless I want to copy /usr/src/sys off somewhere else and work on those sources. That is kinda a pain if I really only want to work on one particular module, and would like the rest of the kernel to be up-to-date (I run sup daily) while I'm working on my change (and if other changes get added to my module while I'm working on it, I'm responsible for reconciling those differences). For non-kernel sources (/usr/src/{bin,usr.bin,sbin,...} you can usually just copy the directory containing the program in question off somewhere and work on it and this usually only involves a very small number or a handful of files at most. The kernel is 1,400+ files. On other systems I've worked on I was able to do something like this: # SETENV SRCROOT /usr/src # cd /usr/src/mpp/sys # mkdir -p compile/mpp # [do the right stuff to get a Makefile & whatever else in /usr/src/mpp/compile/mpp that I need. E.g. all the "config" stuff] # cd compile/mpp # pwd /usr/src/mpp/sys/compile/mpp # vi ../../kern/kern_proc.c [make my changes to my copy of kern_proc.c] # make [this would do a make, picking up my ../../kern/kern_proc.c over the /usr/src/sys/kern/kern_proc.c, and any files not found in ../.. (/usr/src/mpp) would be picked up from $SRCROOT, or /usr/src/sys] Something that allowed me to do what I mentioned above would also let me compile off a CD-ROM, if I pointed SRCROOT to the directory on the CD-ROM that contained my sources and if copied off the appropriate makefile and whatever other support files I needed. It doesn't look too hard to do to the current kernel makefile, and it looks similar to part of what Richard is proposing above. About 5 minutes of hacking tells me that it is possible, but it looks like it will take a bit of work to get it all working correctly. It would also be nice to be able to do this with every system makefile (e.g. just copy /usr/src/Makefile somewhere, cd there, set SRCROOT to /usr/src and then type make and everything would work), thus eliminating the need for the "make obj" stuff, but would require hacking a lot of makefiles. I would settle for the kernel for now. For most programs, something as simple as the following in the makefile might just do the trick: .PATH: ../../usr.bin/progname ${SRCROOT}/usr.bin/progname (modify the above to fit the appropriate command) -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-current Wed Apr 5 02:16:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA12980 for current-outgoing; Wed, 5 Apr 1995 02:16:21 -0700 Received: from vinkku.hut.fi (vode@vinkku.hut.fi [130.233.245.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA12973 for ; Wed, 5 Apr 1995 02:16:00 -0700 Received: (from vode@localhost) by vinkku.hut.fi (8.6.11/8.6.7) id MAA10911; Wed, 5 Apr 1995 12:15:45 +0300 Date: Wed, 5 Apr 1995 12:15:45 +0300 From: Kai Vorma Message-Id: <199504050915.MAA10911@vinkku.hut.fi> To: current@FreeBSD.org Subject: patch for sup Reply-to: Kai.Vorma@hut.fi Sender: current-owner@FreeBSD.org Precedence: bulk Here is a simple patch for sup that makes it possible to have local modifications in your source tree so that sup won't overwrite them. The idea is simple (stolen from this mailing-list, I think :) If sup is updating file foo.c and there exists file foo.c#sup it will update the latter file an leave the former untouched. This patch should work with regular files and perhaps with links but you _cannot_ create shadow directory #foo. I have not tested this too much (I did it yesterday evening) but I has worked so far just fine :-) Btw, why is freefall's supserver so abysmally slow? Is it because supservers uses fork() like almost all badly designed network servers or something else? If the problem is not fork() then I'll try to see if I can make it faster. ..vode PS. This patch is agains sup.tar.gz from ports-collection. --------------------------------------------------------------------------- *** supcmeat.c.ORIG Thu Aug 11 16:24:45 1994 --- supcmeat.c Wed Apr 5 10:11:15 1995 *************** *** 27,32 **** --- 27,35 ---- ********************************************************************** * HISTORY * + * 5-Apr-95 Kai Vorma + * Update regular file foo.c#sup, if exists, instead of foo.c + * * 7-July-93 Nate Williams at Montana State University * Modified SUP to use gzip based compression when sending files * across the network to save BandWidth *************** *** 151,156 **** --- 154,163 ---- #include #endif + #define tstat(p,b) tdostat(0,p,b) + #define tlstat(p,b) tdostat(1,p,b) + char rname[1024]; + TREE *lastT; /* last filenames in collection */ jmp_buf sjbuf; /* jump location for network errors */ int dontjump; /* flag to void sjbuf */ *************** *** 564,572 **** if ((t->Tflags&FNEW) == 0 && (thisC->Cflags&CFOLD) == 0) return (SCMOK); if ((t->Tmode&S_IFMT) == S_IFLNK) ! exists = (lstat (t->Tname,&sbuf) == 0); else ! exists = (stat (t->Tname,&sbuf) == 0); /* This is moderately complicated: If the file is the wrong type or doesn't exist, we need to fetch the whole file. If the file is a special file, we --- 571,579 ---- if ((t->Tflags&FNEW) == 0 && (thisC->Cflags&CFOLD) == 0) return (SCMOK); if ((t->Tmode&S_IFMT) == S_IFLNK) ! exists = (tlstat (t->Tname,&sbuf) == 0); else ! exists = (tstat (t->Tname,&sbuf) == 0); /* This is moderately complicated: If the file is the wrong type or doesn't exist, we need to fetch the whole file. If the file is a special file, we *************** *** 594,600 **** /* If we get this far, we're either doing an update or a full fetch. */ if (!fetch && t->Tmode == sbuf.st_mode && (t->Tmode&S_IFMT) == S_IFREG && (thisC->Cflags&CFNOUPDATE)) { ! vnotify ("SUP update avoided for %s\n", t->Tname); return (SCMOK); } newt = Tinsert (&needT,t->Tname,TRUE); --- 601,607 ---- /* If we get this far, we're either doing an update or a full fetch. */ if (!fetch && t->Tmode == sbuf.st_mode && (t->Tmode&S_IFMT) == S_IFREG && (thisC->Cflags&CFNOUPDATE)) { ! vnotify ("SUP update avoided for %s\n", rname); return (SCMOK); } newt = Tinsert (&needT,t->Tname,TRUE); *************** *** 619,650 **** if (t->Tflags&FUPDATE) /* in current upgrade list */ return (SCMOK); ! if (lstat(name,&sbuf) < 0) /* doesn't exist */ return (SCMOK); /* is it a symbolic link ? */ if ((sbuf.st_mode & S_IFMT) == S_IFLNK) { if (Tlookup (refuseT,name)) { vnotify ("SUP Would not delete symbolic link %s\n", ! name); return (SCMOK); } if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would delete symbolic link %s\n",name); return (SCMOK); } if ((thisC->Cflags&CFDELETE) == 0) { ! notify ("SUP Please delete symbolic link %s\n",name); t->Tflags |= FUPDATE; return (SCMOK); } ! x = unlink (name); if (x < 0) { notify ("SUP: Unable to delete symbolic link %s\n", ! name); t->Tflags |= FUPDATE; return (SCMOK); } ! vnotify ("SUP Deleted symbolic link %s\n",name); return (SCMOK); } /* is it a directory ? */ --- 626,657 ---- if (t->Tflags&FUPDATE) /* in current upgrade list */ return (SCMOK); ! if (tlstat(name,&sbuf) < 0) /* doesn't exist */ return (SCMOK); /* is it a symbolic link ? */ if ((sbuf.st_mode & S_IFMT) == S_IFLNK) { if (Tlookup (refuseT,name)) { vnotify ("SUP Would not delete symbolic link %s\n", ! rname); return (SCMOK); } if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would delete symbolic link %s\n",rname); return (SCMOK); } if ((thisC->Cflags&CFDELETE) == 0) { ! notify ("SUP Please delete symbolic link %s\n",rname); t->Tflags |= FUPDATE; return (SCMOK); } ! x = unlink (rname); if (x < 0) { notify ("SUP: Unable to delete symbolic link %s\n", ! rname); t->Tflags |= FUPDATE; return (SCMOK); } ! vnotify ("SUP Deleted symbolic link %s\n",rname); return (SCMOK); } /* is it a directory ? */ *************** *** 673,697 **** } /* it is a file */ if (Tlookup (refuseT,name)) { ! vnotify ("SUP Would not delete file %s\n",name); return (SCMOK); } if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would delete file %s\n",name); return (SCMOK); } if ((thisC->Cflags&CFDELETE) == 0) { ! notify ("SUP Please delete file %s\n",name); t->Tflags |= FUPDATE; return (SCMOK); } ! x = unlink (name); if (x < 0) { ! notify ("SUP: Unable to delete file %s\n",name); t->Tflags |= FUPDATE; return (SCMOK); } ! vnotify ("SUP Deleted file %s\n",name); return (SCMOK); } --- 680,704 ---- } /* it is a file */ if (Tlookup (refuseT,name)) { ! vnotify ("SUP Would not delete file %s\n",rname); return (SCMOK); } if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would delete file %s\n",rname); return (SCMOK); } if ((thisC->Cflags&CFDELETE) == 0) { ! notify ("SUP Please delete file %s\n",rname); t->Tflags |= FUPDATE; return (SCMOK); } ! x = unlink (rname); if (x < 0) { ! notify ("SUP: Unable to delete file %s\n",rname); t->Tflags |= FUPDATE; return (SCMOK); } ! vnotify ("SUP Deleted file %s\n",rname); return (SCMOK); } *************** *** 746,754 **** register char *type; if (mode == S_IFLNK) ! *newp = (lstat (name,statp) < 0); else ! *newp = (stat (name,statp) < 0); if (*newp) { if (thisC->Cflags&CFLIST) return (FALSE); --- 753,761 ---- register char *type; if (mode == S_IFLNK) ! *newp = (tlstat (name,statp) < 0); else ! *newp = (tstat (name,statp) < 0); if (*newp) { if (thisC->Cflags&CFLIST) return (FALSE); *************** *** 774,792 **** break; } if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would remove %s %s\n",type,name); return (FALSE); } if ((statp->st_mode&S_IFMT) == S_IFDIR) { if (rmdir (name) < 0) runp ("rm","rm","-rf",name,0); } else ! (void) unlink (name); ! if (stat (name,statp) < 0) { ! vnotify ("SUP Removed %s %s\n",type,name); return (FALSE); } ! notify ("SUP: Couldn't remove %s %s\n",type,name); return (TRUE); } --- 781,799 ---- break; } if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would remove %s %s\n",type,rname); return (FALSE); } if ((statp->st_mode&S_IFMT) == S_IFDIR) { if (rmdir (name) < 0) runp ("rm","rm","-rf",name,0); } else ! (void) unlink (rname); ! if (stat (rname,statp) < 0) { ! vnotify ("SUP Removed %s %s\n",type,rname); return (FALSE); } ! notify ("SUP: Couldn't remove %s %s\n",type,rname); return (TRUE); } *************** *** 813,819 **** return (SCMOK); } if (prepare (t->Tname,t->Tmode&S_IFMT,&new,&sbuf)) { ! notify ("SUP: Can't prepare path for %s\n",t->Tname); if ((t->Tmode&S_IFMT) == S_IFREG) { x = readskip (); /* skip over file */ if (x != SCMOK) --- 820,826 ---- return (SCMOK); } if (prepare (t->Tname,t->Tmode&S_IFMT,&new,&sbuf)) { ! notify ("SUP: Can't prepare path for %s\n",rname); if ((t->Tmode&S_IFMT) == S_IFREG) { x = readskip (); /* skip over file */ if (x != SCMOK) *************** *** 905,925 **** } linkname = t->Tlink->Tname; if (!new && (t->Tflags&FNEW) == 0 && ! (n = readlink (t->Tname,buf,sizeof(buf))) >= 0 && (n == strlen (linkname)) && (strncmp (linkname,buf,n) == 0)) return (FALSE); if (thisC->Cflags&CFLIST) { vnotify ("SUP Would %s symbolic link %s to %s\n", ! new?"create":"update",t->Tname,linkname); return (FALSE); } if (!new) ! (void) unlink (t->Tname); ! if (symlink (linkname,t->Tname) < 0 || lstat(t->Tname,statp) < 0) { ! notify ("SUP: Unable to create symbolic link %s\n",t->Tname); return (TRUE); } ! vnotify ("SUP Created symbolic link %s to %s\n",t->Tname,linkname); return (FALSE); } --- 912,932 ---- } linkname = t->Tlink->Tname; if (!new && (t->Tflags&FNEW) == 0 && ! (n = readlink (rname,buf,sizeof(buf))) >= 0 && (n == strlen (linkname)) && (strncmp (linkname,buf,n) == 0)) return (FALSE); if (thisC->Cflags&CFLIST) { vnotify ("SUP Would %s symbolic link %s to %s\n", ! new?"create":"update",rname,linkname); return (FALSE); } if (!new) ! (void) unlink (rname); ! if (symlink (linkname,rname) < 0 || lstat(rname,statp) < 0) { ! notify ("SUP: Unable to create symbolic link %s\n",rname); return (TRUE); } ! vnotify ("SUP Created symbolic link %s to %s\n",rname,linkname); return (FALSE); } *************** *** 950,966 **** return (FALSE); } if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would update file %s\n",t->Tname); return (FALSE); } ! vnotify ("SUP Updating file %s\n",t->Tname); if ((t->Tflags&FNOACCT) == 0) { ! (void) chown (t->Tname,t->Tuid,t->Tgid); ! (void) chmod (t->Tname,t->Tmode&S_IMODE); } tbuf[0].tv_sec = time((long *)NULL); tbuf[0].tv_usec = 0; tbuf[1].tv_sec = t->Tmtime; tbuf[1].tv_usec = 0; ! (void) utimes (t->Tname,tbuf); return (FALSE); } if (thisC->Cflags&CFLIST) { --- 957,973 ---- return (FALSE); } if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would update file %s\n",rname); return (FALSE); } ! vnotify ("SUP Updating file %s\n",rname); if ((t->Tflags&FNOACCT) == 0) { ! (void) chown (rname,t->Tuid,t->Tgid); ! (void) chmod (rname,t->Tmode&S_IMODE); } tbuf[0].tv_sec = time((long *)NULL); tbuf[0].tv_usec = 0; tbuf[1].tv_sec = t->Tmtime; tbuf[1].tv_usec = 0; ! (void) utimes (rname,tbuf); return (FALSE); } if (thisC->Cflags&CFLIST) { *************** *** 972,993 **** p = "receive old"; else p = "receive"; ! vnotify ("SUP Would %s file %s\n",p,t->Tname); return (FALSE); } ! vnotify ("SUP Receiving file %s\n",t->Tname); if (!new && (t->Tmode&S_IFMT) == S_IFREG && (t->Tflags&FBACKUP) && (thisC->Cflags&CFBACKUP)) { ! fin = fopen (t->Tname,"r"); /* create backup */ if (fin == NULL) { x = readskip (); /* skip over file */ if (x != SCMOK) goaway ("Can't skip file transfer"); notify ("SUP: Can't open %s to create backup\n", ! t->Tname); return (TRUE); /* mark upgrade as nogood */ } ! path (t->Tname,dirpart,filepart); (void) sprintf (filename,FILEBACKUP,dirpart,filepart); fout = fopen (filename,"w"); if (fout == NULL) { --- 979,1000 ---- p = "receive old"; else p = "receive"; ! vnotify ("SUP Would %s file %s\n",p,rname); return (FALSE); } ! vnotify ("SUP Receiving file %s\n",rname); if (!new && (t->Tmode&S_IFMT) == S_IFREG && (t->Tflags&FBACKUP) && (thisC->Cflags&CFBACKUP)) { ! fin = fopen (rname,"r"); /* create backup */ if (fin == NULL) { x = readskip (); /* skip over file */ if (x != SCMOK) goaway ("Can't skip file transfer"); notify ("SUP: Can't open %s to create backup\n", ! rname); return (TRUE); /* mark upgrade as nogood */ } ! path (rname,dirpart,filepart); (void) sprintf (filename,FILEBACKUP,dirpart,filepart); fout = fopen (filename,"w"); if (fout == NULL) { *************** *** 1006,1025 **** ffilecopy (fin,fout); (void) fclose (fin); (void) fclose (fout); ! vnotify ("SUP Backup of %s created\n", t->Tname); } ! x = copyfile (t->Tname,(char *)NULL); if (x) return (TRUE); if ((t->Tflags&FNOACCT) == 0) { /* convert user and group names to local ids */ ugconvert (t->Tuser,t->Tgroup,&t->Tuid,&t->Tgid,&t->Tmode); ! (void) chown (t->Tname,t->Tuid,t->Tgid); ! (void) chmod (t->Tname,t->Tmode&S_IMODE); } tbuf[0].tv_sec = time((long *)NULL); tbuf[0].tv_usec = 0; tbuf[1].tv_sec = t->Tmtime; tbuf[1].tv_usec = 0; ! (void) utimes (t->Tname,tbuf); return (FALSE); } --- 1013,1032 ---- ffilecopy (fin,fout); (void) fclose (fin); (void) fclose (fout); ! vnotify ("SUP Backup of %s created\n", rname); } ! x = copyfile (rname,(char *)NULL); if (x) return (TRUE); if ((t->Tflags&FNOACCT) == 0) { /* convert user and group names to local ids */ ugconvert (t->Tuser,t->Tgroup,&t->Tuid,&t->Tgid,&t->Tmode); ! (void) chown (rname,t->Tuid,t->Tgid); ! (void) chmod (rname,t->Tmode&S_IMODE); } tbuf[0].tv_sec = time((long *)NULL); tbuf[0].tv_usec = 0; tbuf[1].tv_sec = t->Tmtime; tbuf[1].tv_usec = 0; ! (void) utimes (rname,tbuf); return (FALSE); } *************** *** 1031,1038 **** register char *name = t->Tname; int new,x; char *type; ! if (stat(*fname,&fbuf) < 0) { /* source file */ if (thisC->Cflags&CFLIST) { vnotify ("SUP Would link %s to %s\n",name,*fname); return (SCMOK); --- 1038,1046 ---- register char *name = t->Tname; int new,x; char *type; + char rfname[1024]; /* Kludge alert.. */ ! if (tstat(*fname,&fbuf) < 0) { /* source file */ if (thisC->Cflags&CFLIST) { vnotify ("SUP Would link %s to %s\n",name,*fname); return (SCMOK); *************** *** 1041,1048 **** thisC->Cnogood = TRUE; return (SCMOK); } if (prepare (name,S_IFREG,&new,&sbuf)) { ! notify ("SUP: Can't prepare path for link %s\n",name); thisC->Cnogood = TRUE; return (SCMOK); } --- 1049,1057 ---- thisC->Cnogood = TRUE; return (SCMOK); } + strcpy(rfname,rname); if (prepare (name,S_IFREG,&new,&sbuf)) { ! notify ("SUP: Can't prepare path for link %s\n",rname); thisC->Cnogood = TRUE; return (SCMOK); } *************** *** 1050,1069 **** fbuf.st_dev == sbuf.st_dev && fbuf.st_ino == sbuf.st_ino) return (SCMOK); if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would link %s to %s\n",name,*fname); return (SCMOK); } ! (void) unlink (name); type = ""; ! if ((x = link (*fname,name)) < 0) { type = "symbolic "; ! x = symlink (*fname,name); } ! if (x < 0 || lstat(name,&sbuf) < 0) { ! notify ("SUP: Unable to create %slink %s\n",type,name); return (TRUE); } ! vnotify ("SUP Created %slink %s to %s\n",type,name,*fname); return (SCMOK); } --- 1059,1078 ---- fbuf.st_dev == sbuf.st_dev && fbuf.st_ino == sbuf.st_ino) return (SCMOK); if (thisC->Cflags&CFLIST) { ! vnotify ("SUP Would link %s to %s\n",rname,rfname); return (SCMOK); } ! (void) unlink (rname); type = ""; ! if ((x = link (rfname,rname)) < 0) { type = "symbolic "; ! x = symlink (rfname,rname); } ! if (x < 0 || lstat(rname,&sbuf) < 0) { ! notify ("SUP: Unable to create %slink %s\n",type,rname); return (TRUE); } ! vnotify ("SUP Created %slink %s to %s\n",type,rname,rfname); return (SCMOK); } *************** *** 1481,1483 **** --- 1490,1518 ---- if (!dontjump) longjmp (sjbuf,TRUE); } + + + char *SUFFIX = "#sup"; + + int tdostat(ls, path, sbuf) + int ls; + char *path; + struct stat *sbuf; + { + int x, l = strlen(path); + + strcpy(rname, path); + if (l + strlen(SUFFIX) < sizeof(rname)) { + strcat(rname, SUFFIX); + if ((x = ls ? lstat(rname, sbuf): stat(rname, sbuf)) != -1) { + if (sbuf->st_mode&S_IFMT == S_IFDIR) + goaway("%s must not be a directory", rname); + return x; + } + if (errno != ENOENT) + goaway ("%sstat for %s failed (%d)", ls ? "tl" : "t", rname, errno); + rname[l] = '\0'; + } + return (ls ? lstat(rname, sbuf) : stat(rname, sbuf)); + } + From owner-freebsd-current Wed Apr 5 03:14:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA14352 for current-outgoing; Wed, 5 Apr 1995 03:14:43 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA14346 for ; Wed, 5 Apr 1995 03:14:36 -0700 Received: (dufault@localhost) by hda.com (8.6.9/8.3) id GAA03887; Wed, 5 Apr 1995 06:14:11 -0400 From: Peter Dufault Message-Id: <199504051014.GAA03887@hda.com> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: terry@cs.weber.edu (Terry Lambert) Date: Wed, 5 Apr 1995 06:14:11 -0400 (EDT) Cc: nate@trout.sri.MT.net, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <9504042045.AA18525@cs.weber.edu> from "Terry Lambert" at Apr 4, 95 02:45:55 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2588 Sender: current-owner@FreeBSD.org Precedence: bulk Terry Lambert writes: > > > *BLECH* BSD systems have *never* (and should *never*) require that you > > have the complete source tree installed just to build a kernel. Making > > them go through alot of trouble to build a kernel is a waste of their > > time. Many, many more people build kernels w/out src trees than people > > who build kernels w/src trees. We are trying to make the system > > *easier* to use for the avg. user w/out penalizing the developer. > > I'm glad you said this. > > When will the binary link kit be available? > > I've often thought that it should be possible to configure devices > in and out of the kernel without regenerating more than a single > object file containing the device switches. Wait a minute, who was that Terry Lambert giving me such grief about this last week? I thought we had to redesign the configuration, power management, and make the kernel multithreaded (no, that last one was a different issuse, never mind) at the same time. At the moment you can almost do this for isa drivers except for the assignment of interrupts in isa/isa.c. I just steal unused interrupts to get around the problem. > > The really nice thing about this, of course, is that multiport > board drivers and Adaptec drivers using Adaptec code, and (potentially) > the Intel supplied-for-MACH binary math coprocesser emulator could > all be supplied without sources in full conformance to the non > disclosure agreements required to obtain them. I agree with this completely. Fundamental changes to company policy on intellectual property are best left to the Linux camp. > > To make the nay-sayers happy, putting the source in escrow with the > condition that a non-disclosure be signed to obtain it should be > sufficient to not vest too much in a driver writer as a single point > of failure. I don't know about this. You'll have to be very careful about who these sources go to. One slip and FreeBSD has a black eye and a lawsuit. > That's just a legal niceity, however, and the main point, that it be > *possible*, is the important thing. > > Actually, sufficient reliance on a devfs, loadable modules, and > soft autoconfiguration with a "save" for "/kernel -c" boot should > make it totally unnecessary to have a link kit to get a new kernel > configuration anyway. Yes, this is a good design rule and with a little attention to detail it won't even be much work. -- 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 Wed Apr 5 03:35:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA15083 for current-outgoing; Wed, 5 Apr 1995 03:35:25 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id DAA15077 for ; Wed, 5 Apr 1995 03:35:23 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: current@freefall.cdrom.com Subject: "Cookbook" for security. Date: Wed, 05 Apr 1995 03:35:23 -0700 Message-ID: <15076.797078123@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk Poul and I were talking about the whole immutable flag issue, and since cpio, tar, pax and friends don't support the notion of extracting these extra flags ANYWAY, we might as well make a virtue of a vice and go "cookbook" style on it, where some central well-known file contains information that can be used to apply the flags in question after the system is installed. For that matter, the file can also contain MD5 checksums so that you can verify that all the "important" files have not been changed from the release copies. Needless to say, the "cookbook" file should be highly immutable itself in these cases :-). It seems to me that this would serve as a very valuable security aid and of use in creating the overall security tool from hell that I'd like to see on FreeBSD someday! :-) Jordan From owner-freebsd-current Wed Apr 5 05:04:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA18235 for current-outgoing; Wed, 5 Apr 1995 05:04:31 -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 FAA18228; Wed, 5 Apr 1995 05:04:15 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA18226; Wed, 5 Apr 1995 22:00:21 +1000 Date: Wed, 5 Apr 1995 22:00:21 +1000 From: Bruce Evans Message-Id: <199504051200.WAA18226@godzilla.zeta.org.au> To: current@freefall.cdrom.com, jkh@freefall.cdrom.com Subject: Re: "Cookbook" for security. Sender: current-owner@FreeBSD.org Precedence: bulk >Poul and I were talking about the whole immutable flag issue, and >since cpio, tar, pax and friends don't support the notion of >extracting these extra flags ANYWAY, we might as well make a virtue of >a vice and go "cookbook" style on it, where some central well-known >file contains information that can be used to apply the flags in >question after the system is installed. For that matter, the file can >also contain MD5 checksums so that you can verify that all the >"important" files have not been changed from the release copies. >Needless to say, the "cookbook" file should be highly immutable itself >in these cases :-). /etc/mtree/* is supposed to be used for this. Guess what other friend doesn't support chflags(). :-). Bruce From owner-freebsd-current Wed Apr 5 07:23:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA21343 for current-outgoing; Wed, 5 Apr 1995 07:23:34 -0700 Received: from isl.cf.ac.uk (isl-gate.elsy.cf.ac.uk [131.251.22.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA21335 for ; Wed, 5 Apr 1995 07:23:27 -0700 Received: (from paul@localhost) by isl.cf.ac.uk (8.6.9/8.6.9) id PAA04160; Wed, 5 Apr 1995 15:21:23 +0100 From: Paul Richards Message-Id: <199504051421.PAA04160@isl.cf.ac.uk> Subject: Re: Proper procedure to partition/label disk now? To: bob@obiwan.pmr.com (Bob Willcox) Date: Wed, 5 Apr 1995 15:21:22 +0100 (BST) Cc: bde@zeta.org.au, freebsd-current@freefall.cdrom.com In-Reply-To: from "Bob Willcox" at Apr 4, 95 09:57:46 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 801 Sender: current-owner@FreeBSD.org Precedence: bulk In reply to Bob Willcox who said > > I fear that they are going to be a concern to users as they convert > from 1.1.5 or 2.0 to 2.1. Lots of folks will think something is > broken when they see these messages. > Well, I mentioned this before and there was silence but I want to rewrite the MBR and bootblocks when 2.1 installs itself so we can fix all the bogus MBR's out there and also update the partition tables to the new standard. There's technically no reason why it can't be done but people do get very uptight when you mess with these things. -- Paul Richards, FreeBSD core team member. Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/ Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff. From owner-freebsd-current Wed Apr 5 07:48:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA22083 for current-outgoing; Wed, 5 Apr 1995 07:48:03 -0700 Received: from obiwan.pmr.com (obiwan.pmr.com [199.98.84.130]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA22077 for ; Wed, 5 Apr 1995 07:47:56 -0700 Received: by obiwan.pmr.com (Smail3.1.29.1 #4) id m0rwWNF-00030VC; Wed, 5 Apr 95 09:48 CDT Message-Id: From: bob@obiwan.pmr.com (Bob Willcox) Subject: Re: Proper procedure to partition/label disk now? To: paul@isl.cf.ac.uk (Paul Richards) Date: Wed, 5 Apr 1995 09:48:01 -0500 (CDT) Cc: bde@zeta.org.au, freebsd-current@freefall.cdrom.com In-Reply-To: <199504051421.PAA04160@isl.cf.ac.uk> from "Paul Richards" at Apr 5, 95 03:21:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 944 Sender: current-owner@FreeBSD.org Precedence: bulk Paul Richards wrote: > > In reply to Bob Willcox who said > > > > I fear that they are going to be a concern to users as they convert > > from 1.1.5 or 2.0 to 2.1. Lots of folks will think something is > > broken when they see these messages. > > > > Well, I mentioned this before and there was silence but I want to rewrite > the MBR and bootblocks when 2.1 installs itself so we can fix all the > bogus MBR's out there and also update the partition tables to the > new standard. I think thats a good idea! My 1.1.5.1 system has 14 disks on it and I don't look forward to the raft of error messages. :-( > > There's technically no reason why it can't be done but people do get very > uptight when you mess with these things. Yep. There is the risk that it may go awry in some environment and do damage, I suppose. But, I would still support doing it. -- Bob Willcox bob@obiwan.pmr.com (or obiwan%bob@uunet.uu.net) Austin, TX From owner-freebsd-current Wed Apr 5 08:00:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA22291 for current-outgoing; Wed, 5 Apr 1995 08:00:18 -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 HAA22278 for ; Wed, 5 Apr 1995 07:59:31 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA22629; Thu, 6 Apr 1995 00:52:39 +1000 Date: Thu, 6 Apr 1995 00:52:39 +1000 From: Bruce Evans Message-Id: <199504051452.AAA22629@godzilla.zeta.org.au> To: bob@obiwan.pmr.com, paul@isl.cf.ac.uk Subject: Re: Proper procedure to partition/label disk now? Cc: bde@zeta.org.au, freebsd-current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> I fear that they are going to be a concern to users as they convert >> from 1.1.5 or 2.0 to 2.1. Lots of folks will think something is >> broken when they see these messages. >> >Well, I mentioned this before and there was silence but I want to rewrite >the MBR and bootblocks when 2.1 installs itself so we can fix all the >bogus MBR's out there and also update the partition tables to the >new standard. >There's technically no reason why it can't be done but people do get very >uptight when you mess with these things. The problem is converting backwards (to 1.1.5...) and sideways (to NetBSD ...). Bruce From owner-freebsd-current Wed Apr 5 08:13:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA22598 for current-outgoing; Wed, 5 Apr 1995 08:13:45 -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 IAA22585 for ; Wed, 5 Apr 1995 08:13:40 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA25822; Wed, 5 Apr 1995 11:12:37 -0400 Date: Wed, 5 Apr 1995 11:12:37 -0400 From: Garrett Wollman Message-Id: <9504051512.AA25822@halloran-eldar.lcs.mit.edu> To: Bruce Evans Cc: current@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 In-Reply-To: <199504041121.VAA18870@godzilla.zeta.org.au> References: <199504041121.VAA18870@godzilla.zeta.org.au> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > What about a parallel object tree that is union mounted over the source? > Assume that union mounts have no bugs. I assume you mean `unionfs' (which should be called `translucentfs' but isn't); `union mount' means something different entirely. This might be workable, although I wouldn't want to depend on it seriously. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Apr 5 08:29:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA22747 for current-outgoing; Wed, 5 Apr 1995 08:29:04 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA22741 ; Wed, 5 Apr 1995 08:29:03 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id IAA08521; Wed, 5 Apr 1995 08:29:03 -0700 From: Poul-Henning Kamp Message-Id: <199504051529.IAA08521@ref.tfs.com> Subject: Re: "Cookbook" for security. To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 5 Apr 1995 08:29:02 -0700 (PDT) Cc: current@freefall.cdrom.com In-Reply-To: <15076.797078123@freefall.cdrom.com> from "Jordan K. Hubbard" at Apr 5, 95 03:35:23 am Content-Type: text Content-Length: 883 Sender: current-owner@FreeBSD.org Precedence: bulk > Poul and I were talking about the whole immutable flag issue, and > since cpio, tar, pax and friends don't support the notion of > extracting these extra flags ANYWAY, we might as well make a virtue of > a vice and go "cookbook" style on it, where some central well-known > file contains information that can be used to apply the flags in > question after the system is installed. For that matter, the file can > also contain MD5 checksums so that you can verify that all the > "important" files have not been changed from the release copies. > Needless to say, the "cookbook" file should be highly immutable itself > in these cases :-). living on a CD-ROM or write-protected floppy it will be... -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant' From owner-freebsd-current Wed Apr 5 08:34:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA22807 for current-outgoing; Wed, 5 Apr 1995 08:34:43 -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 IAA22801 for ; Wed, 5 Apr 1995 08:34:42 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA25847; Wed, 5 Apr 1995 11:34:38 -0400 Date: Wed, 5 Apr 1995 11:34:38 -0400 From: Garrett Wollman Message-Id: <9504051534.AA25847@halloran-eldar.lcs.mit.edu> To: terry@cs.weber.edu (Terry Lambert) Cc: current@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 In-Reply-To: <9504042045.AA18525@cs.weber.edu> References: <199504041758.LAA06600@trout.sri.MT.net> <9504042045.AA18525@cs.weber.edu> Sender: current-owner@FreeBSD.org Precedence: bulk < When will the binary link kit be available? When somebody cares enough to make one. (hint, hint.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Apr 5 08:36:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA22832 for current-outgoing; Wed, 5 Apr 1995 08:36: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 IAA22826 for ; Wed, 5 Apr 1995 08:36:27 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA25850; Wed, 5 Apr 1995 11:36:24 -0400 Date: Wed, 5 Apr 1995 11:36:24 -0400 From: Garrett Wollman Message-Id: <9504051536.AA25850@halloran-eldar.lcs.mit.edu> To: terry@cs.weber.edu (Terry Lambert) Cc: nate@trout.sri.MT.net (Nate Williams), rkw@dataplex.net, current@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 In-Reply-To: <9504042045.AA18525@cs.weber.edu> References: <199504041758.LAA06600@trout.sri.MT.net> <9504042045.AA18525@cs.weber.edu> Sender: current-owner@FreeBSD.org Precedence: bulk < When will the binary link kit be available? [and later:] > The really nice thing about this, of course, is that multiport > board drivers and Adaptec drivers using Adaptec code, and (potentially) > the Intel supplied-for-MACH binary math coprocesser emulator could > all be supplied without sources in full conformance to the non > disclosure agreements required to obtain them. These two are completely unrelated. You can do the second NOW if you want to; just add `foo.o' to files.i386. (If this breaks, it's a bug in config; you're supposed to be able to do this.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Apr 5 08:52:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA23063 for current-outgoing; Wed, 5 Apr 1995 08:52:33 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA23057 for ; Wed, 5 Apr 1995 08:52:30 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id JAA11044; Wed, 5 Apr 1995 09:54:29 -0600 Date: Wed, 5 Apr 1995 09:54:29 -0600 From: Nate Williams Message-Id: <199504051554.JAA11044@trout.sri.MT.net> In-Reply-To: Bruce Evans "Re: Proper procedure to partition/label disk now?" (Apr 6, 12:52am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Bruce Evans , bob@obiwan.pmr.com, paul@isl.cf.ac.uk Subject: Re: Proper procedure to partition/label disk now? Cc: freebsd-current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > >Well, I mentioned this before and there was silence but I want to rewrite > >the MBR and bootblocks when 2.1 installs itself so we can fix all the > >bogus MBR's out there and also update the partition tables to the > >new standard. > > >There's technically no reason why it can't be done but people do get very > >uptight when you mess with these things. > > The problem is converting backwards (to 1.1.5...) and sideways (to NetBSD > ...). Why do we want to do that? We never claimed we could move backwards to other OS's. Nate From owner-freebsd-current Wed Apr 5 09:15:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA23387 for current-outgoing; Wed, 5 Apr 1995 09:15:46 -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 JAA23381 for ; Wed, 5 Apr 1995 09:15:35 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA25909; Wed, 5 Apr 1995 12:12:43 -0400 Date: Wed, 5 Apr 1995 12:12:43 -0400 From: Garrett Wollman Message-Id: <9504051612.AA25909@halloran-eldar.lcs.mit.edu> To: Bruce Evans Cc: current@freefall.cdrom.com Subject: Re: "Cookbook" for security. In-Reply-To: <199504051200.WAA18226@godzilla.zeta.org.au> References: <199504051200.WAA18226@godzilla.zeta.org.au> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > /etc/mtree/* is supposed to be used for this. Guess what other friend > doesn't support chflags(). :-). Trivial to fix. No, I'm not going to do it, I already did the MD5 stuff! -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Apr 5 09:17:05 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA23395 for current-outgoing; Wed, 5 Apr 1995 09:17:05 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA23349 for ; Wed, 5 Apr 1995 09:13:20 -0700 Received: from minnow.render.com ([158.152.30.118]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id DAA22051 for ; Wed, 5 Apr 1995 03:10:36 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id LAA06788; Wed, 5 Apr 1995 11:16:16 +0100 Date: Wed, 5 Apr 1995 11:16:16 +0100 (BST) From: Doug Rabson To: "Jordan K. Hubbard" cc: current@FreeBSD.org Subject: Re: LINT settings In-Reply-To: <24787.797034810@freefall.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Tue, 4 Apr 1995, Jordan K. Hubbard wrote: > > I just put a new SoundBlaster16 + CD in my machine. All the FreeBSD > > drivers appear to work fine (well I can play .au files and mount the > > CDROM). One extremely minor point is that the default port setting for > > the sbmidi0 device in LINT is 0x300 whereas the default on the card was > > 0x330 (both on the card and in the manual). > > I think it was set this way to avoid SCSI controller clash.. Hmmmmmm. > Suggestions? Well there are at least half a dozen entries in GENERIC which use port 0x300 so one more shouldn't hurt... -- Doug Rabson, RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Wed Apr 5 09:24:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA23494 for current-outgoing; Wed, 5 Apr 1995 09:24:29 -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 JAA23487 ; Wed, 5 Apr 1995 09:24:17 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA25931; Wed, 5 Apr 1995 12:22:13 -0400 Date: Wed, 5 Apr 1995 12:22:13 -0400 From: Garrett Wollman Message-Id: <9504051622.AA25931@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: current@freefall.cdrom.com Subject: "Cookbook" for security. In-Reply-To: <15076.797078123@freefall.cdrom.com> References: <15076.797078123@freefall.cdrom.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > It seems to me that this would serve as a very valuable security aid > and of use in creating the overall security tool from hell that I'd > like to see on FreeBSD someday! :-) One of the results of `make distribution' should be to `cd /where/ever; mtree > /somewhere/else/distname.mtree'. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Apr 5 09:47:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA23684 for current-outgoing; Wed, 5 Apr 1995 09:47:39 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA23678 for ; Wed, 5 Apr 1995 09:47:35 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Wed, 5 Apr 1995 11:46:40 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Apr 1995 11:46:43 -0500 To: Garrett Wollman From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Why do you care WHERE the obj files reside? Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk ><Wackerbarth) said: > >> I don't understand how this is related to WHERE the objects are located. >> In order to DTRT, the objects could be totally inaccessable to YOU as long >> as they were accessable to the "Make". > >Because I want things like `touch obj/foo.o' to still work right. I'm not sure why YOU want to do this. It is certainly not the cannonical form of a directive for a make rule. You must be trying to "trick" make into doing something that it would not routinely do. However, as I have previously said, YOU may add links to your tree. It is just that "make" will not use them. > And >I want things like `cd /usr/src/usr.sbin/mrouted; patch -p < >~/mrouted.patch; make depend && make all && make install' to work >without having to screw with enviroment variables, mount points, >symbolic links, or other detritus. If you wish to alter the sources in YOUR tree, go right ahead. Of course you will not be reading them from the CDROM. As for the "make" portion of that line, I, too, expect it to work. That is DTRT. Since you have described only one tree, I can use the default definition of the TREE_ROOT, namely "/usr". I'll find the sources in /usr/src/xxx and place the objects in /usr/obj/xxxx just as the present version does. The complication occurs when you have multiple trees and add symbolic links to common code. You have to tell me which tree you are in. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Wed Apr 5 09:51:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA23753 for current-outgoing; Wed, 5 Apr 1995 09:51:57 -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 JAA23746 for ; Wed, 5 Apr 1995 09:51:41 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA25258; Thu, 6 Apr 1995 02:45:42 +1000 Date: Thu, 6 Apr 1995 02:45:42 +1000 From: Bruce Evans Message-Id: <199504051645.CAA25258@godzilla.zeta.org.au> To: ache@astral.msk.su, rgrimes@gndrsh.aac.dev.com Subject: Re: Strange kernel printf... Cc: freebsd-current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> I got strange printf on each kernel reboot, it comes to console >> and log both. >> Here piece of dmesg output: >> ... >> pca0 >> ^^^^^^^^^^^^^!!!!!! Watch this !!!!!!! >> pca0: PC speaker audio driver >> >> I examine pcaudio.c and don't find any additional printf there >> except "pca0: PC speaker audio driver". >> Wrom where this magic "pca0" can come? >> Any ideas? >> Does anybody see it too? >I beleive this is coming from some bad logic in isa.c that has gone >through several changes in attempts to get it to print ``on isa'' >for certain devices that use funny I/O addresses. >It now under certain conditins prints nothing :-(., but atleast the >newline is there :-) :-). >I've been meaning to get in there and fix it, but if you would, please >do. This used to work as follows: isa.c printed "pca0". pcaudio.c printed " PC speaker audio driver\n". isa.c has nothing to print after "pca0" because the driver says that it doesn't use any i/o ports: pcaprobe() returns (-1) (which is a special code meaning `no ports') and the config line for pca0 doesn't specify a port so the iobase is 0 (iobase 0 is thus another special code meaning `no ports'. Apparently there was a convention that the device driver for devices with base port 0 should complete the description of the device and print a new line. pcaattach() did this. This behaviour was broken in two stages: First, isa.c was changed to always print a newline. Apparently some devices didn't follow the convention. The change fixed these devices and broke the pcaudio message to "pca0\n PC speaker audio driver\n". Second, pcaudio was changed to match the changed isa.c. There is no way to undo the newline and the driver wants to be verbose so the end result is a useless line printed by isa.c. This is particularly annoying because the driver lies about the ports that it uses. It actually uses IO_TIMER1 and IO_PPI. The config struct has no way to represent multiple ports per driver, and the config line doesn't use either because IO_TIMER1 should conflict with the clock "driver" and IO_PPI would conflict with keyboard drivers. The config struct also has no way to represent ranges of ports. This is kludged around by having drivers return the number of ports, or (-1) for no ports (0 would be a better value but it means `no device'). The config struct also has no way to represent individual bits within ports. Both IO_TIMER1 and IO_PPI have some bits shared by the pcaudio driver and the clock/syscons driver, and some bits not shared. This is kludged around by doing sloppy conflict checking. Bruce From owner-freebsd-current Wed Apr 5 10:21:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA24034 for current-outgoing; Wed, 5 Apr 1995 10:21:19 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA24028 for ; Wed, 5 Apr 1995 10:21:17 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id KAA24922 for ; Wed, 5 Apr 1995 10:01:40 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Wed, 5 Apr 1995 12:00:49 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Apr 1995 12:00:51 -0500 To: "bo (b.) xiao" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: SATAN ported?? Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk bo (b.) xiao" writes: >It does not in the gcc 2.6.3 days. My 0322snap complains non integer >array subscripts in .c file under ext brunch. There are a lot ST(0.) >over there. Move them to ST(0) fixes the problem but after a make >clean, you have to do it again. Any one knows where are the source >files I should be looking at? I think that gcc may have broken more of perl. I just today noticed that my "mirror" perl scripts that used to work fine are no longer doing the correct thing. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Wed Apr 5 10:33:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA24270 for current-outgoing; Wed, 5 Apr 1995 10:33:02 -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 KAA24262 for ; Wed, 5 Apr 1995 10:32:56 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA26342; Thu, 6 Apr 1995 03:28:17 +1000 Date: Thu, 6 Apr 1995 03:28:17 +1000 From: Bruce Evans Message-Id: <199504051728.DAA26342@godzilla.zeta.org.au> To: dfr@render.com, jkh@freefall.cdrom.com Subject: Re: LINT settings Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Well there are at least half a dozen entries in GENERIC which use port >0x300 so one more shouldn't hurt... Yes it could. Some probes are destructive and screw up other devices. E.g., probing one or both of the bt and uha devices screws up the other if the port is the same. I think GENERIC should have all devices turned off by default and there should be a fancy config to turn them on. Bruce From owner-freebsd-current Wed Apr 5 12:12:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA25717 for current-outgoing; Wed, 5 Apr 1995 12:12: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 MAA25693 ; Wed, 5 Apr 1995 12:12:14 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id MAA01157; Wed, 5 Apr 1995 12:12:04 -0700 From: "Rodney W. Grimes" Message-Id: <199504051912.MAA01157@gndrsh.aac.dev.com> Subject: Re: "Cookbook" for security. To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Wed, 5 Apr 1995 12:12:03 -0700 (PDT) Cc: jkh@freefall.cdrom.com, current@freefall.cdrom.com In-Reply-To: <9504051622.AA25931@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Apr 5, 95 12:22:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1364 Sender: current-owner@FreeBSD.org Precedence: bulk > > < said: > > > It seems to me that this would serve as a very valuable security aid > > and of use in creating the overall security tool from hell that I'd > > like to see on FreeBSD someday! :-) > > One of the results of `make distribution' should be to `cd > /where/ever; mtree > > /somewhere/else/distname.mtree'. Yes, and a lot of the work I put into mtree for the -c option was aimed at just this. Infact at one time /usr/src/etc/mtree/BSD.* where the output of a series of mtree commands I ran and then commited the resulting files. I still run these mtree commands when doing my regression tests of finding out what is working correctly with ``make DESTDIR=foo install''. For creating new versions of /usr/src/etc/mtree/BSD.* files I use: mtree -c -d -i -n -x -kuname,gname,mode -p /usr >/tmp/BSD.usr.dist These still require some hand edits for the header, and now that include has been moved out that requires a hand edit. To create a really good file for checking your system use something like: mtree -c -i -n -kuname,gname,mode,size,link,time,md5digest \ -p / >/tmp/BSD.full.dist -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Wed Apr 5 13:13:17 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA27562 for current-outgoing; Wed, 5 Apr 1995 13:13: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 NAA27546 for ; Wed, 5 Apr 1995 13:12:52 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA29572; Thu, 6 Apr 1995 06:12:14 +1000 Date: Thu, 6 Apr 1995 06:12:14 +1000 From: Bruce Evans Message-Id: <199504052012.GAA29572@godzilla.zeta.org.au> To: nate@sneezy.sri.com, terry@cs.weber.edu Subject: Re: NOTICE: If you care, speak now! Cc: current@FreeBSD.org, phk@ref.tfs.com, rkw@dataplex.net Sender: current-owner@FreeBSD.org Precedence: bulk >> > 3) This is no more of a change than the changes to "install" that are being >> > so widely advocated. >> >> Huh? The install change affects *one* utility, but the changes you are >> advocating effect the entire build process, and from the sounds of it >> every Makefile. And, as a rebuttal, even though the install changes are >> to one tool, because of the significance of the tool those changes might >> not make it into the release. >Oh, ho, he's got you, Nate! That one utility is used to install all the >binaries on the system. 8-). The new flags would have no effect if they weren't used. It's very easy to support the new flags without affecting the current build process if you don't want to: + change `install' + fix some system makefiles that suffer from bitrot: bsd.doc.mk, bsd.info.mk and bsd.man.mk are missing support for ${INSTALLFLAGS}. Users who wish to use the new flags can type make INSTALLFLAGS='-newflag1 =newflag2 ...' If most developers like this then we can change the makefiles to always use the new flags (headers and libararies should be installed without changing the target timestamp if possible). Bruce From owner-freebsd-current Wed Apr 5 13:25:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA28100 for current-outgoing; Wed, 5 Apr 1995 13:25:35 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA28088 for ; Wed, 5 Apr 1995 13:25:23 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id OAA12023; Wed, 5 Apr 1995 14:23:42 -0600 Date: Wed, 5 Apr 1995 14:23:42 -0600 From: Nate Williams Message-Id: <199504052023.OAA12023@trout.sri.MT.net> In-Reply-To: Bruce Evans "Re: NOTICE: If you care, speak now!" (Apr 6, 6:12am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Bruce Evans , terry@cs.weber.edu Subject: New install flags ( was Re: NOTICE: If you care, speak now!) Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > >> > 3) This is no more of a change than the changes to "install" that are being > >> > so widely advocated. > >> > >> Huh? The install change affects *one* utility, but the changes you are > >> advocating effect the entire build process, and from the sounds of it > >> every Makefile. And, as a rebuttal, even though the install changes are > >> to one tool, because of the significance of the tool those changes might > >> not make it into the release. > > >Oh, ho, he's got you, Nate! That one utility is used to install all the > >binaries on the system. 8-). > > The new flags would have no effect if they weren't used. It's very easy > to support the new flags without affecting the current build process if > you don't want to: This assumes that the new install utility has no more bugs than the current version. :-) > + change `install' > + fix some system makefiles that suffer from bitrot: bsd.doc.mk, > bsd.info.mk and bsd.man.mk are missing support for ${INSTALLFLAGS}. > > Users who wish to use the new flags can type > > make INSTALLFLAGS='-newflag1 =newflag2 ...' > > If most developers like this then we can change the makefiles to always > use the new flags (headers and libararies should be installed without > changing the target timestamp if possible). My thoughts exactly. We could incrementaly add them to the tree as we see fit, and after enough testing is done. It wouldn't affect the current process one bit *unless* it was decided by the release engineer to be a worthwhile addition. Nate From owner-freebsd-current Wed Apr 5 13:48:05 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA29091 for current-outgoing; Wed, 5 Apr 1995 13:48:05 -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 NAA29075 for ; Wed, 5 Apr 1995 13:47:49 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA30107; Thu, 6 Apr 1995 06:44:59 +1000 Date: Thu, 6 Apr 1995 06:44:59 +1000 From: Bruce Evans Message-Id: <199504052044.GAA30107@godzilla.zeta.org.au> To: current@FreeBSD.org, nate@trout.sri.MT.net, rgrimes@gndrsh.aac.dev.com, rkw@dataplex.net Subject: Re: Genassym Sender: current-owner@FreeBSD.org Precedence: bulk >I haven't looked at genassym, but assume that it uses the sys headers only >as input text, or equivalently, conditional conpilation flags. If it makes >any assumptions about kernel data structures, etc. it will eventually break >in cross platform compilation. :( You should like at it. It's main job is to print the sizes of and offsets in kernel data structures. (It also gathers the defines for manifest constants from scattered headers files that aren't all ready for inclusion in assembler files, but this is easy to do in other ways.) genassym can't work in it's present form in a cross platform environment, so it's a waste of time to worry about how to build it in such an environment. genassym.s could be built as follows: replace genassym.c by code of the form: long define_FOO = FOO; size_t sizeof_bar = sizeof bar; size_t offset_of_baz_in_bar = offsetof(bar, baz); Compile this to an object file for the target using a cross compiler. Write a post-processor to convert this file (nm file | awk ...). nm outout is very easy to parse. Bruce From owner-freebsd-current Wed Apr 5 15:49:17 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA04024 for current-outgoing; Wed, 5 Apr 1995 15:49:17 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA04018 for ; Wed, 5 Apr 1995 15:49:16 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id PAA21641; Wed, 5 Apr 1995 15:49:12 -0700 Date: Wed, 5 Apr 1995 15:49:09 -0700 From: Richard Chang To: FreeBSD-current@freefall.cdrom.com Subject: ppp still not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Somehow ppp is still not working under the latest -current. A few days ago, when I got ppp working, sup stopped working under both slip and ppp on April Fool's day then when sup worked with Justin Gibb's help of turning off sysctl, ppp no longer works anymore. When I attempt to telnet, it would just not even go through the modem and just say: bigbang# telnet csua.berkeley.edu Hostname lookup not found Slip and sup now works fine without sysctl on rfc1323 and rfc1644. I even compared my ppp setup with someone else at Berkeley and it's the same configuration so anyone have any ideas what's wrong? Thanks for any help. --richardc From owner-freebsd-current Wed Apr 5 18:16:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA07369 for current-outgoing; Wed, 5 Apr 1995 18:16: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 SAA07361 for ; Wed, 5 Apr 1995 18:16:40 -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 DAA11096 ; Thu, 6 Apr 1995 03:15:35 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id DAA11472 ; Thu, 6 Apr 1995 03:15:34 +0200 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.6.11/keltia-uucp-1.21) id DAA00365; Thu, 6 Apr 1995 03:12:49 +0200 From: Ollivier Robert Message-Id: <199504060112.DAA00365@keltia.frmug.fr.net> Subject: Label/slices : how to add a disk ? To: freebsd-current@FreeBSD.org (FreeBSD Current Users' list) Date: Thu, 6 Apr 1995 03:12:48 +0200 (MET DST) Cc: bde@zeta.org.au (Bruce Evans) Reply-To: roberto@blaise.ibp.fr (Ollivier Robert) X-Operating-System: FreeBSD 2.1.0-Development ctm#514 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: 3211 Sender: current-owner@FreeBSD.org Precedence: bulk Hello, I have another problem with the slicing code... I just got a brand new disk, Conner CFP1080S, geometry reported by boot -v is (3659/6/96). The standard translation would give me 1030/64/32. I've been unable to even put a label on it :-( Probe messages : Apr 6 02:44:26 keltia /kernel: (bt0:2:0): "CONNER CFP1080S 3939" is a type 0 fixed SCSI 2 Apr 6 02:44:26 keltia /kernel: sd2(bt0:2:0): Direct-Access 1030MB (2110812 512 byte sectors) fdisk cannot get the correct geometry for it : fdisk /dev/sd2 ******* Working on device /dev/sd2 ******* parameters extracted from in-core disklabel are: cylinders=3658 heads=64 sectors/track=32 (2048 blks/cyl) ^^^^ ^^^^ ^^^ good wrong wrong Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3658 heads=64 sectors/track=32 (2048 blks/cyl) Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 2097152 (1024 Meg), flag 80 beg: cyl 0/ sector 0/ head 0; end: cyl 1023/ sector 32/ head 63 fdisk /dev/rsd2c fdisk: Can't get disk parameters on /dev/rsd2c; supplying dummy ones ******* Working on device /dev/rsd2c ******* parameters extracted from in-core disklabel are: cylinders=1 heads=1 sectors/track=1 (1 blks/cyl) parameters to be used for BIOS calculations are: cylinders=1 heads=1 sectors/track=1 (1 blks/cyl) Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 2097152 (1024 Meg), flag 80 beg: cyl 0/ sector 0/ head 0; end: cyl 1023/ sector 32/ head 63 I've tried to partition it with fdisk with a fair success and get these messages : Apr 6 02:45:51 keltia /kernel: sd2s4: start 1, end = 2097152, size 2097152: OK Apr 6 02:46:20 keltia /kernel: sd2s4: start 1, end = 2097152, size 2097152: OK Apr 6 02:46:20 keltia /kernel: sd2: cannot find label (no disk label) My /etc/disktab entry is like this : # # Conner CFP1080S (FreeBSD 2.1.x) # # a = /new # cfp1080s|Conner CFP1080S 1 GB SCSI-2:\ :dt=SCSI:ty=winchester:\ :nc#1030:ns#32:nt#64:se#512:rm#6300:\ :oa#0:pa#2097152:ta=4.2BSD:ba#8192:fa#1024: disklabel says this : disklabel -w -r sd2 cfp1080s 201 [3:09] root@keltia:~# disklabel -w -r sd2 cfp1080s write: No such file or directory and i got this in messages : sd2s4: start 0, end = 2097151, size 2097152 sd2s4: C/H/S start 0/0/0 (4294967295) != start 0: invalid Why is this slice 4 ? There is no DOS partition on the disk, only big one for FreeBSD... I know the disk is more than 1024 cyl even with standard translation, is this my problem ? I don't understand (Bruce help !) :-( -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.1.0-Development #13: Sun Apr 2 21:38:04 MET DST 1995 From owner-freebsd-current Wed Apr 5 18:24:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA07459 for current-outgoing; Wed, 5 Apr 1995 18:24: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 SAA07452 for ; Wed, 5 Apr 1995 18:24:13 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id SAA01996; Wed, 5 Apr 1995 18:23:48 -0700 From: "Rodney W. Grimes" Message-Id: <199504060123.SAA01996@gndrsh.aac.dev.com> Subject: Re: Label/slices : how to add a disk ? To: roberto@blaise.ibp.fr Date: Wed, 5 Apr 1995 18:23:48 -0700 (PDT) Cc: freebsd-current@FreeBSD.org, bde@zeta.org.au In-Reply-To: <199504060112.DAA00365@keltia.frmug.fr.net> from "Ollivier Robert" at Apr 6, 95 03:12:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1909 Sender: current-owner@FreeBSD.org Precedence: bulk > > Hello, > > I have another problem with the slicing code... > > I just got a brand new disk, Conner CFP1080S, geometry reported by boot -v > is (3659/6/96). The standard translation would give me 1030/64/32. > > I've been unable to even put a label on it :-( > > Probe messages : > > Apr 6 02:44:26 keltia /kernel: (bt0:2:0): "CONNER CFP1080S 3939" is a type 0 fixed SCSI 2 > Apr 6 02:44:26 keltia /kernel: sd2(bt0:2:0): Direct-Access 1030MB (2110812 512 byte sectors) > > fdisk cannot get the correct geometry for it : > > fdisk /dev/sd2 > ******* Working on device /dev/sd2 ******* > parameters extracted from in-core disklabel are: > cylinders=3658 heads=64 sectors/track=32 (2048 blks/cyl) > ^^^^ ^^^^ ^^^ > good wrong wrong Nope, use the override what the BIOS thinks and tell it cyliders=1030, heads=64, sectors/track=32. > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=3658 heads=64 sectors/track=32 (2048 blks/cyl) > > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 0 is: > > The data for partition 1 is: > > The data for partition 2 is: > > The data for partition 3 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 0, size 2097152 (1024 Meg), flag 80 > beg: cyl 0/ sector 0/ head 0; ^^^^^^^^^ Redo the fdisk -u, override the calculation of beg/end. Use cyl 0, sect 1, head 0 for the beg. The default caclulations screw up and put 0 in for the starting sector :-(. > end: cyl 1023/ sector 32/ head 63 > > fdisk /dev/rsd2c ... rest is irrelevant until the above is fixed. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Wed Apr 5 18:26:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA07508 for current-outgoing; Wed, 5 Apr 1995 18:26:15 -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 SAA07502 ; Wed, 5 Apr 1995 18:26:13 -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 DAA11152 ; Thu, 6 Apr 1995 03:26:10 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id DAA11619 ; Thu, 6 Apr 1995 03:26:10 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199504060126.DAA11619@blaise.ibp.fr> Subject: Re: "Cookbook" for security. To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Thu, 6 Apr 1995 03:26:09 +0200 (MET DST) Cc: current@freefall.cdrom.com In-Reply-To: <15076.797078123@freefall.cdrom.com> from "Jordan K. Hubbard" at Apr 5, 95 03:35:23 am X-Operating-System: FreeBSD 2.1.0-Development ctm#480 X-Mailer: ELM [version 2.4 PL23beta2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 788 Sender: current-owner@FreeBSD.org Precedence: bulk > extracting these extra flags ANYWAY, we might as well make a virtue of > a vice and go "cookbook" style on it, where some central well-known > file contains information that can be used to apply the flags in > question after the system is installed. For that matter, the file can > also contain MD5 checksums so that you can verify that all the > "important" files have not been changed from the release copies. > Needless to say, the "cookbook" file should be highly immutable itself > in these cases :-). Check Tripwire from Gene Spafford and ???. It does exactly that with 5 or more "checksums" including md5, snefru, SHA, and so on. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.1.0-Development #7: Thu Mar 23 00:28:31 MET 1995 From owner-freebsd-current Wed Apr 5 18:36:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA07637 for current-outgoing; Wed, 5 Apr 1995 18:36:19 -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 SAA07630 for ; Wed, 5 Apr 1995 18:36:17 -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 DAA11200 ; Thu, 6 Apr 1995 03:35:42 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id DAA11763 ; Thu, 6 Apr 1995 03:35:41 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199504060135.DAA11763@blaise.ibp.fr> Subject: Re: Label/slices : how to add a disk ? To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Thu, 6 Apr 1995 03:35:41 +0200 (MET DST) Cc: freebsd-current@FreeBSD.org, bde@zeta.org.au In-Reply-To: <199504060123.SAA01996@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Apr 5, 95 06:23:48 pm X-Operating-System: FreeBSD 2.1.0-Development ctm#480 X-Mailer: ELM [version 2.4 PL23beta2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 656 Sender: current-owner@FreeBSD.org Precedence: bulk > > beg: cyl 0/ sector 0/ head 0; > ^^^^^^^^^ > > Redo the fdisk -u, override the calculation of beg/end. Use > cyl 0, sect 1, head 0 for the beg. The default caclulations screw > up and put 0 in for the starting sector :-(. I(ve tried that before and ot the partition table. disklabel keeps on barfing on me. I've tried disklabel -B as found in a preceding message and got : 215 [3:34] root@keltia:~# disklabel -B sd2 Bad pack magic number (label is damaged, or pack is unlabeled) -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.1.0-Development #7: Thu Mar 23 00:28:31 MET 1995 From owner-freebsd-current Wed Apr 5 18:56:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA07893 for current-outgoing; Wed, 5 Apr 1995 18:56:56 -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 SAA07886 for ; Wed, 5 Apr 1995 18:56:53 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id SAA02082; Wed, 5 Apr 1995 18:56:42 -0700 From: "Rodney W. Grimes" Message-Id: <199504060156.SAA02082@gndrsh.aac.dev.com> Subject: Re: Label/slices : how to add a disk ? To: roberto@blaise.ibp.fr (Ollivier Robert) Date: Wed, 5 Apr 1995 18:56:41 -0700 (PDT) Cc: freebsd-current@FreeBSD.org, bde@zeta.org.au In-Reply-To: <199504060135.DAA11763@blaise.ibp.fr> from "Ollivier Robert" at Apr 6, 95 03:35:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1313 Sender: current-owner@FreeBSD.org Precedence: bulk > > > > beg: cyl 0/ sector 0/ head 0; > > ^^^^^^^^^ > > > > Redo the fdisk -u, override the calculation of beg/end. Use > > cyl 0, sect 1, head 0 for the beg. The default caclulations screw > > up and put 0 in for the starting sector :-(. > > > I(ve tried that before and ot the partition table. disklabel keeps on > barfing on me. I've tried disklabel -B as found in a preceding message and > got : > > 215 [3:34] root@keltia:~# disklabel -B sd2 > Bad pack magic number (label is damaged, or pack is unlabeled) Do what I said with fdisk, then create a file /tmp/foo that looks like this (only use your numbers): # /dev/rsd0c: type: SCSI disk: MICROP_2112 label: 15MQ1001901HQ30 flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 960 sectors/unit: 1966080 rpm: 5400 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 1966080 0 unused 0 0 # (Cyl. 0 - 959) Then disklabel -R -B sd2 /tmp/foo -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Wed Apr 5 20:42:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA09787 for current-outgoing; Wed, 5 Apr 1995 20:42:57 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id UAA09780 ; Wed, 5 Apr 1995 20:42:56 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: ache@astral.msk.su, rgrimes@gndrsh.aac.dev.com, freebsd-current@freefall.cdrom.com Subject: Re: Strange kernel printf... In-reply-to: Your message of "Thu, 06 Apr 95 02:45:42 +1000." <199504051645.CAA25258@godzilla.zeta.org.au> Date: Wed, 05 Apr 1995 20:42:42 -0700 Message-ID: <9774.797139762@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > This is particularly annoying because the driver lies about the ports > that it uses. It actually uses IO_TIMER1 and IO_PPI. The config struct > has no way to represent multiple ports per driver, and the config line > doesn't use either because IO_TIMER1 should conflict with the clock > "driver" and IO_PPI would conflict with keyboard drivers. Hmmmmm. Would it be useful to have config changed to: 1. Generate arrays of allocated addresses, IRQs (are there any devices made that more than one?), DMA channels, etc. where it currently holds only a single value. 2. Accept a somewhat altered config file specification: device at [#|?] port [, ..] irq [, ..] drq [, ..] [conflict_ok [, ..]] Where "conflict_ok" would take arguments like "iomem, irq, drq, etc." to enable bits in an "allowed conflicts" mask. This would eliminate the ALLOW_CONFLICT_* horrors I inflicted upon the code many months ago. I resisted the impulse to also add some sort of probe priority flag, but if someone can really think of a serious use not already catered to by natural config file ordering (which also kinda bites, now that I think about it - very counter-intuitive!). Seriously, we always talk about how evil config is but no one really does anything about it. Sort of like our attitude towards government, but I digress. How hard would it REALLY be to finally fix config properly? Jordan From owner-freebsd-current Wed Apr 5 20:53:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA09878 for current-outgoing; Wed, 5 Apr 1995 20:53:37 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id UAA09871 ; Wed, 5 Apr 1995 20:53:36 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: rkw@dataplex.net (Richard Wackerbarth) cc: "bo (b.) xiao" , current@FreeBSD.org Subject: Re: SATAN ported?? In-reply-to: Your message of "Wed, 05 Apr 95 12:00:51 CDT." Date: Wed, 05 Apr 1995 20:53:35 -0700 Message-ID: <9870.797140415@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I think that gcc may have broken more of perl. I just today noticed that my > "mirror" perl scripts that used to work fine are no longer doing the > correct thing. I can verify this exactly same problem on one of our own machines.. Its users are not very happy that I upgraded them to -current 2 days ago.. :-( This problem seems to break the copy of perl4 in our source tree, not just perl5 for Satan.. Jordan From owner-freebsd-current Wed Apr 5 21:16:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA10109 for current-outgoing; Wed, 5 Apr 1995 21:16:30 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA10103 for ; Wed, 5 Apr 1995 21:16:26 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Wed, 5 Apr 1995 23:16:14 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Apr 1995 23:16:18 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: SATAN ported?? Cc: "bo (b.) xiao" , current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk "Jordan K. Hubbard" writes: >> I think that gcc may have broken more of perl. I just today noticed that my >> "mirror" perl scripts that used to work fine are no longer doing the >> correct thing. > >I can verify this exactly same problem on one of our own machines.. >Its users are not very happy that I upgraded them to -current 2 days >ago.. :-( This problem seems to break the copy of perl4 in our source >tree, not just perl5 for Satan.. I found that to be the case here. perl5 will not compile and perl4 no longer behaves the same way it used to behave. The problem seems to be associated with tests for zero. I guess that I should go back and run some regression tests on perl4. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Wed Apr 5 21:41:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA10311 for current-outgoing; Wed, 5 Apr 1995 21:41:08 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA10305 for ; Wed, 5 Apr 1995 21:41:07 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id VAA27492; Wed, 5 Apr 1995 21:36:31 -0700 Date: Wed, 5 Apr 1995 21:36:28 -0700 From: Richard Chang To: FreeBSD-current@freefall.cdrom.com Subject: ppp still not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Somehow ppp is still not working under the latest -current. A few days ago, when I got ppp working, sup stopped working under both slip and ppp on April Fool's day then when sup worked with Justin Gibb's help of turning off sysctl, ppp no longer works anymore. When I attempt to telnet, it would just not even go through the modem and just say: bigbang# telnet csua.berkeley.edu Hostname lookup not found Slip and sup now works fine without sysctl on rfc1323 and rfc1644. I even compared my ppp setup with someone else at Berkeley and it's the same configuration so anyone have any ideas what's wrong? Thanks for any help. --richardc From owner-freebsd-current Wed Apr 5 22:28:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA10739 for current-outgoing; Wed, 5 Apr 1995 22:28:04 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA10732 for ; Wed, 5 Apr 1995 22:28:03 -0700 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id WAA01436 for ; Wed, 5 Apr 1995 22:24:50 -0700 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.11/8.6.9) with SMTP id WAA21470; Wed, 5 Apr 1995 22:26:01 -0700 Message-Id: <199504060526.WAA21470@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Kai.Vorma@hut.fi cc: current@FreeBSD.org Subject: Re: patch for sup In-reply-to: Your message of "Wed, 05 Apr 1995 12:15:45 +0300." <199504050915.MAA10911@vinkku.hut.fi> Date: Wed, 05 Apr 1995 22:26:00 -0700 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk >Here is a simple patch for sup that makes it possible to have local >modifications in your source tree so that sup won't overwrite them. The >idea is simple (stolen from this mailing-list, I think :) > > If sup is updating file foo.c and there exists file foo.c#sup it > will update the latter file an leave the former untouched. > >This patch should work with regular files and perhaps with links but >you _cannot_ create shadow directory #foo. I have not tested this >too much (I did it yesterday evening) but I has worked so far just >fine :-) > >Btw, why is freefall's supserver so abysmally slow? Is it because >supservers uses fork() like almost all badly designed network >servers or something else? If the problem is not fork() then I'll try >to see if I can make it faster. > >..vode > >PS. This patch is agains sup.tar.gz from ports-collection. Can you rewrite this so that it doesn't double the number of stat calls needed to do an upgrade? I think you should be doing this check only after a file has been deemed an upgrade target and the test should be made conditionally on a an option to SUP. The test could be done much more simply by doing the stat on upgrade_target.suffix and then if it exists, change the name of the target in the tnode and goto the top of the "upgrade" test cases and loop through them a second time. That way we penalize the special case and leave the common case alone. >+ >+ >+ char *SUFFIX = "#sup"; >+ >+ int tdostat(ls, path, sbuf) >+ int ls; >+ char *path; >+ struct stat *sbuf; >+ { >+ int x, l = strlen(path); >+ >+ strcpy(rname, path); >+ if (l + strlen(SUFFIX) < sizeof(rname)) { >+ strcat(rname, SUFFIX); >+ if ((x = ls ? lstat(rname, sbuf): stat(rname, sbuf)) != -1) { >+ if (sbuf->st_mode&S_IFMT == S_IFDIR) >+ goaway("%s must not be a directory", rname); >+ return x; >+ } >+ if (errno != ENOENT) >+ goaway ("%sstat for %s failed (%d)", ls ? "tl" : "t", rname, errno); >+ rname[l] = '\0'; >+ } >+ return (ls ? lstat(rname, sbuf) : stat(rname, sbuf)); >+ } >+ -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Thu Apr 6 00:25:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA13462 for current-outgoing; Thu, 6 Apr 1995 00:25:36 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA13456 for ; Thu, 6 Apr 1995 00:25:36 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: current@freefall.cdrom.com Subject: PERL4&5 broken in -current and 950322-SNAP! Date: Thu, 06 Apr 1995 00:25:35 -0700 Message-ID: <13455.797153135@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk Just a heads-up. Something in the gcc 2.6.3 upgrade seems to have broken them! One symptom among several is that mirror no longer works.. Jordan From owner-freebsd-current Thu Apr 6 00:43:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA14288 for current-outgoing; Thu, 6 Apr 1995 00:43:36 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA14279 ; Thu, 6 Apr 1995 00:43:34 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id AAA11947; Thu, 6 Apr 1995 00:43:34 -0700 From: Poul-Henning Kamp Message-Id: <199504060743.AAA11947@ref.tfs.com> Subject: Re: Strange kernel printf... To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Thu, 6 Apr 1995 00:43:33 -0700 (PDT) Cc: bde@zeta.org.au, ache@astral.msk.su, rgrimes@gndrsh.aac.dev.com, freebsd-current@freefall.cdrom.com In-Reply-To: <9774.797139762@freefall.cdrom.com> from "Jordan K. Hubbard" at Apr 5, 95 08:42:42 pm Content-Type: text Content-Length: 678 Sender: current-owner@FreeBSD.org Precedence: bulk > 1. Generate arrays of allocated addresses, IRQs (are there any devices > made that more than one?), DMA channels, etc. where it currently holds > only a single value. nca0 for the PAS16, and the sound-drivers come to mind... > Seriously, we always talk about how evil config is but no one really > does anything about it. Sort of like our attitude towards government, > but I digress. How hard would it REALLY be to finally fix config > properly? as in "get rid of config entirely" ? -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant' From owner-freebsd-current Thu Apr 6 00:48:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA14432 for current-outgoing; Thu, 6 Apr 1995 00:48:46 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA14418 for ; Thu, 6 Apr 1995 00:48:39 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id PAA14376; Thu, 6 Apr 1995 15:48:53 +0800 Date: Thu, 6 Apr 1995 15:48:51 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: SATAN ported?? In-Reply-To: <9870.797140415@freefall.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Wed, 5 Apr 1995, Jordan K. Hubbard wrote: > > I can verify this exactly same problem on one of our own machines.. > Its users are not very happy that I upgraded them to -current 2 days > ago.. :-( This problem seems to break the copy of perl4 in our source > tree, not just perl5 for Satan.. SATAN appears to run fine with perl5001 (compiled with gcc 2.6.2 on a 950210-SNAP machine) on my FreeBSD 950322-SNAP system. /bin/sh didn't like the first line of the reconfing script and I get messages that perl exits on a segmentation violation after SATAN has completed its scans. I'm recompiling perl5001 with 2.6.3 and it is complaining that the (0.) array subscript is not an integer (which is true). These source files are generated on-the-fly, but I no longer have my perl build tree from 950210 to see if it used (0.) back then. Replacing the 0.'s with 0's appears to solve the compilation problems. -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Thu Apr 6 01:03:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA15513 for current-outgoing; Thu, 6 Apr 1995 01:03:52 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA15506 ; Thu, 6 Apr 1995 01:03:49 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Poul-Henning Kamp cc: bde@zeta.org.au, ache@astral.msk.su, rgrimes@gndrsh.aac.dev.com, freebsd-current@freefall.cdrom.com Subject: Re: Strange kernel printf... In-reply-to: Your message of "Thu, 06 Apr 95 00:43:33 PDT." <199504060743.AAA11947@ref.tfs.com> Date: Thu, 06 Apr 1995 01:03:47 -0700 Message-ID: <15505.797155427@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > as in "get rid of config entirely" ? No, as in make it work robustly enough that TRULY disgusting hacks on hacks aren't continually required by our config files. Seeing config entirely replaced in my lifetime would not make me sad at all, but I'm not going to wait around for the death of it or fortran! :-) Jordan From owner-freebsd-current Thu Apr 6 01:06:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA15613 for current-outgoing; Thu, 6 Apr 1995 01:06:15 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA15607 for ; Thu, 6 Apr 1995 01:06:11 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id QAA14626; Thu, 6 Apr 1995 16:05:58 +0800 Date: Thu, 6 Apr 1995 16:05:58 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Guess I should forward this from ports to current... apologies to those who will be seeing this twice. -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org ---------- Forwarded message ---------- Date: Thu, 6 Apr 1995 15:58:54 +0800 (CST) From: Brian Tao To: FREEBSD-PORTS-L Subject: Perl 5.001 Just finished building and testing perl 5.001 with all extensions on my 950322-SNAP machine. I get the following errors running the testsuite: cmd/for........FAILED on test 1 op/time........FAILED on test 5 lib/bigint.....FAILED on test 61 lib/bigintpm...FAILED on test 7 Failed 4/90 tests, 95.56% okay. None of these were present when compiled with gcc 2.6.2 on a 950210 machine. The 2.6.2-compiled perl5 also fails now. I noticed this when running the cmd/for test: % /usr/local/bin/perl for.t 1..7 #1 :10: eq :10: #1 :0. 1 2 3 4 5 6 7 8 9 10: eq :0 1 2 3 4 5 6 7 8 9 10: not ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 The first loop prints out a "0." instead of a "0". This anomaly also caused gcc to fail when compiling the extension modules (because perl was generating array subscripts with 0. instead of 0). Anyone have a gcc 2.6.2/pre-950322 machine to test this? -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Thu Apr 6 03:24:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA22712 for current-outgoing; Thu, 6 Apr 1995 03:24:41 -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 DAA22704 for ; Thu, 6 Apr 1995 03:24:24 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA16925; Thu, 6 Apr 1995 20:18:44 +1000 Date: Thu, 6 Apr 1995 20:18:44 +1000 From: Bruce Evans Message-Id: <199504061018.UAA16925@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, taob@gate.sinica.edu.tw Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Sender: current-owner@FreeBSD.org Precedence: bulk > The first loop prints out a "0." instead of a "0". This anomaly >also caused gcc to fail when compiling the extension modules (because >perl was generating array subscripts with 0. instead of 0). Anyone >have a gcc 2.6.2/pre-950322 machine to test this? The C printf function used to print "0" in some cases when it should have printed "0.". Apparently perl's tests expect the broken behaviour. Bruce From owner-freebsd-current Thu Apr 6 04:24:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA23589 for current-outgoing; Thu, 6 Apr 1995 04:24: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 EAA23580 ; Thu, 6 Apr 1995 04:23:56 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA18008; Thu, 6 Apr 1995 21:05:16 +1000 Date: Thu, 6 Apr 1995 21:05:16 +1000 From: Bruce Evans Message-Id: <199504061105.VAA18008@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@freefall.cdrom.com Subject: Re: Strange kernel printf... Cc: ache@astral.msk.su, freebsd-current@freefall.cdrom.com, rgrimes@gndrsh.aac.dev.com Sender: current-owner@FreeBSD.org Precedence: bulk >Hmmmmm. Would it be useful to have config changed to: >1. Generate arrays of allocated addresses, IRQs (are there any devices > made that more than one?), DMA channels, etc. where it currently holds > only a single value. Config already seem to handle this reasonably: device foo0 at isa? port 1 iomem 2 iosize 3 drq 4 irq 5 vector foointr device foo0 at isa? port 6 iomem 7 iosize 8 drq 9 irq 10 You can repeat everything except the vector and a reasonable arrays are built. >2. Accept a somewhat altered config file specification: >device at [#|?] port [, ..] irq [, ..] drq [, ..] > [conflict_ok [, ..]] Although repeating the device lines is a hack, its syntax is simpler and exactly matches the data structures that should be built, at least in ioconf.c (you wouldn't want variable length arrays or linked lists). >Where "conflict_ok" would take arguments like "iomem, irq, drq, etc." >to enable bits in an "allowed conflicts" mask. This would eliminate >the ALLOW_CONFLICT_* horrors I inflicted upon the code many months ago. I don't like this. Conflicts need to be resolved at runtime. The static conflict checking code in isa.c should go away and be replaced by calls such as register_iobase(iobase, iosize, id, flags); There should be flags for exclusive access and for preventing exclusive access by other drivers. Bruce From owner-freebsd-current Thu Apr 6 06:10:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA26081 for current-outgoing; Thu, 6 Apr 1995 06:10:25 -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 GAA26073 for ; Thu, 6 Apr 1995 06:10:22 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id KAA13746; Thu, 6 Apr 1995 10:00:25 +0100 Date: Thu, 6 Apr 1995 10:00:23 +0100 (BST) From: Doug Rabson To: Bruce Evans cc: jkh@freefall.cdrom.com, current@FreeBSD.org Subject: Re: LINT settings In-Reply-To: <199504051728.DAA26342@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, 6 Apr 1995, Bruce Evans wrote: > >Well there are at least half a dozen entries in GENERIC which use port > >0x300 so one more shouldn't hurt... > > Yes it could. Some probes are destructive and screw up other devices. > E.g., probing one or both of the bt and uha devices screws up the other > if the port is the same. > > I think GENERIC should have all devices turned off by default and there > should be a fancy config to turn them on. I wasn't suggesting that the sbmidi0 device goes into GENERIC. All I meant was that LINT should have the correct defaults for it. -- Doug Rabson, RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Thu Apr 6 06:48:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA26904 for current-outgoing; Thu, 6 Apr 1995 06:48:22 -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 GAA26886 for ; Thu, 6 Apr 1995 06:48:02 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA21963; Thu, 6 Apr 1995 23:45:33 +1000 Date: Thu, 6 Apr 1995 23:45:33 +1000 From: Bruce Evans Message-Id: <199504061345.XAA21963@godzilla.zeta.org.au> To: rgrimes@gndrsh.aac.dev.com, roberto@blaise.ibp.fr Subject: Re: Label/slices : how to add a disk ? Cc: bde@zeta.org.au, freebsd-current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> I just got a brand new disk, Conner CFP1080S, geometry reported by boot -v >> is (3659/6/96). The standard translation would give me 1030/64/32. >> >> I've been unable to even put a label on it :-( >> ... >> Apr 6 02:44:26 keltia /kernel: (bt0:2:0): "CONNER CFP1080S 3939" is a type 0 fixed SCSI 2 >> Apr 6 02:44:26 keltia /kernel: sd2(bt0:2:0): Direct-Access 1030MB (2110812 512 byte sectors) >> ... >> fdisk /dev/sd2 >> ******* Working on device /dev/sd2 ******* >> parameters extracted from in-core disklabel are: >> cylinders=3658 heads=64 sectors/track=32 (2048 blks/cyl) >> ^^^^ ^^^^ ^^^ >> good wrong wrong Actually:-) wrong good good >Nope, use the override what the BIOS thinks and tell it >cyliders=1030, heads=64, sectors/track=32. The dummy in-core label for /dev/sd2 is supposed to give the BIOS geometry, but it got the number of cylinders wrong (known bug, it doesn't change it from the H=6/S=96 geometry to the H=64/S=32. There are a lot of different numbers for the number of cylinders for the 6/96 geometry! The BIOS says 3659, the dummy label says 3658, but 2110812/8/96 is 3664 with a remainder of 348. 1030/64/32 is correct (remainder 1372). >> The data for partition 3 is: >> sysid 165,(FreeBSD/NetBSD/386BSD) >> start 0, size 2097152 (1024 Meg), flag 80 >> beg: cyl 0/ sector 0/ head 0; > ^^^^^^^^^ >Redo the fdisk -u, override the calculation of beg/end. Use >cyl 0, sect 1, head 0 for the beg. The default caclulations screw >up and put 0 in for the starting sector :-(. Another known bug. I didn't expect it to cause so much trouble. I expected people who use the whole disk for FreeBSD to not even run fdisk. For this to work, you have to have a disk that doesn't have a partition table. This is easy to arrange by overwriting the partition table: dd if=/dev/zero of=/dev/rsd2 count=1 to clear the MBR or dd if=/dev/zero of=/dev/sd2 bs=1 seek=46 count=66 to clear the partition table (leaving the bootstrap intact) or dd if=/dev/zero of=/dev/sd2 bs=1 seek=510 count=2 to clear only the partition-table-valid magic. Then normal (poor) BSD methods apply: disklabel -w -r [-B] sd2 disktabentry [...] The driver knows almost everything about the disk geometry and puts it in the dummy in-core label on for /dev/rsd2, but there is no convenient way to get the geometry onto the disk /dev/rsd2c. There is no dummy in-core label for /dev/rsd2c because the disk isn't considered to be a BSD disk until it is labeled. Bruce From owner-freebsd-current Thu Apr 6 07:03:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA27333 for current-outgoing; Thu, 6 Apr 1995 07:03:55 -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 HAA27324 for ; Thu, 6 Apr 1995 07:03:39 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA22412; Fri, 7 Apr 1995 00:00:00 +1000 Date: Fri, 7 Apr 1995 00:00:00 +1000 From: Bruce Evans Message-Id: <199504061400.AAA22412@godzilla.zeta.org.au> To: rgrimes@gndrsh.aac.dev.com, roberto@blaise.ibp.fr Subject: Re: Label/slices : how to add a disk ? Cc: bde@zeta.org.au, freebsd-current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> 215 [3:34] root@keltia:~# disklabel -B sd2 >> Bad pack magic number (label is damaged, or pack is unlabeled) >Do what I said with fdisk, then create a file /tmp/foo that looks like >this (only use your numbers): ># /dev/rsd0c: >type: SCSI >disk: MICROP_2112 >label: 15MQ1001901HQ30 >... >8 partitions: ># size offset fstype [fsize bsize bps/cpg] > c: 1966080 0 unused 0 0 # (Cyl. 0 - 959) >Then disklabel -R -B sd2 /tmp/foo I think you can create a suitable /tmp/foo using disklabel /dev/rsd2 >/tmp/foo You'll have to edit the unused (?) rpm and interleave fields to satisfy disklabel(8) and some ASCII fields for printing in bug reports (:-). The driver should initialize a few more fields. Bruce From owner-freebsd-current Thu Apr 6 07:08:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA27466 for current-outgoing; Thu, 6 Apr 1995 07:08:23 -0700 Received: from gw.itfs.nsk.su (gw.itfs.nsk.su [193.124.36.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA27448 for ; Thu, 6 Apr 1995 07:08:07 -0700 Received: from localhost (nnd@localhost) by gw.itfs.nsk.su (8.6.4/8.6.4) id UAA10720 for freebsd-current@FreeBSD.org; Thu, 6 Apr 1995 20:24:44 +0700 Date: Thu, 6 Apr 1995 20:24:44 +0700 From: "Nickolay N. Dudorov" Message-Id: <199504061324.UAA10720@gw.itfs.nsk.su> To: freebsd-current@FreeBSD.org Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Sender: current-owner@FreeBSD.org Precedence: bulk >From: Bruce Evans >> The first loop prints out a "0." instead of a "0". This anomaly >>also caused gcc to fail when compiling the extension modules (because >>perl was generating array subscripts with 0. instead of 0). Anyone >>have a gcc 2.6.2/pre-950322 machine to test this? >The C printf function used to print "0" in some cases when it should >have printed "0.". Apparently perl's tests expect the broken behaviour. This is very strange but on FreeBSD-1.1.5.1, FreeBSD-2.0-950210-SNAP, SunOS 4.1.3 and ISC 3.0 my test program prints: 1 0 and only on FreeBSD-current I see: 1 0. (Test program : main() { char b[256]; sprintf(b,"%g",1.0); printf("%s\n",b); sprintf(b,"%g",0.0); printf("%s\n",b); } N.Dudorov From owner-freebsd-current Thu Apr 6 07:20:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA27945 for current-outgoing; Thu, 6 Apr 1995 07:20:52 -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 HAA27937 for ; Thu, 6 Apr 1995 07:20:49 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA27254; Thu, 6 Apr 1995 10:19:47 -0400 Date: Thu, 6 Apr 1995 10:19:47 -0400 From: Garrett Wollman Message-Id: <9504061419.AA27254@halloran-eldar.lcs.mit.edu> To: Bruce Evans Cc: current@FreeBSD.org Subject: Re: LINT settings In-Reply-To: <199504051728.DAA26342@godzilla.zeta.org.au> References: <199504051728.DAA26342@godzilla.zeta.org.au> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > I think GENERIC should have all devices turned off by default and there > should be a fancy config to turn them on. It wouldn't be GENERIC then. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Thu Apr 6 07:37:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA28549 for current-outgoing; Thu, 6 Apr 1995 07:37:56 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA28543 ; Thu, 6 Apr 1995 07:37:49 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id IAA14940; Thu, 6 Apr 1995 08:42:07 -0600 Date: Thu, 6 Apr 1995 08:42:07 -0600 Message-Id: <199504061442.IAA14940@trout.sri.MT.net> To: "Jordan K. Hubbard" Cc: current@freefall.cdrom.com Subject: Re: PERL4&5 broken in -current and 950322-SNAP! In-Reply-To: <13455.797153135@freefall.cdrom.com> References: <13455.797153135@freefall.cdrom.com> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > Just a heads-up. Something in the gcc 2.6.3 upgrade seems to have broken > them! Actually, I think it's my change to the shlibs that's broken them. I may pull it and see. Nate From owner-freebsd-current Thu Apr 6 07:50:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA28876 for current-outgoing; Thu, 6 Apr 1995 07:50:48 -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 HAA28870 for ; Thu, 6 Apr 1995 07:50:46 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA27331; Thu, 6 Apr 1995 10:50:45 -0400 Date: Thu, 6 Apr 1995 10:50:45 -0400 From: Garrett Wollman Message-Id: <9504061450.AA27331@halloran-eldar.lcs.mit.edu> To: current@FreeBSD.org Subject: Re: khavrinen nightly sup run In-Reply-To: <199504061104.HAA09819@khavrinen.lcs.mit.edu> References: <199504061104.HAA09819@khavrinen.lcs.mit.edu> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > SUP Created directory TODO-2.1 for TODO-2.1/CVS/Entries > SUP Created directory TODO-2.1/CVS for TODO-2.1/CVS/Entries > SUP Receiving file TODO-2.1/CVS/Entries > SUP Receiving file TODO-2.1/CVS/Repository -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Thu Apr 6 07:59:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA28977 for current-outgoing; Thu, 6 Apr 1995 07:59:15 -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 HAA28968 for ; Thu, 6 Apr 1995 07:58:58 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA24079; Fri, 7 Apr 1995 00:53:03 +1000 Date: Fri, 7 Apr 1995 00:53:03 +1000 From: Bruce Evans Message-Id: <199504061453.AAA24079@godzilla.zeta.org.au> To: bde@zeta.org.au, wollman@halloran-eldar.lcs.mit.edu Subject: Re: LINT settings Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> I think GENERIC should have all devices turned off by default and there >> should be a fancy config to turn them on. >It wouldn't be GENERIC then. It isn't generic now. All the special devices would have to be turned off for it to be generic. You would be left with isa0, fdc0, fd[0-1], wdc0, wd[0-1], npx0, sio[0-1] and lpt[0-3]. All other devices have nonstandard addresses so probing is dangerous. Unfortunately a generic machine can't be guaranteed to have a hard disk. wdc0 is safe to probe but there may be non-disk there. Bruce From owner-freebsd-current Thu Apr 6 08:09:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA29253 for current-outgoing; Thu, 6 Apr 1995 08:09:39 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA29247 for ; Thu, 6 Apr 1995 08:09:37 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0rwtBa-000K0iC; Thu, 6 Apr 95 08:09 WET DST Message-Id: Date: Thu, 6 Apr 95 08:09 WET DST From: pete@pelican.com (Pete Carah) To: current@FreeBSD.org Subject: Re: Label/slices : how to add a disk ? In-Reply-To: <199504061345.XAA21963@godzilla.zeta.org.au> Organization: Pelican Consulting Sender: current-owner@FreeBSD.org Precedence: bulk In article <199504061345.XAA21963@godzilla.zeta.org.au> bde writes: .... >For this to work, you have to have a disk that doesn't have a partition >table. This is easy to arrange by overwriting the partition table: > dd if=/dev/zero of=/dev/rsd2 count=1 >to clear the MBR or > dd if=/dev/zero of=/dev/sd2 bs=1 seek=46 count=66 ^^ this can't be right. The table ends at byte 510 - the seek must be 446 (and 66 will wipe the signature too; if you want the bootstrap to work with another table you need that back.) 46 will write in the code area. >to clear the partition table (leaving the bootstrap intact) or > dd if=/dev/zero of=/dev/sd2 bs=1 seek=510 count=2 >to clear only the partition-table-valid magic. Actually that is the bootstrap-code-valid magic; an all-0 partition table *is* valid for no allocated partitions. Presuming this to flag the table as valid is true (it actually flags both) but nuking it will make any Microsoft/IBM fdisk (maybe not ours) overwrite the code too later. I don't know what dos does with a valid table and no boot code and no signature; I've never tried it... There is a related problem with floppies with valid BPB's with no boot code, and no signature; our pcfs driver doesn't recognize them as dos floppies (because of the no signature), thus making about half the brands of preformatted floppies not work with pcfs. (they properly don't have the signature, so they don't fool the bios into branching into the block of 0's above the BPB. DOS and OS/2 both use them just fine as FAT filesystems.) This comes from using the signature for two separate purposes... -- Pete From owner-freebsd-current Thu Apr 6 08:13:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA29344 for current-outgoing; Thu, 6 Apr 1995 08:13:35 -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 IAA29331 for ; Thu, 6 Apr 1995 08:13:26 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA24533; Fri, 7 Apr 1995 01:10:00 +1000 Date: Fri, 7 Apr 1995 01:10:00 +1000 From: Bruce Evans Message-Id: <199504061510.BAA24533@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, nnd@gw.itfs.nsk.su Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Sender: current-owner@FreeBSD.org Precedence: bulk > This is very strange but on FreeBSD-1.1.5.1, FreeBSD-2.0-950210-SNAP, >SunOS 4.1.3 and ISC 3.0 my test program prints: >1 >0 >and only on FreeBSD-current I see: >1 >0. >(Test program : >main() >{ >char b[256]; >sprintf(b,"%g",1.0); >printf("%s\n",b); >sprintf(b,"%g",0.0); >printf("%s\n",b); >} It looks like I was too creative editing the 1.1.5 changes for -current :-(. "0." is only correct for "%#g". I will fix this soon. Bruce From owner-freebsd-current Thu Apr 6 08:33:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA29793 for current-outgoing; Thu, 6 Apr 1995 08:33:03 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA29785 for ; Thu, 6 Apr 1995 08:32:57 -0700 Received: by sovcom.kiae.su id AA01630 (5.65.kiae-2 for freebsd-current@FreeBSD.org); Thu, 6 Apr 1995 19:22:29 +0400 Received: by sovcom.KIAE.su (UUMAIL/2.0); Thu, 6 Apr 95 19:22:27 +0300 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id TAA02904; Thu, 6 Apr 1995 19:15:44 +0400 To: freebsd-current@FreeBSD.org, "Nickolay N. Dudorov" References: <199504061324.UAA10720@gw.itfs.nsk.su> In-Reply-To: <199504061324.UAA10720@gw.itfs.nsk.su>; from "Nickolay N. Dudorov" at Thu, 6 Apr 1995 20:24:44 +0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 6 Apr 1995 19:15:44 +0400 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Lines: 50 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1327 Sender: current-owner@FreeBSD.org Precedence: bulk In message <199504061324.UAA10720@gw.itfs.nsk.su> Nickolay N. Dudorov writes: >>From: Bruce Evans >>> The first loop prints out a "0." instead of a "0". This anomaly >>>also caused gcc to fail when compiling the extension modules (because >>>perl was generating array subscripts with 0. instead of 0). Anyone >>>have a gcc 2.6.2/pre-950322 machine to test this? >>The C printf function used to print "0" in some cases when it should >>have printed "0.". Apparently perl's tests expect the broken behaviour. > This is very strange but on FreeBSD-1.1.5.1, FreeBSD-2.0-950210-SNAP, >SunOS 4.1.3 and ISC 3.0 my test program prints: >1 >0 >and only on FreeBSD-current I see: >1 >0. I think, we still have a bug here. Why 1 instead of 1. ? And more generic why: I think it should be 1.0 0.0 or return to 1 0 (SunOS and ISC can be treated as some kind of standard behaviour) >(Test program : >main() >{ >char b[256]; >sprintf(b,"%g",1.0); >printf("%s\n",b); >sprintf(b,"%g",0.0); >printf("%s\n",b); >} -- 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 Thu Apr 6 09:13:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA00962 for current-outgoing; Thu, 6 Apr 1995 09:13:48 -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 JAA00947 for ; Thu, 6 Apr 1995 09:13:38 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA26085; Fri, 7 Apr 1995 02:07:45 +1000 Date: Fri, 7 Apr 1995 02:07:45 +1000 From: Bruce Evans Message-Id: <199504061607.CAA26085@godzilla.zeta.org.au> To: current@FreeBSD.org, pete@pelican.com Subject: Re: Label/slices : how to add a disk ? Sender: current-owner@FreeBSD.org Precedence: bulk >> dd if=/dev/zero of=/dev/sd2 bs=1 seek=46 count=66 > ^^ this can't be right. >The table ends at byte 510 - the seek must be 446 (and 66 will wipe >the signature too; if you want the bootstrap to work with another >table you need that back.) 46 will write in the code area. >>to clear the partition table (leaving the bootstrap intact) or I meant to type 446. It's important to clear the signature because the driver interprets the signature as belonging to the table and not to the bootblock (there's no better way to tell if the partition table is supposed to be valid) and an empty table means that there are 4 empty slices, not that the whole disk is for BSD. I forgot to say that when you write a boot block, the signature will come back together with a bogus partition table. The driver interprets the combination of the particular bogus table and the signature as a big signature saying that the whole disk is for FreeBSD. >> dd if=/dev/zero of=/dev/sd2 bs=1 seek=510 count=2 >>to clear only the partition-table-valid magic. >Actually that is the bootstrap-code-valid magic; an all-0 partition >table *is* valid for no allocated partitions. Presuming this to >flag the table as valid is true (it actually flags both) but nuking >it will make any Microsoft/IBM fdisk (maybe not ours) overwrite the >code too later. I don't know what dos does with a valid table and no >boot code and no signature; I've never tried it... I assumed that the signature would always come back if the whole disk is used for BSD, but it doesn't come back if you never run fdisk and only run disklabel without -B. I don't know what other fdisks do with the bogus partition table. I assume that people who want to use a purely for BSD won't allow foreign fdisks near it. >There is a related problem with floppies with valid BPB's with no boot >code, and no signature; our pcfs driver doesn't recognize them as dos >floppies (because of the no signature), thus making about half the brands >of preformatted floppies not work with pcfs. (they properly don't have The file system iscalled msdosfs now :) and still has this check :(. Bruce From owner-freebsd-current Thu Apr 6 09:16:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA01134 for current-outgoing; Thu, 6 Apr 1995 09:16:35 -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 JAA01128 for ; Thu, 6 Apr 1995 09:16:30 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA26149; Fri, 7 Apr 1995 02:12:19 +1000 Date: Fri, 7 Apr 1995 02:12:19 +1000 From: Bruce Evans Message-Id: <199504061612.CAA26149@godzilla.zeta.org.au> To: ache@astral.msk.su, nnd@gw.itfs.nsk.su Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> This is very strange but on FreeBSD-1.1.5.1, FreeBSD-2.0-950210-SNAP, >>SunOS 4.1.3 and ISC 3.0 my test program prints: >>1 >>0 >>and only on FreeBSD-current I see: >>1 >>0. >I think, we still have a bug here. >Why 1 instead of 1. ? >And more generic why: I think it should be >1.0 >0.0 >or return to >1 >0 >(SunOS and ISC can be treated as some kind of standard behaviour) Trailing `.'s and zeros aren't printf for %g format. Bruce From owner-freebsd-current Thu Apr 6 09:19:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA01197 for current-outgoing; Thu, 6 Apr 1995 09:19:22 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA01182 for ; Thu, 6 Apr 1995 09:19:09 -0700 Received: by sequent.kiae.su id AA03157 (5.65.kiae-2 ); Thu, 6 Apr 1995 20:12:52 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 6 Apr 95 20:12:49 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id UAA00325; Thu, 6 Apr 1995 20:10:48 +0400 To: Bruce Evans , freebsd-current@FreeBSD.org, nnd@gw.itfs.nsk.su References: <199504061510.BAA24533@godzilla.zeta.org.au> In-Reply-To: <199504061510.BAA24533@godzilla.zeta.org.au>; from Bruce Evans at Fri, 7 Apr 1995 01:10:00 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 6 Apr 1995 20:10:47 +0400 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Lines: 15 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 670 Sender: current-owner@FreeBSD.org Precedence: bulk In message <199504061510.BAA24533@godzilla.zeta.org.au> Bruce Evans writes: >It looks like I was too creative editing the 1.1.5 changes for -current :-(. >"0." is only correct for "%#g". I will fix this soon. Bruce, why 0. instead of 0.0 (I mean %#g now)? Manpage said that 'g' switched to 'e' or 'f', and at least one digit is required after '.' according to manpage. -- 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 Thu Apr 6 09:33:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA01598 for current-outgoing; Thu, 6 Apr 1995 09:33:56 -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 JAA01573 for ; Thu, 6 Apr 1995 09:33:37 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA26669; Fri, 7 Apr 1995 02:29:28 +1000 Date: Fri, 7 Apr 1995 02:29:28 +1000 From: Bruce Evans Message-Id: <199504061629.CAA26669@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, nnd@gw.itfs.nsk.su Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Sender: current-owner@FreeBSD.org Precedence: bulk >>The C printf function used to print "0" in some cases when it should >>have printed "0.". Apparently perl's tests expect the broken behaviour. > This is very strange but on FreeBSD-1.1.5.1, FreeBSD-2.0-950210-SNAP, >SunOS 4.1.3 and ISC 3.0 my test program prints: >1 >0 >and only on FreeBSD-current I see: >1 >0. >(Test program : >main() >{ >char b[256]; >sprintf(b,"%g",1.0); >printf("%s\n",b); >sprintf(b,"%g",0.0); >printf("%s\n",b); >} Fixed. vfprintf() was broken. Thanks for the bug report. Bruce From owner-freebsd-current Thu Apr 6 09:44:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA01741 for current-outgoing; Thu, 6 Apr 1995 09:44:22 -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 JAA01734 for ; Thu, 6 Apr 1995 09:44:10 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA26892; Fri, 7 Apr 1995 02:39:08 +1000 Date: Fri, 7 Apr 1995 02:39:08 +1000 From: Bruce Evans Message-Id: <199504061639.CAA26892@godzilla.zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, freebsd-current@FreeBSD.org, nnd@gw.itfs.nsk.su Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Sender: current-owner@FreeBSD.org Precedence: bulk >>It looks like I was too creative editing the 1.1.5 changes for -current :-(. >>"0." is only correct for "%#g". I will fix this soon. >Bruce, why 0. instead of 0.0 (I mean %#g now)? >Manpage said that 'g' switched to 'e' or 'f', >and at least one digit is required after '.' according to manpage. Actually 0.00000 is correct for "%#g". The default precision is 6 so the `#' flag forces 6 digits. I was thinking of a more obscure case involving precision 0 or 1 when I wrote "0.". Bruce From owner-freebsd-current Thu Apr 6 10:12:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA02315 for current-outgoing; Thu, 6 Apr 1995 10:12:16 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA02304 ; Thu, 6 Apr 1995 10:12:14 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA13822; Thu, 6 Apr 95 11:05:52 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504061705.AA13822@cs.weber.edu> Subject: Re: Strange kernel printf... To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Thu, 6 Apr 95 11:05:52 MDT Cc: jkh@freefall.cdrom.com, bde@zeta.org.au, ache@astral.msk.su, rgrimes@gndrsh.aac.dev.com, freebsd-current@freefall.cdrom.com In-Reply-To: <199504060743.AAA11947@ref.tfs.com> from "Poul-Henning Kamp" at Apr 6, 95 00:43:33 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > Seriously, we always talk about how evil config is but no one really > > does anything about it. Sort of like our attitude towards government, > > but I digress. How hard would it REALLY be to finally fix config > > properly? > > as in "get rid of config entirely" ? That was my gut reaction as well. 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 Apr 6 10:16:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA02407 for current-outgoing; Thu, 6 Apr 1995 10:16:41 -0700 Received: from FirePower.COM (firepower.firepower.com [198.4.104.7]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA02400 for ; Thu, 6 Apr 1995 10:16:39 -0700 Received: from tuskppp by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA01725; Thu, 6 Apr 95 10:15:28 -0700 Received: from rhiannon by tusk.dsms.sanmateo.ca.us (NX5.67e/NX3.0M.dsms.0.3) id AA06372; Thu, 6 Apr 95 10:15:26 -0700 Message-Id: <9504061715.AA06372@tusk.dsms.sanmateo.ca.us> Received: by rhiannon.dsms.sanmateo.ca.us (NX5.67e/NX3.0X) id AA00575; Thu, 6 Apr 95 10:15:24 -0700 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Received: by NeXT.Mailer (1.118.2) From: harold barker Date: Thu, 6 Apr 95 10:15:21 -0700 To: Brian Tao Subject: Re: PERL4&5 broken in -current and 950322-SNAP! Cc: freebsd-current@FreeBSD.org References: Sender: current-owner@FreeBSD.org Precedence: bulk When gcc 2.6.3 came out i tried to compile it on a number of our machines = (rs6k, HPUX9.5, SUN 4.1.3, NeXT 3.3/3.2) not one compile made it through = with out core dumping on libg++, so i stayed at 2.6.2. > Guess I should forward this from ports to current... apologies to > those who will be seeing this twice. > --=20 > Brian ("Though this be madness, yet there is method in't") Tao > taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org >=20 > ---------- Forwarded message ---------- > Date: Thu, 6 Apr 1995 15:58:54 +0800 (CST) > From: Brian Tao > To: FREEBSD-PORTS-L > Subject: Perl 5.001 >=20 > Just finished building and testing perl 5.001 with all extensions > on my 950322-SNAP machine. I get the following errors running the > testsuite: >=20 > cmd/for........FAILED on test 1 > op/time........FAILED on test 5 > lib/bigint.....FAILED on test 61 > lib/bigintpm...FAILED on test 7 > Failed 4/90 tests, 95.56% okay. >=20 > None of these were present when compiled with gcc 2.6.2 on a > 950210 machine. The 2.6.2-compiled perl5 also fails now. >=20 > I noticed this when running the cmd/for test: >=20 > % /usr/local/bin/perl for.t > 1..7 > #1 :10: eq :10: > #1 :0. 1 2 3 4 5 6 7 8 9 10: eq :0 1 2 3 4 5 6 7 8 9 10: > not ok 1 > ok 2 > ok 3 > ok 4 > ok 5 > ok 6 > ok 7 >=20 > The first loop prints out a "0." instead of a "0". This anomaly > also caused gcc to fail when compiling the extension modules (because > perl was generating array subscripts with 0. instead of 0). Anyone > have a gcc 2.6.2/pre-950322 machine to test this? > --=20 > Brian ("Though this be madness, yet there is method in't") Tao > taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org >=20 From owner-freebsd-current Thu Apr 6 16:16:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA12110 for current-outgoing; Thu, 6 Apr 1995 16:16:43 -0700 Received: from kryten.atinc.com (kryten.atinc.com [198.138.38.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA12102 ; Thu, 6 Apr 1995 16:16:39 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id TAA06315; Thu, 6 Apr 1995 19:13:11 -0400 Date: Thu, 6 Apr 1995 19:13:09 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: Strange kernel printf... To: "Jordan K. Hubbard" cc: Bruce Evans , ache@astral.msk.su, rgrimes@gndrsh.aac.dev.com, freebsd-current@freefall.cdrom.com In-Reply-To: <9774.797139762@freefall.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Wed, 5 Apr 1995, Jordan K. Hubbard wrote: > 2. Accept a somewhat altered config file specification: > > device at [#|?] port [, ..] irq [, ..] drq [, ..] > [conflict_ok [, ..]] > > Where "conflict_ok" would take arguments like "iomem, irq, drq, etc." > to enable bits in an "allowed conflicts" mask. This would eliminate > the ALLOW_CONFLICT_* horrors I inflicted upon the code many months ago. here are diffs to 1.1.5.1 sources that remove the need to the ALLOW_XXX_CONFLICT flags. spec the two devices, how they can conflict, and the order in which they are probed--that conflict is then allowed. alll other conflicts are treated as they are now--the second device is not probed. if this can be used, i will gen patches for 2.0-RELEASE and current as for the last sup. i have used kernels with these patches continuously since sept 1994 when chuck robey helped me get a soundblaster working. i just could live with the ALLOW options in the kernel. patches at end. Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 *** sys/i386/isa/isa.c.orig Fri Aug 26 15:51:21 1994 --- sys/i386/isa/isa.c Sat Sep 3 23:37:34 1994 *************** *** 65,68 **** --- 65,69 ---- #include "i386/isa/ic/i8237.h" #include "i386/isa/ic/i8042.h" + #include "i386/isa/known_conflicts.h" /* *************** *** 84,87 **** --- 85,121 ---- void config_isadev __P((struct isa_device *, u_int *)); + unsigned short + strequal( one, two ) + register const char *one, *two; + { + + while ( *one || *two ) + if ( *one++ != *two++) + return 0; + return 1; + } + + /* + * check the conflict, to see if its allowed + */ + unsigned short + allowed(dvp, tmpdvp, reason) + struct isa_device *dvp, *tmpdvp; + short reason; + { + struct known_conflict *this; + + for( this = known_conflicts; this->sec_name; this++ ) { + if ( ( dvp->id_unit == this->sec_unit ) + && ( tmpdvp->id_unit == this->first_unit ) + && ( reason & this->type ) + && strequal(dvp->id_driver->name, this->sec_name) + && strequal(tmpdvp->id_driver->name, this->first_name) ) { + return 1; + } + } + return 0; + } + /* * print a conflict message *************** *** 126,132 **** (tmpdvp->id_iobase + tmpdvp->id_alive - 1))) { #ifndef ALLOW_CONFLICT_IOADDR ! conflict(dvp, tmpdvp, dvp->id_iobase, ! "I/O address", "0x%x"); ! status = 1; #endif } --- 160,168 ---- (tmpdvp->id_iobase + tmpdvp->id_alive - 1))) { #ifndef ALLOW_CONFLICT_IOADDR ! if ( !allowed(dvp, tmpdvp, IO_CONFLICT) ) { ! conflict(dvp, tmpdvp, dvp->id_iobase, ! "I/O address", "0x%x"); ! status = 1; ! } #endif } *************** *** 147,153 **** (tmpdvp->id_maddr + tmpdvp->id_msize - 1))) { #ifndef ALLOW_CONFLICT_MEMADDR ! conflict(dvp, tmpdvp, dvp->id_maddr, "maddr", ! "0x%x"); ! status = 1; #endif } --- 183,191 ---- (tmpdvp->id_maddr + tmpdvp->id_msize - 1))) { #ifndef ALLOW_CONFLICT_MEMADDR ! if ( !allowed(dvp, tmpdvp, MEM_CONFLICT) ) { ! conflict(dvp, tmpdvp, dvp->id_maddr, ! "maddr", "0x%x"); ! status = 1; ! } #endif } *************** *** 159,165 **** if(tmpdvp->id_irq) { if (tmpdvp->id_irq == dvp->id_irq) { ! conflict(dvp, tmpdvp, ffs(dvp->id_irq) - 1, ! "irq", "%d"); ! status = 1; } } --- 197,205 ---- if(tmpdvp->id_irq) { if (tmpdvp->id_irq == dvp->id_irq) { ! if ( !allowed(dvp, tmpdvp, IRQ_CONFLICT) ) { ! conflict(dvp, tmpdvp, ffs(dvp->id_irq) - 1, ! "irq", "%d"); ! status = 1; ! } } } *************** *** 171,177 **** if(tmpdvp->id_drq != -1) { if (tmpdvp->id_drq == dvp->id_drq) { ! conflict(dvp, tmpdvp, dvp->id_drq, ! "drq", "%d"); ! status = 1; } } --- 211,219 ---- if(tmpdvp->id_drq != -1) { if (tmpdvp->id_drq == dvp->id_drq) { ! if ( !allowed(dvp, tmpdvp, DRQ_CONFLICT) ) { ! conflict(dvp, tmpdvp, dvp->id_drq, ! "drq", "%d"); ! status = 1; ! } } } *** sys/i386/isa/sound/sb16_dsp.c.orig Fri Sep 2 13:09:13 1994 --- sys/i386/isa/sound/sb16_dsp.c Fri Sep 2 13:38:12 1994 *************** *** 506,509 **** --- 506,513 ---- switch (level) { + case 2: /* XXX jmb 940902 added this, set the lowest bit ?? */ + case 9: /* yes both irq 2 and irq 9 are the same */ + ival = 1; + break; case 5: ival = 2; *** /dev/null Mon Sep 5 12:37:56 1994 --- sys/i386/isa/known_conflicts.h Mon Sep 5 12:57:05 1994 *************** *** 0 **** --- 1,36 ---- + /* + ** list of known conflicting isa bus devices and the manner in which + ** which they conflict. + ** + ** each entry in the known_conflicts strcuture defines a single allowed + ** conflict: + ** sec_name: name of the conflicting device as recorded in + ** isa_device->id_driver->name + ** sec_unit: unit number of conflicting device as recored in + ** isa_device->id_unit + ** first_name: name of the device conflicted with as recorded in + ** isa_device->isa_driver->name + ** first_unit: unit number of device conflicted with as recored in + ** isa_device->id_unit + ** flags: OR of allowed types of conflict + ** + */ + #define MEM_CONFLICT 1 + #define IRQ_CONFLICT 2 + #define DRQ_CONFLICT 4 + #define IO_CONFLICT 8 + + struct known_conflict { + char *sec_name; /* second device probed for */ + int sec_unit; + char *first_name; /* first device found */ + int first_unit; + unsigned short type; + } + known_conflicts[] = { + + { "psm", 0, "sc", 0, IO_CONFLICT }, + { "snd", 6, "snd", 2, IO_CONFLICT | IRQ_CONFLICT }, + { (char *)0, 0, (char *)0, 0, 0 } + + }; From owner-freebsd-current Thu Apr 6 20:21:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA20454 for current-outgoing; Thu, 6 Apr 1995 20:21:31 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id UAA20448 for ; Thu, 6 Apr 1995 20:21:29 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (4.1/SMI-4.0) id AA19212; Thu, 6 Apr 95 23:21:25 EDT Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA05191; Thu, 6 Apr 95 23:19:23 EDT Date: Thu, 6 Apr 95 23:19:23 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9504070319.AA05191@borg.ess.harris.com> To: freebsd-current@freefall.cdrom.com Subject: net dropouts Sender: current-owner@FreeBSD.org Precedence: bulk I have been noticing slow connects and at times ppp drop outs for some time now. It only seems to happen when 2 freebsd machines are involved. If I use a sparc to get to a freebsd current I usually have no problems. However, if I telnet from one freebsd-current to another there is a good chance that I take the remote machines PPP connection that I am coming in on down :-( It usually gets as far as: Connected blah blah blah Escape character is '^]'. and thats all, the link is usually down now. Everything going out is fine as long as its not to a freebsd-current. Sooooo, has anyone else noticed this little feature? :-) Jim From owner-freebsd-current Thu Apr 6 20:39:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA20840 for current-outgoing; Thu, 6 Apr 1995 20:39:25 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA20834 for ; Thu, 6 Apr 1995 20:39:24 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id UAA27863; Thu, 6 Apr 1995 20:39:21 -0700 Date: Thu, 6 Apr 1995 20:39:17 -0700 From: Richard Chang To: FreeBSD-current@freefall.cdrom.com Subject: ppp still not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Somehow ppp is still not working under the latest -current. A few days ago, when I got ppp working, sup stopped working under both slip and ppp on April Fool's day then when sup worked with Justin Gibb's help of turning off sysctl, ppp no longer works anymore. When I attempt to telnet, it would just not even go through the modem and just say: bigbang# telnet csua.berkeley.edu Hostname lookup not found Slip and sup now works fine without sysctl on rfc1323 and rfc1644. I even compared my ppp setup with someone else at Berkeley and it's the same configuration so anyone have any ideas what's wrong? Thanks for any help. --richardc From owner-freebsd-current Thu Apr 6 22:20:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA23058 for current-outgoing; Thu, 6 Apr 1995 22:20:34 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA23052 for ; Thu, 6 Apr 1995 22:20:30 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id XAA06417; Thu, 6 Apr 1995 23:24:47 -0600 Date: Thu, 6 Apr 1995 23:24:47 -0600 Message-Id: <199504070524.XAA06417@trout.sri.MT.net> To: current@FreeBSD.org Subject: Announce: Linker changes which broke shared C++/F77 code backed out Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Due to some underlying dependance of the linker on the previous behavior, the change I made to enforce command line linking has been backed out. This should (hopefully?) fix the problems people were having with C++ programs. However, it should be noted that as it stands currently, if you define a symbol in a static library it will be preferred over the version that exists in a shared library, even if it precedes it on the link line. For example, if you link a program with against -lcompat(static by default) and -lgnuregex(shared by default), as the code is now the regex routines will be pulled from the static library and not the shared library since they both define symbols from regex and friends. I'm hoping to change this behavior, but in the mean-time be aware of this 'feature' of the linker, and if you see any weird behavior in your binaries or are concerned, you're best bet is to compile the program completely static which avoids these problems. On a not so positive note, this change doesn't appear to fix the problems folks are having with Lites. This seems to be a dependance on changes that were made to the run-time loader, and I'm hoping to track this whole mess down as time permits. Nate From owner-freebsd-current Thu Apr 6 23:10:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA24067 for current-outgoing; Thu, 6 Apr 1995 23:10:49 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA24061 for ; Thu, 6 Apr 1995 23:10:47 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0rx7FZ-000K0iC; Thu, 6 Apr 95 23:10 WET DST Message-Id: From: pete@pelican.com (Pete Carah) Subject: preprocessor conflict in proj.4 (geodesic.h) To: gie@charon.er.usgs.gov Date: Thu, 6 Apr 1995 23:10:33 -0700 (PDT) Cc: current@FreeBSD.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1445 Sender: current-owner@FreeBSD.org Precedence: bulk In freebsd (2.1 alpha) I had a serious problem with geodesic.h: it defines a and f; these are very common preprocessor arguments for other macros in system libraries. This causes ctype.h to fail. since f is a free argument to a bunch of macros, and GEODESIC.FLAT isn't a valid C identifier... I can see two ways around this - the easiest is to move the include of this to after all system include files. The best is to use underscores everywhere in either the system includes or your own; I don't know what the ansi committee has to say about this; my copy of "? & Steele" is put away and K&R don't get into this kind of detail. I'm cc'ing this to the freebsd group in case those dummy args should have underscores. The offending define is geodesic.h:# define f GEODESIC.FLAT ---------------------------------------------------------------- and lines in ctype.h: #if defined(_USE_CTYPE_INLINE_) static __inline int __istype(_BSD_RUNE_T_ c, unsigned long f) { if (c < 0) c = (unsigned char) c; return((((c & _CRMASK) ? ___runetype(c) : _CurrentRuneLocale->runetype[c]) & f) ? 1 : 0); } ------------------------------------------------------------------- For now I can probably get away with defining _USE_CTYPE_CLIBRARY_ to avoid these definitions. Jordan, Terry, Garrett? Is anyone familiar enough with the ANSI system-include rules to know if we (freebsd) have a problem here? -- Pete From owner-freebsd-current Thu Apr 6 23:16:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA24135 for current-outgoing; Thu, 6 Apr 1995 23:16:21 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA24129 for ; Thu, 6 Apr 1995 23:16:17 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0rx7Kx-000K0iC; Thu, 6 Apr 95 23:16 WET DST Message-Id: From: pete@pelican.com (Pete Carah) Subject: more ctype woes To: current@FreeBSD.org Date: Thu, 6 Apr 1995 23:16:06 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 462 Sender: current-owner@FreeBSD.org Precedence: bulk In reference to my problem with ctype - defining _USE_CTYPE_CLIBRARY_ fixed the compile problems and gave rise to: gcc -o geod geod.o geod_setup.o geod_forwd.o geod_invrs.o emess.o libproj.a -lm geod.o: Undefined symbol `___isctype' referenced from text segment gmake: *** [geod] Error 1 i.e. the relevant entry (there is a reference in libc.so to isctype.so but not ___isctype) isn't in the C library... I don't know who belongs to the rune code ... -- Pete From owner-freebsd-current Thu Apr 6 23:22:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA24243 for current-outgoing; Thu, 6 Apr 1995 23:22:54 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA24237 for ; Thu, 6 Apr 1995 23:22:52 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0rx7RB-000K0iC; Thu, 6 Apr 95 23:22 WET DST Message-Id: From: pete@pelican.com (Pete Carah) Subject: fix - don't know if it's the right thing To: gie@charon.er.usgs.gov, current@FreeBSD.org Date: Thu, 6 Apr 1995 23:22:32 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 393 Sender: current-owner@FreeBSD.org Precedence: bulk Since the CLIBRARY define didn't work, I bit the bullet and edited ctype.h to add a leading _ to all dummies. That worked and made proj and geod just fine. Hopefully it'll work with the 2.6.3 thing; I already ran into trouble with xv using -O and had to use no opt to make it work on nasa picture files. Don't know if this is the right thing but if it is, could someone commit it? -- Pete From owner-freebsd-current Thu Apr 6 23:34:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA24411 for current-outgoing; Thu, 6 Apr 1995 23:34:31 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA24404 ; Thu, 6 Apr 1995 23:34:30 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: pete@pelican.com (Pete Carah) cc: gie@charon.er.usgs.gov, current@FreeBSD.org Subject: Re: preprocessor conflict in proj.4 (geodesic.h) In-reply-to: Your message of "Thu, 06 Apr 95 23:10:33 PDT." Date: Thu, 06 Apr 1995 23:34:30 -0700 Message-ID: <24403.797236470@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I'm cc'ing this to the freebsd group in case those dummy args should > have underscores. > > The offending define is > geodesic.h:# define f GEODESIC.FLAT > ---------------------------------------------------------------- > and lines in ctype.h: > #if defined(_USE_CTYPE_INLINE_) > static __inline int > __istype(_BSD_RUNE_T_ c, unsigned long f) Yeah.. This isn't the first time this has come up. Last time, I prepended an undercore to all the macro argument names but I also seem to recall that Garrett screamed something at me about moving things from implementation space to frobutronic space, or something.. I can't remember. In any case, Garrett knows the right answer to this! I don't! Garrett? :-) Jordan From owner-freebsd-current Fri Apr 7 00:33:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA25241 for current-outgoing; Fri, 7 Apr 1995 00:33:42 -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 AAA25232 for ; Fri, 7 Apr 1995 00:33:38 -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 JAA00707 ; Fri, 7 Apr 1995 09:32:59 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id JAA01532 ; Fri, 7 Apr 1995 09:32:34 +0200 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.6.11/keltia-uucp-1.21) id WAA02147; Thu, 6 Apr 1995 22:00:15 +0200 From: Ollivier Robert Message-Id: <199504062000.WAA02147@keltia.frmug.fr.net> Subject: Re: Label/slices : how to add a disk ? To: bde@zeta.org.au (Bruce Evans) Date: Thu, 6 Apr 1995 22:00:14 +0200 (MET DST) Cc: current@FreeBSD.org, pete@pelican.com Reply-To: roberto@keltia.freenix.fr (Ollivier Robert) In-Reply-To: <199504061607.CAA26085@godzilla.zeta.org.au> from "Bruce Evans" at Apr 7, 95 02:07:45 am X-Operating-System: FreeBSD 2.1.0-Development ctm#514 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: 1125 Sender: current-owner@FreeBSD.org Precedence: bulk Thanks to all... After a few miss from me, it now works. The whole process is not really user-friendly though :-( Anyway, the drive is a Conner and it seems very fast : Excerpts from iozone 2.01 : 16 512 1927723 2982616 16 1024 2957966 4036623 16 2048 3969470 4455360 16 4096 4373693 4464622 16 8192 5100911 4464622 with a peek at 6.5 MB/s ! 8 512 1913978 2974354 8 1024 2949840 3976821 8 2048 3976821 4382619 8 4096 4628197 4418690 8 8192 6547206 4382619 Boy I'm happy... Thanks for giving us a system like FreeBSD. It keeps on amazing me. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.1.0-Development #13: Sun Apr 2 21:38:04 MET DST 1995 From owner-freebsd-current Fri Apr 7 01:59:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA28808 for current-outgoing; Fri, 7 Apr 1995 01:59:15 -0700 Received: from morton.cdrom.com (morton.cdrom.com [192.216.222.17]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA28798 for ; Fri, 7 Apr 1995 01:59:09 -0700 Received: (from jkh@localhost) by morton.cdrom.com (8.6.11/8.6.9) id BAA03743 for current@freefall; Fri, 7 Apr 1995 01:58:46 -0700 Date: Fri, 7 Apr 1995 01:58:46 -0700 From: "Jordan K. Hubbard" Message-Id: <199504070858.BAA03743@morton.cdrom.com> To: current@freefall.cdrom.com Subject: Argh! Another side-effect of Nate's changes? Sender: current-owner@FreeBSD.org Precedence: bulk Unpack the following somewhere and run driver, then driver.broken. The only difference between the two is that they're linked dynamic and static. I really *need* this example to work static! Can someone suggest anything? Is this outside the realm of possibility simply due to the way shared library symbol resolution works? You'd think that dlopen() would (should) work irrespective of the calling program's own link preference! Jordan # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # Makefile # driver.c # lib.c # echo x - Makefile sed 's/^X//' >Makefile << 'END-of-Makefile' Xall: lib.so driver.c X cc driver.c -g -O -o driver X cc -static driver.c -g -O -o driver.broken X Xlib.so: X cc -O -c -fpic lib.c X ld -Bshareable -o lib.so lib.o X Xclean: X rm -f *.o *.so driver driver.broken END-of-Makefile echo x - driver.c sed 's/^X//' >driver.c << 'END-of-driver.c' Xvoid Xfunky_chicken(char *arg) X{ X printf("C'mon and %s!\n", arg); X} X Xvoid Xsuicide(char *arg) X{ X printf("The end is nigh, so we %s.\n", arg); X} X Xmain(int ac, char **av) X{ X void *handle; X int (*ptr)(int, char **); X char *name; X X if (ac > 1) X name = av[1]; X else X name = "lib.so"; X printf("main: Loading %s:\n", name); X handle = (void *)dlopen(name); X if (!handle) { X printf("main: Load of %s failed!\n", name); X return -1; X } X else X printf("main: Load of %s successfull!\n", name); X ptr = (int (*)(int, char **))dlsym(handle, "_run"); X if (ptr) { X printf("main: Run entrypoint found for %s - invoking.\n", name); X (*ptr)(--ac, ++av); X } X printf("main: Shutting down handle for %s\n", name); X dlclose(handle); X printf("main: Terminating the program\n"); X return 0; X} END-of-driver.c echo x - lib.c sed 's/^X//' >lib.c << 'END-of-lib.c' X/* This modules init function */ Xvoid Xinit(void) X{ X printf("lib: I am alive!\n"); X funky_chicken("shout"); X funky_chicken("sing"); X funky_chicken("dance like a lunatic"); X} X Xint Xrun(int argc, char **argv) X{ X printf("lib: in run code, argc = %d\n", argc); X} X Xvoid Xfini(void) X{ X printf("lib: Aiua! I am dead!\n"); X suicide("dance the tango"); X suicide("curl up our legs like dying insects"); X} X END-of-lib.c exit From owner-freebsd-current Fri Apr 7 02:09:17 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA29396 for current-outgoing; Fri, 7 Apr 1995 02:09: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 CAA29385 for ; Fri, 7 Apr 1995 02:08:47 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA21424; Fri, 7 Apr 1995 19:06:39 +1000 Date: Fri, 7 Apr 1995 19:06:39 +1000 From: Bruce Evans Message-Id: <199504070906.TAA21424@godzilla.zeta.org.au> To: jkh@freefall.cdrom.com, pete@pelican.com Subject: Re: preprocessor conflict in proj.4 (geodesic.h) Cc: current@FreeBSD.org, gie@charon.er.usgs.gov Sender: current-owner@FreeBSD.org Precedence: bulk >> The offending define is >> geodesic.h:# define f GEODESIC.FLAT >> ---------------------------------------------------------------- >> and lines in ctype.h: >> #if defined(_USE_CTYPE_INLINE_) >> static __inline int >> __istype(_BSD_RUNE_T_ c, unsigned long f) >Yeah.. This isn't the first time this has come up. >Last time, I prepended an undercore to all the macro argument names >but I also seem to recall that Garrett screamed something at me about >moving things from implementation space to frobutronic space, >or something.. I can't remember. >In any case, Garrett knows the right answer to this! I don't! >Garrett? :-) Macro argument names don't need leading underscores. Only inline function arg names need leading underscores (one). has many other bugs. I have had fixes for them in my queue since December. The fixes are delayed waiting for similar fixes in . has many user names (e.g., `min' in structs) although it is otherwise careful about namespaces. Struct names don't need any protection from user variables but they can be clobbered by user macros. Bruce From owner-freebsd-current Fri Apr 7 02:20:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA29728 for current-outgoing; Fri, 7 Apr 1995 02:20:25 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA29716 for ; Fri, 7 Apr 1995 02:20:14 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id RAA19537; Fri, 7 Apr 1995 17:19:49 +0800 Date: Fri, 7 Apr 1995 17:19:48 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: PERL4&5 broken in -current and 950322-SNAP! In-Reply-To: <199504061442.IAA14940@trout.sri.MT.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk So perl5 is doing things correctly and it's our [v][s]printf that's broken? Should I send a followup to the Larry Wall? -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Fri Apr 7 02:23:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA29846 for current-outgoing; Fri, 7 Apr 1995 02:23:49 -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 CAA29837 for ; Fri, 7 Apr 1995 02:23:43 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id CAA07043; Fri, 7 Apr 1995 02:23:10 -0700 From: "Rodney W. Grimes" Message-Id: <199504070923.CAA07043@gndrsh.aac.dev.com> Subject: Re: Label/slices : how to add a disk ? To: roberto@keltia.freenix.fr Date: Fri, 7 Apr 1995 02:23:09 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: <199504062000.WAA02147@keltia.frmug.fr.net> from "Ollivier Robert" at Apr 6, 95 10:00:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2484 Sender: current-owner@FreeBSD.org Precedence: bulk > > Thanks to all... After a few miss from me, it now works. > > The whole process is not really user-friendly though :-( > > Anyway, the drive is a Conner and it seems very fast : > > Excerpts from iozone 2.01 : > > 16 512 1927723 2982616 > 16 1024 2957966 4036623 > 16 2048 3969470 4455360 > 16 4096 4373693 4464622 > 16 8192 5100911 4464622 > > with a peek at 6.5 MB/s ! > > 8 512 1913978 2974354 > 8 1024 2949840 3976821 > 8 2048 3976821 4382619 > 8 4096 4628197 4418690 > 8 8192 6547206 4382619 > > Boy I'm happy... Thanks for giving us a system like FreeBSD. It keeps on > amazing me. That is an amazing write speed!! How much memory is in this machine??? As a note to folks it really helps if you run one really long iozone job to find out about sustained transfer rate and to eliminate almost all of the buffer cache effects: (The 16MB limit on iozone auto is not high enough for 16MB machines, since the buffer cache can now get quite large). This is on a 16MB machine, P54C-90, NCR810 controller iozone 2.01: The buffer cache become ineffective at 8MB transfer size, but still skewed the numbers some (~200K/sec). 16 512 2681003 2725233 16 1024 2732167 2674325 16 2048 2721779 2704639 16 4096 2725233 2721779 16 8192 2739137 2749658 iozone 128 8192: IOZONE writes a 128 Megabyte sequential file consisting of 16384 records which are each 8192 bytes in length. It then reads the file. It prints the bytes-per-second rate at which the computer can read and write files. Writing the 128 Megabyte file, 'iozone.tmp'...53.343750 seconds Reading the file...51.906250 seconds IOZONE performance measurements: 2516090 bytes/second for writing the file 2585772 bytes/second for reading the file -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Fri Apr 7 02:30:05 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA00154 for current-outgoing; Fri, 7 Apr 1995 02:30:05 -0700 Received: from vinkku.hut.fi (root@vinkku.hut.fi [130.233.245.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA00134 for ; Fri, 7 Apr 1995 02:29:47 -0700 Received: from lk-hp-20.hut.fi (lk-hp-20.hut.fi [130.233.247.32]) by vinkku.hut.fi (8.6.11/8.6.7) with ESMTP id MAA17765 for ; Fri, 7 Apr 1995 12:29:14 +0300 From: Juha Inkari Received: (inkari@localhost) by lk-hp-20.hut.fi (8.6.11/8.6.7) id MAA26445 for current@freebsd.org; Fri, 7 Apr 1995 12:29:14 +0300 Message-Id: <199504070929.MAA26445@lk-hp-20.hut.fi> Subject: lib/libc/net/ether_addr.c doesnt see sys/netinet/if_ether.h To: current@FreeBSD.org Date: Fri, 7 Apr 1995 12:29:14 +0200 (EET DST) X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1392 Sender: current-owner@FreeBSD.org Precedence: bulk I have SNAP-0322 and just supper source tree. Now make breaks when compiling libc/net/ether_addr.c, because it needs for example ``struct ether_addr'' (in sys/netinet/if_ether.h), but for some reason, it does not get included. So, do I need to upgrade /usr/include somehow, or is there some other thing to configure ? ------- cc -v -DLIBC_RCS -DSYSLIBC_RCS -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/m/sd1a/src/lib/libc/locale -DYP -c /m/sd1a/src/lib/libc/net/ether_addr.c -o ether_addr.o gcc version 2.6.3 /usr/libexec/cpp -lang-c -v -I/m/sd1a/src/lib/libc/locale -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dunix -Di386 -D__FreeBSD__=2 -D__unix__ -D__i386__ -D__FreeBSD__=2 -D__unix -D__i386 -Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -DLIBC_RCS -DSYSLIBC_RCS -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -DYP /m/sd1a/src/lib/libc/net/ether_addr.c /var/tmp/cc004097.i GNU CPP version 2.6.3 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: /m/sd1a/src/lib/libc/locale /usr/include End of search list. /usr/libexec/cc1 /var/tmp/cc004097.i -quiet -dumpbase ether_addr.c -version -o /var/tmp/cc004097.s GNU C version 2.6.3 (80386, BSD syntax) compiled by GNU C version 2.6.3. /m/sd1a/src/lib/libc/net/ether_addr.c: In function `ether_line': /m/sd1a/src/lib/libc/net/ether_addr.c:80: dereferencing pointer to incomplete type ... ------- From owner-freebsd-current Fri Apr 7 02:33:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA00315 for current-outgoing; Fri, 7 Apr 1995 02:33:22 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA00308 for ; Fri, 7 Apr 1995 02:33:09 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id RAA19599; Fri, 7 Apr 1995 17:30:57 +0800 Date: Fri, 7 Apr 1995 17:30:56 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: man(1) bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk man in 950322-SNAP incorrectly handles a name argument that begins with a digit: % find /usr/local/man -name "[0-9]*" -print /usr/local/man/man3/3DBorder.3.gz % man 3DBorder What manual page do you want from section 3DBorder? % man -k 3dborder What manual page do you want from section 3dborder? % man 3 3DBorder % This appears to be unique to FreeBSD's man, as no other OS I could get my hands on had this bug (include BSD/OS 1.1 and 2.0). Related question: where is the source? I looked in the obvious srcubin.* series, but could not find it there. I then searched through all the others (except gnu.*, which is missing one segment at the local mirror) without success. -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Fri Apr 7 02:43:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA00807 for current-outgoing; Fri, 7 Apr 1995 02:43:42 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA00800 ; Fri, 7 Apr 1995 02:43:40 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: pete@pelican.com, current@FreeBSD.org, gie@charon.er.usgs.gov Subject: Re: preprocessor conflict in proj.4 (geodesic.h) In-reply-to: Your message of "Fri, 07 Apr 95 19:06:39 +1000." <199504070906.TAA21424@godzilla.zeta.org.au> Date: Fri, 07 Apr 1995 02:43:35 -0700 Message-ID: <798.797247815@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > Macro argument names don't need leading underscores. Only inline > function arg names need leading underscores (one). has many Argh. I didn't mean to say macros! I am reading and sending too much email. I think it's time to cut back.. :-) Jordan From owner-freebsd-current Fri Apr 7 05:38:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA05295 for current-outgoing; Fri, 7 Apr 1995 05:38:47 -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 FAA05284 for ; Fri, 7 Apr 1995 05:37:58 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA25471; Fri, 7 Apr 1995 22:35:35 +1000 Date: Fri, 7 Apr 1995 22:35:35 +1000 From: Bruce Evans Message-Id: <199504071235.WAA25471@godzilla.zeta.org.au> To: current@FreeBSD.org, pete@pelican.com Subject: Re: more ctype woes Sender: current-owner@FreeBSD.org Precedence: bulk >In reference to my problem with ctype - defining _USE_CTYPE_CLIBRARY_ >fixed the compile problems and gave rise to: >gcc -o geod geod.o geod_setup.o geod_forwd.o geod_invrs.o emess.o libproj.a -lm >geod.o: Undefined symbol `___isctype' referenced from text segment >gmake: *** [geod] Error 1 >i.e. the relevant entry (there is a reference in libc.so to isctype.so >but not ___isctype) isn't in the C library... I committed fixes for this a few minutes ago. ___isctype wasn't defined because libc/locale/nomacros.c didn't understand the convolutions in . It needed to define _USE_CTYPE_CLIBRARY_ to stop from declaring the inline versions and it shouldn't have tested either _USE_CTYPE_INLINE_ or _USE_CTYPE_MACROS_ to decide whether to generate code. I replaced _USE_CTYPE_CLIBRARY_ and _ANSI_LIBRARY by _EXTERNALIZE_CTYPE_INLINES_ and another layer of macros for toupper() and tolower(). Now all the ctype "functions" are implemented as macros (which usually expand to inline functions) so that both the library and applications can #undef them to work with the functions. Bruce From owner-freebsd-current Fri Apr 7 06:12:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA05866 for current-outgoing; Fri, 7 Apr 1995 06:12:43 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA05853 for ; Fri, 7 Apr 1995 06:12:20 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id UAA20480; Fri, 7 Apr 1995 20:51:33 +0800 Date: Fri, 7 Apr 1995 20:51:32 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: Label/slices : how to add a disk ? In-Reply-To: <199504070923.CAA07043@gndrsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Fri, 7 Apr 1995, Rodney W. Grimes wrote: > > This is on a 16MB machine, P54C-90, NCR810 controller iozone 2.01: The > buffer cache become ineffective at 8MB transfer size, but still skewed > the numbers some (~200K/sec). [...] > Writing the 128 Megabyte file, 'iozone.tmp'...53.343750 seconds > Reading the file...51.906250 seconds > > IOZONE performance measurements: > 2516090 bytes/second for writing the file > 2585772 bytes/second for reading the file How much CPU is being eaten on your machine while performing the benchmark? My machine is a PCI 486DX4/100 machine (16 megs) with the NCR53810 controller and a Quantum Empire 1080. iozone 2.01: IOZONE writes a 128 Megabyte sequential file consisting of 16384 records which are each 8192 bytes in length. It then reads the file. It prints the bytes-per-second rate at which the computer can read and write files. Writing the 128 Megabyte file, 'iozone.tmp'...44.750000 seconds Reading the file...43.953125 seconds IOZONE performance measurements: 2999278 bytes/second for writing the file 3053656 bytes/second for reading the file 'top' shows this (sometime during the latter half of the run): PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 20444 root 48 0 244K 424K run 0:41 51.76% 50.35% iozone Is this a reasonable figure? At 3000000 bytes/sec using 8192-byte blocks, the CPU is shuttling about 366 I/O operations a second or about 2.7 ms per operation. That sounds like "a lot of time" from a CPU's viewpoint, most of it spent waiting for the disk (I assume?). BTW, out of curiosity, if I do something like this: % time dd if=/dev/zero of=/dev/null bs=102400 count=10240 10240+0 records in 10240+0 records out 1048576000 bytes transferred in 30 secs (34952533 bytes/sec) 0.171u 28.688s 0:29.33 98.3% 56+529k 0+1io 0pf+0w ... just what am I measuring? CPU-to-RAM bandwidth? CPU-to-cache speed? Or nothing at all useful? :) -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Fri Apr 7 07:52:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA08859 for current-outgoing; Fri, 7 Apr 1995 07:52:06 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA08852 for ; Fri, 7 Apr 1995 07:52:02 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id IAA10404; Fri, 7 Apr 1995 08:56:06 -0600 Date: Fri, 7 Apr 1995 08:56:06 -0600 Message-Id: <199504071456.IAA10404@trout.sri.MT.net> To: "Jordan K. Hubbard" Cc: current@freefall.cdrom.com Subject: Re: Argh! Another side-effect of Nate's changes? In-Reply-To: <199504070858.BAA03743@morton.cdrom.com> References: <199504070858.BAA03743@morton.cdrom.com> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > Unpack the following somewhere and run driver, then driver.broken. This ain't my problem. It's broken on a 2.0R machine as well, and I'm not claiming responsibility of anything that far back. It's possible that it's a side-effect of the problems I've been seeing, but it also may be something that is not-yet complete in the dl*() functions. Nate From owner-freebsd-current Fri Apr 7 07:54:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA08889 for current-outgoing; Fri, 7 Apr 1995 07:54:32 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA08883 for ; Fri, 7 Apr 1995 07:54:26 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id IAA10407; Fri, 7 Apr 1995 08:58:28 -0600 Date: Fri, 7 Apr 1995 08:58:28 -0600 Message-Id: <199504071458.IAA10407@trout.sri.MT.net> To: Brian Tao Cc: FREEBSD-CURRENT-L Subject: Re: man(1) bug In-Reply-To: References: Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Brian Tao writes: > man in 950322-SNAP incorrectly handles a name argument that begins > with a digit: And also misses names like '[' which is a link to the test man-page. > This appears to be unique to FreeBSD's man, as no other OS I could > get my hands on had this bug (include BSD/OS 1.1 and 2.0). Correct, we use a version of man that slices/dices and does all sorts of neat things. > Related question: where is the source? I looked in the obvious > srcubin.* series, but could not find it there. I then searched > through all the others (except gnu.*, which is missing one segment at > the local mirror) without success. It's in /usr/src/gnu/usr.bin/man/*. Nate From owner-freebsd-current Fri Apr 7 08:40:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA09758 for current-outgoing; Fri, 7 Apr 1995 08:40:57 -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 IAA09752 for ; Fri, 7 Apr 1995 08:40:56 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA28754; Fri, 7 Apr 1995 11:40:51 -0400 Date: Fri, 7 Apr 1995 11:40:51 -0400 From: Garrett Wollman Message-Id: <9504071540.AA28754@halloran-eldar.lcs.mit.edu> To: nate@sneezy.sri.com (Nate Williams) Cc: "Jordan K. Hubbard" , current@freefall.cdrom.com Subject: Re: Argh! Another side-effect of Nate's changes? In-Reply-To: <199504071456.IAA10404@trout.sri.MT.net> References: <199504070858.BAA03743@morton.cdrom.com> <199504071456.IAA10404@trout.sri.MT.net> Sender: current-owner@FreeBSD.org Precedence: bulk < This ain't my problem. It's broken on a 2.0R machine as well, and I'm > not claiming responsibility of anything that far back. It's possible > that it's a side-effect of the problems I've been seeing, but it also > may be something that is not-yet complete in the dl*() functions. I think the problem is simply that static programs don't have the _DYNAMIC information necessary to do dynamic linking. Arguably, you don't want them to. -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 Fri Apr 7 09:11:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA10240 for current-outgoing; Fri, 7 Apr 1995 09:11: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 JAA10234 for ; Fri, 7 Apr 1995 09:11:27 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA28809; Fri, 7 Apr 1995 12:11:13 -0400 Date: Fri, 7 Apr 1995 12:11:13 -0400 From: Garrett Wollman Message-Id: <9504071611.AA28809@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: current@freefall.cdrom.com Subject: Re: Argh! Another side-effect of Nate's changes? In-Reply-To: <9504071540.AA28754@halloran-eldar.lcs.mit.edu> References: <199504070858.BAA03743@morton.cdrom.com> <199504071456.IAA10404@trout.sri.MT.net> <9504071540.AA28754@halloran-eldar.lcs.mit.edu> Sender: current-owner@FreeBSD.org Precedence: bulk < I think the problem is simply that static programs don't have the > _DYNAMIC information necessary to do dynamic linking. Arguably, you > don't want them to. Of course! You can't use dlopen() etc. in static programs because they are implemented in ld.so! (This is the same restriction as in SunOS.) I would be opposed to making crt0 map in ld.so for static programs just in case they decide to use dlopen() and friends. -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 Fri Apr 7 09:35:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA10989 for current-outgoing; Fri, 7 Apr 1995 09:35:38 -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 JAA10983 for ; Fri, 7 Apr 1995 09:35:34 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id JAA07710; Fri, 7 Apr 1995 09:34:47 -0700 From: "Rodney W. Grimes" Message-Id: <199504071634.JAA07710@gndrsh.aac.dev.com> Subject: Disk performance (was Re: Label/slices : how to add a disk ?) To: taob@gate.sinica.edu.tw (Brian Tao) Date: Fri, 7 Apr 1995 09:34:46 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Brian Tao" at Apr 7, 95 08:51:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3950 Sender: current-owner@FreeBSD.org Precedence: bulk > > On Fri, 7 Apr 1995, Rodney W. Grimes wrote: > > > > This is on a 16MB machine, P54C-90, NCR810 controller iozone 2.01: The > > buffer cache become ineffective at 8MB transfer size, but still skewed > > the numbers some (~200K/sec). Ooppss. left the drive model out, these tests where on a Micropolis 2112, 1Gbyte drive. > [...] > > Writing the 128 Megabyte file, 'iozone.tmp'...53.343750 seconds > > Reading the file...51.906250 seconds > > > > IOZONE performance measurements: > > 2516090 bytes/second for writing the file > > 2585772 bytes/second for reading the file > > How much CPU is being eaten on your machine while performing the > benchmark? My machine is a PCI 486DX4/100 machine (16 megs) with the > NCR53810 controller and a Quantum Empire 1080. iozone 2.01: > ... > > 'top' shows this (sometime during the latter half of the run): > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 20444 root 48 0 244K 424K run 0:41 51.76% 50.35% iozone I get the following stats using 3 different utilities (I was glad to see that thy agreed within reason!): [We are not comparing apples to apples here, I am running on a P54C-90, your tests where on a DX4/100] systat -vm processor mode line: 19.3%Sys 2.0%Intr 0.5%User 0.0%Nice 78.3%Idl time iozone 128 8192: 0.1u 20.8s 1:46.42 19.6% 30+285k 2237+16675io 0pf+0w top: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 138 root -6 0 248K 572K sleep 0:12 19.29% 18.46% iozone > Is this a reasonable figure? At 3000000 bytes/sec using 8192-byte > blocks, the CPU is shuttling about 366 I/O operations a second or > about 2.7 ms per operation. That sounds like "a lot of time" from a > CPU's viewpoint, most of it spent waiting for the disk (I assume?). You forgot that the CPU is not 100% busy. What that 2.7mS number relates to closest is the fact that 8192 bytes fly under the disk head in ~2.7mS. Your Quantum 1080 is a 5400 RPM (90 RPS) drive, meaning it takes 11.11mS for one revolution, turning a few more numbers through xcalc 2.7mS/11.11mS * (16 sectors per 8192 bytes)=65 sectors/revolution. I could check this if I had the number of cylinders reported by the probe (my Quantum data sheet only shows total sectors and # of heads), but I suspect that the average sectors/track is very close to 65 for this drive. > > BTW, out of curiosity, if I do something like this: > > % time dd if=/dev/zero of=/dev/null bs=102400 count=10240 > 10240+0 records in > 10240+0 records out > 1048576000 bytes transferred in 30 secs (34952533 bytes/sec) > 0.171u 28.688s 0:29.33 98.3% 56+529k 0+1io 0pf+0w > > ... just what am I measuring? CPU-to-RAM bandwidth? CPU-to-cache > speed? Or nothing at all useful? :) It is hard to be sure exactly what is being measure here, It is a combination of bzero speed, RAM -> CPU and CPU <-> cache bandwidths. If you think about every step along the way you could figure it out. Here are a few of the steps. a) bzero the 10k input buffer from /dev/zero. b) either page flip or copy out the buffer to user space c) copy the input buffer to the output buffer (reads here are probably pure cache hit, the writes may or may not be in the cache). d) Call the kernel to do the output to /dev/null, no copy occurs here, the fp is just advanced. I tried to correlate the number with a memory benchmark program on my system and it comes up to be faster than the CPU -> main memory write bandwidth but about 1/2 the speed of main memory read bandwidth. Using a 512k bs pushed the speed up a bit and makes sure we trash my 256K cache, so I suspect the number is a combination of memory read and write bandwidth, with memory write bandwidth having a very heavy factor. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Fri Apr 7 10:18:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA11802 for current-outgoing; Fri, 7 Apr 1995 10:18:38 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA11795 for ; Fri, 7 Apr 1995 10:18:37 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA20480; Fri, 7 Apr 95 11:10:31 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504071710.AA20480@cs.weber.edu> Subject: Re: preprocessor conflict in proj.4 (geodesic.h) To: pete@pelican.com (Pete Carah) Date: Fri, 7 Apr 95 11:10:30 MDT Cc: gie@charon.er.usgs.gov, current@FreeBSD.org In-Reply-To: from "Pete Carah" at Apr 6, 95 11:10:33 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk I'm only answering this because you singled me out. I think there is not a hard and fast rule to fix this, but I can give you my opinions. > I'm cc'ing this to the freebsd group in case those dummy args should > have underscores. I don't think they should; they're not in the implementation name space. On the other hand, I think defining single letters might be allowed, but it is critically bad practice. I also think that #define arguments should not be subject to preprocesser substitution (I can't see a useful case where this would make something work where it didn't before). It's also generic bad practice to have manifest defines define anything but all uppercase tokens. So in order, I'd probably: 1) Change the #define in geodesic.h to define an upper case value. 2) Get rid of the ' ' between '#' and 'define' (I'm a nut for making code work on the oldest compiler I can get to crawl). 3) Change the 'F' (that used to be 'f') into something a bit more, shall we say, descriptive. 4) Move the inline function out of the standard header file into a tool or system specific header file that's pulled in by ctype.h. 5) Wonder what a type (_BSD_RUNE_T_) is doing in the implementation name space. 6) If it were more than 5 places, send the patches back to the maintainer so thenext time I tried to run the code I didn't have to fix the same thing over again. 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 Apr 7 14:20:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA20104 for current-outgoing; Fri, 7 Apr 1995 14:20:25 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA20098 for ; Fri, 7 Apr 1995 14:20:24 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id OAA22611; Fri, 7 Apr 1995 14:20:20 -0700 Date: Fri, 7 Apr 1995 14:20:17 -0700 From: Richard Chang To: FreeBSD-current@freefall.cdrom.com Subject: ppp still not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Somehow ppp is still not working under the latest -current. A few days ago, when I got ppp working, sup stopped working under both slip and ppp on April Fool's day then when sup worked with Justin Gibb's help of turning off sysctl, ppp no longer works anymore. When I attempt to telnet, it would just not even go through the modem and just say: bigbang# telnet csua.berkeley.edu Hostname lookup not found Slip and sup now works fine without sysctl on rfc1323 and rfc1644. I even compared my ppp setup with someone else at Berkeley and it's the same configuration so anyone have any ideas what's wrong? Thanks for any help. --richardc From owner-freebsd-current Fri Apr 7 14:29:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA20296 for current-outgoing; Fri, 7 Apr 1995 14:29:45 -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 OAA20290 for ; Fri, 7 Apr 1995 14:29:42 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id OAA08492; Fri, 7 Apr 1995 14:29:21 -0700 From: "Rodney W. Grimes" Message-Id: <199504072129.OAA08492@gndrsh.aac.dev.com> Subject: Re: ppp still not working To: richardc@CSUA.Berkeley.EDU (Richard Chang) Date: Fri, 7 Apr 1995 14:29:20 -0700 (PDT) Cc: FreeBSD-current@freefall.cdrom.com In-Reply-To: from "Richard Chang" at Apr 7, 95 02:20:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1095 Sender: current-owner@FreeBSD.org Precedence: bulk > > > Somehow ppp is still not working under the latest -current. A > few days ago, when I got ppp working, sup stopped working under both slip > and ppp on April Fool's day then when sup worked with Justin Gibb's help > of turning off sysctl, ppp no longer works anymore. When I attempt to > telnet, it would just not even go through the modem and just say: > > bigbang# telnet csua.berkeley.edu > Hostname lookup not found > > Slip and sup now works fine without sysctl on rfc1323 and > rfc1644. I even compared my ppp setup with someone else at Berkeley and > it's the same configuration so anyone have any ideas what's wrong? > Thanks for any help. Would someone who is running ppp on FreeBSD-current help Richard out, this is the 3rd posting from him about his problem and no one has responeded to him. I would help but I am not running SLIP or PPP on -current (all my -current boxes are on ethernet). > --richardc -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Fri Apr 7 14:30:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA20315 for current-outgoing; Fri, 7 Apr 1995 14:30:21 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA20308 ; Fri, 7 Apr 1995 14:30:19 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Garrett Wollman cc: nate@sneezy.sri.com (Nate Williams), "Jordan K. Hubbard" , current@freefall.cdrom.com, pk@sun-lamp.cs.berkeley.edu Subject: Re: Argh! Another side-effect of Nate's changes? In-reply-to: Your message of "Fri, 07 Apr 95 11:40:51 EDT." <9504071540.AA28754@halloran-eldar.lcs.mit.edu> Date: Fri, 07 Apr 1995 14:30:19 -0700 Message-ID: <20307.797290219@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I think the problem is simply that static programs don't have the > _DYNAMIC information necessary to do dynamic linking. Arguably, you > don't want them to. Arguably, perhaps (and this is what I figured the case probably was). But it still remains the case that dlopen() and friends then remain caller-specific. You can't use them if the caller is static, only dynamic. At the very least this should be *documented* since the naturally tendency of the reader is then going to be to assume that dlopen() is just another call like "strcpy" or something - something that ANY program can call, be it static or dynamic. Jordan From owner-freebsd-current Fri Apr 7 22:24:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA29642 for current-outgoing; Fri, 7 Apr 1995 22:24:30 -0700 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA29636 for ; Fri, 7 Apr 1995 22:24:28 -0700 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.11/8.6.9) with SMTP id WAA01620 for ; Fri, 7 Apr 1995 22:24:27 -0700 Message-Id: <199504080524.WAA01620@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: current@FreeBSD.org Subject: Passing flags to PCI devices Date: Fri, 07 Apr 1995 22:24:27 -0700 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk What is the method for accessing device flags (like the floppy tape driver's enable flag) in the PCI driver case? It doesn't look like PCI devices can have flags, but then maybe I'm not looking in the right place. I'd really like to make tagged queuing a flag instead of a kernel option, but I need to do it for all the busses that the driver supports. Thanks, __ Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Fri Apr 7 22:49:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA00697 for current-outgoing; Fri, 7 Apr 1995 22:49:56 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA00691 for ; Fri, 7 Apr 1995 22:49:55 -0700 Received: from ast.com by relay3.UU.NET with SMTP id QQyknn01452; Sat, 8 Apr 1995 01:49:52 -0400 Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA01440 (5.67b/IDA-1.5 for uunet!freebsd.org!freebsd-current); Fri, 7 Apr 1995 22:53:58 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Sat, 8 Apr 95 00:49 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #18) id m0rxTBl-0004vsC; Sat, 8 Apr 95 00:36 CDT Message-Id: Date: Sat, 8 Apr 95 00:36 CDT To: freebsd-current@FreeBSD.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Reply-To: uhclem%nemesis@fw.ast.com Sent: Sat Apr 8 1995, 00:36:04 CDT Subject: New version of Matsushita/Panasonic driver Cc: uhclem@nemesis.lonestar.org Sender: current-owner@FreeBSD.org Precedence: bulk A new driver for the Matsushita/Panasonic proprietary interface drives has been uploaded to freefall.cdrom.com. This is version 1(16). This version fixes a couple of bugs located since the driver first appeared in FreeBSD -current a month ago. It also adds the remaining audio and TOC ioctls that keep xcd and xcdplayer (and some versions of cdplayer) from running. It compiles -Wall with no warnings under 2.x and will still compile and run under 1.1.5.1. Some new devs have been added that lock the media in the drives while the devices on a drive are open that can be used in environments where the born-button-pushers live or where discs tend to walk off. :-) There is also a man page (matcd.4). This should take care of all outstanding problems/complaints. The MAX data transfer rate under 2.x is still under 190K/sec, while the same code, disc and system gives just over 302K/sec under 1.1.5.1. This is a 2.x kernel issue that still exists. If there are any other problems, please let me know. Frank Durda IV |"The federal agents are exposing or uhclem%nemesis@trsvax.ast.com (Internet)| themselves to the outer ...letni!rwsys!nemesis!uhclem | atmosphere." (Bet that stings!) ...decvax!trsvax.fw.ast.com!nemesis!uhclem | - Real quote from KXAS reporter From owner-freebsd-current Sat Apr 8 00:02:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA02059 for current-outgoing; Sat, 8 Apr 1995 00:02:32 -0700 Received: from kbrown.oldcampus.yale.edu (root@kbrown.oldcampus.yale.edu [130.132.128.124]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA02053 for ; Sat, 8 Apr 1995 00:02:31 -0700 Date: Sat, 8 Apr 1995 03:01:54 -0400 (EDT) From: -Vince- To: FreeBSD-current@freefall.cdrom.com Subject: backspace key doesn't work in X Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Just wanted to report that the backspace key would just generate ^H on the screen for all TCP/IP Clients and not work correctly under X... Anyone know how to fix this? Cheers, Vince -*vince@kbrown.oldcampus.yale.edu*- UCLA Physics/Electrical Engineering From owner-freebsd-current Sat Apr 8 00:13:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA02329 for current-outgoing; Sat, 8 Apr 1995 00:13:03 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA02263 for ; Sat, 8 Apr 1995 00:12:09 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id OAA00890; Sat, 8 Apr 1995 14:50:20 +0800 Date: Sat, 8 Apr 1995 14:50:19 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: Disk performance In-Reply-To: <199504071634.JAA07710@gndrsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Fri, 7 Apr 1995, Rodney W. Grimes wrote: > > > 'top' shows this (sometime during the latter half of the run): > > > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > > 20444 root 48 0 244K 424K run 0:41 51.76% 50.35% iozone > > I get the following stats using 3 different utilities (I was glad to > see that thy agreed within reason!): [We are not comparing apples to > apples here, I am running on a P54C-90, your tests where on a DX4/100] > > systat -vm processor mode line: > 19.3%Sys 2.0%Intr 0.5%User 0.0%Nice 78.3%Idl I asked because the P90 (the one with those twin Maverick drives) peaks at less than 10% CPU, but of course it can barely manage 1.3MB/sec with iozone so the CPU is idle 90% of the time. Thus my initial reaction to the 50% figure above was "too high", and so: > > Is this a reasonable figure? > > You forgot that the CPU is not 100% busy. My feeling is that it should have been lower and not anywhere close to 100% usage. Sending out 366 I/O requests to a SCSI device and waiting for them to return did not seem to warrant a 50% busy state with a 100-MHz processor on a 33-MHz bus. I gather this is where IDE drives fare much worse? > What that 2.7mS number > relates to closest is the fact that 8192 bytes fly under the disk head > in ~2.7mS. Your Quantum 1080 is a 5400 RPM (90 RPS) drive, meaning > it takes 11.11mS for one revolution, turning a few more numbers through > xcalc 2.7mS/11.11mS * (16 sectors per 8192 bytes)=65 sectors/revolution. You mean 11.11/2.7, but I get your point. Quantum's data sheet for the Empire 1080 shows 64 to 107 sectors per track. I tested it on my sd0g partition which is located between cylinders 467 to 862 (out of 1017). The iozone file is probably located along the inner half of that cylinder group, given that the filesystem is over half ful now. So given the overheard in iozone and other little errors, 65 sectors/track is pretty good guess. BTW, is the best place for a swap partition along the outer edge of the disk where there are more sectors/track, or are there other factors (e.g., disk head seeking between swap and ufs partitions)? Does it really make much difference with only one spindle to swap on? > > % time dd if=/dev/zero of=/dev/null bs=102400 count=10240 > > It is hard to be sure exactly what is being measure here, It is > a combination of bzero speed, RAM -> CPU and CPU <-> cache bandwidths. [...] > I tried to correlate the number with a memory benchmark program on > my system and it comes up to be faster than the CPU -> main memory > write bandwidth but about 1/2 the speed of main memory read bandwidth. The P90 gets roughly the same benchmark (if you could call it that) as both the DX4/100 and DX2/66, about 33MB/sec. The Sparc1 upstairs gets 13.3MB/sec but the SGI Crimson next door gets something like 128MB/sec. Probably not much more useful on its own than any other benchmark. -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sat Apr 8 00:24:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA03137 for current-outgoing; Sat, 8 Apr 1995 00:24:37 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA03126 ; Sat, 8 Apr 1995 00:24:36 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: ache@astral.msk.su, freebsd-current@freefall.cdrom.com, rgrimes@gndrsh.aac.dev.com Subject: Re: Strange kernel printf... In-reply-to: Your message of "Thu, 06 Apr 95 21:05:16 +1000." <199504061105.VAA18008@godzilla.zeta.org.au> Date: Sat, 08 Apr 1995 00:24:32 -0700 Message-ID: <3115.797325872@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > Although repeating the device lines is a hack, its syntax is simpler and > exactly matches the data structures that should be built, at least in > ioconf.c (you wouldn't want variable length arrays or linked lists). Hmmmmm. Mumble. OK. > I don't like this. Conflicts need to be resolved at runtime. The > static conflict checking code in isa.c should go away and be replaced > by calls such as > > register_iobase(iobase, iosize, id, flags); > > There should be flags for exclusive access and for preventing exclusive > access by other drivers. OK, that sounds more reasonable - I was just looking for a relatively quick fix with my other proposal.. :) So, my original question remains: Is this something we're going to actually do, or are we prepared to live with config in all of its fetid glory for the forseeable future? Jordan From owner-freebsd-current Sat Apr 8 00:36:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA04039 for current-outgoing; Sat, 8 Apr 1995 00:36: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 AAA04026 for ; Sat, 8 Apr 1995 00:36:37 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id AAA14324; Sat, 8 Apr 1995 00:35:37 -0700 From: "Rodney W. Grimes" Message-Id: <199504080735.AAA14324@gndrsh.aac.dev.com> Subject: Re: Disk performance To: taob@gate.sinica.edu.tw (Brian Tao) Date: Sat, 8 Apr 1995 00:35:36 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Brian Tao" at Apr 8, 95 02:50:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5301 Sender: current-owner@FreeBSD.org Precedence: bulk > > On Fri, 7 Apr 1995, Rodney W. Grimes wrote: > > > > > 'top' shows this (sometime during the latter half of the run): > > > > > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > > > 20444 root 48 0 244K 424K run 0:41 51.76% 50.35% iozone > > > > I get the following stats using 3 different utilities (I was glad to > > see that thy agreed within reason!): [We are not comparing apples to > > apples here, I am running on a P54C-90, your tests where on a DX4/100] > > > > systat -vm processor mode line: > > 19.3%Sys 2.0%Intr 0.5%User 0.0%Nice 78.3%Idl > > I asked because the P90 (the one with those twin Maverick drives) > peaks at less than 10% CPU, but of course it can barely manage > 1.3MB/sec with iozone so the CPU is idle 90% of the time. Thus my > initial reaction to the 50% figure above was "too high", and so: I tend to agree that it does look a little high. But remeber we still have to bcopy the bytes between user land and the kernel, which well be somewhat slower on the 486 class of machines due to the data path width to memory. (It does not scale 2X like you think it would, it seems the memory desiges in Pentium systems leave a little to be desired :-(). > > > Is this a reasonable figure? Probabaly, it's with in reason, but could be better. > > You forgot that the CPU is not 100% busy. > > My feeling is that it should have been lower and not anywhere > close to 100% usage. Sending out 366 I/O requests to a SCSI device > and waiting for them to return did not seem to warrant a 50% busy > state with a 100-MHz processor on a 33-MHz bus. I gather this is > where IDE drives fare much worse? Yes, IDE drives load the cpu down far more, as they not only have to bcopy the bytes to and from user land, they also have to bcopy them to and from the disk. The scsi systems win here because the transfers between the disk and main memory are all done by the scsi adapter (well, at least for bus mastered scsi adapters). > > What that 2.7mS number > > relates to closest is the fact that 8192 bytes fly under the disk head > > in ~2.7mS. Your Quantum 1080 is a 5400 RPM (90 RPS) drive, meaning > > it takes 11.11mS for one revolution, turning a few more numbers through > > xcalc 2.7mS/11.11mS * (16 sectors per 8192 bytes)=65 sectors/revolution. > > You mean 11.11/2.7, but I get your point. Quantum's data sheet Ooopss, your right, I flipped the time values when I wrote it above, it was done in xcalc correctly though. > for the Empire 1080 shows 64 to 107 sectors per track. I tested it > on my sd0g partition which is located between cylinders 467 to 862 > (out of 1017). The iozone file is probably located along the inner > half of that cylinder group, given that the filesystem is over half > ful now. So given the overheard in iozone and other little errors, 65 > sectors/track is pretty good guess. :-), just bloody amazing!!! Wish I had a little chunk of code to read the notch page for that drive so I could find out just how close I really was! > BTW, is the best place for a swap partition along the outer edge > of the disk where there are more sectors/track, or are there other > factors (e.g., disk head seeking between swap and ufs partitions)? Historically the seek time was the dominant factor, but now with seeks times and rotational delays getting all to close togeather it's all becoming muddy. I tend to try and locate my swap area on boot disks between / and /usr since these are the most active file systems for that disk. > Does it really make much difference with only one spindle to swap on? Probably not much, though you don't want to locate it far away from the most active area of the disk, IMHO. > > > % time dd if=/dev/zero of=/dev/null bs=102400 count=10240 > > > > It is hard to be sure exactly what is being measure here, It is > > a combination of bzero speed, RAM -> CPU and CPU <-> cache bandwidths. > [...] > > I tried to correlate the number with a memory benchmark program on > > my system and it comes up to be faster than the CPU -> main memory > > write bandwidth but about 1/2 the speed of main memory read bandwidth. > > The P90 gets roughly the same benchmark (if you could call it > that) as both the DX4/100 and DX2/66, about 33MB/sec. The Sparc1 > upstairs gets 13.3MB/sec but the SGI Crimson next door gets something > like 128MB/sec. Probably not much more useful on its own than any > other benchmark. Especially with out detailed information about how the kernel implements the buffer copies to and from user land. I'm pretty sure the SGI boxes use page flipping, and I know the SGI machines have very fast memory systems in them from other tests. AHh.. just ask phk@FreeBSD.org why the sun's are so bloody slow. Most 486 machines can outperform SS1000 :-). I expect to be able towards the end of next week show some really amazing numbers on a Pentium system with respect to memory speeds. Let's all hope that the new EDO and Pipelined Burst SRAM stand up to the theories and we start to see 100++MB/sec main memory speeds on a Pentium like we should. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 02:33:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA08279 for current-outgoing; Sat, 8 Apr 1995 02:33:48 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA08272 for ; Sat, 8 Apr 1995 02:33:45 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id RAA01115; Sat, 8 Apr 1995 17:34:05 +0800 Date: Sat, 8 Apr 1995 17:34:02 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: Disk performance In-Reply-To: <199504080735.AAA14324@gndrsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sat, 8 Apr 1995, Rodney W. Grimes wrote: > > I tend to agree that it does look a little high. But remeber we still > have to bcopy the bytes between user land and the kernel, which well > be somewhat slower on the 486 class of machines due to the data path > width to memory. (It does not scale 2X like you think it would, it seems > the memory desiges in Pentium systems leave a little to be desired :-(). Then you have some people who think PCI is a load of crock and think we should have stuck with VME instead. Note that my lack of knowledge of bus architectures does not permit me to hold an opinion either way, so flames will be cheerfully ignored. ;-) > Yes, IDE drives load the cpu down far more, as they not only have to > bcopy the bytes to and from user land, they also have to bcopy them > to and from the disk. I presume that EIDE drives and drivers that support DMA wouldn't suffer from this particular deficiency then. Sorry, I don't mean to pick your brains in public like this. I hope someone else is learning the basics of disk transfer too. :) > > Does it really make much difference with only one spindle to swap on? > > Probably not much, though you don't want to locate it far away from > the most active area of the disk, IMHO. I suppose not, especially when these systems I have usually don't need to touch swap. I remember laughing at someone a few years back because he wanted to buy a separate 100-meg drive for his NeXT as additional swap space. Now it seems like a perfectly reasonable thing to do. :-/ :) > Especially with out detailed information about how the kernel implements > the buffer copies to and from user land. I'm pretty sure the SGI boxes > use page flipping, Hmmm, the only page flipping I know of is a double-buffered animation technique used on the Apple II hi-res graphics screen. :) > systems in them from other tests. AHh.. just ask phk@FreeBSD.org why > the sun's are so bloody slow. Most 486 machines can outperform SS1000 :-). Indeed: % sunmodel Machine gate: 'SPARCsystem 600MP (4 X 390Z55)' '(Model 541)' @ 50.0 MHz, GX % uname -a SunOS gate 5.3 Generic_Patch sun4m sparc % uptime 5:11pm up 5 day(s), 7:07, 9 users, load average: 1.36, 1.29, 1.38 % time dd if=/dev/zero of=/dev/null bs=102400 count=10240 10240+0 records in 10240+0 records out 0.63u 34.44s 0:35.25 99.4% About 5MB/sec slower than the 486's. A damn waste of CPU too... all I see people do on that machine is read news and mail. :( > I expect to be able towards the end of next week show some really > amazing numbers on a Pentium system with respect to memory speeds. > Let's all hope that the new EDO and Pipelined Burst SRAM stand up > to the theories and we start to see 100++MB/sec main memory speeds on > a Pentium like we should. Wow!!! -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sat Apr 8 02:53:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA09004 for current-outgoing; Sat, 8 Apr 1995 02:53:18 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA08998 for ; Sat, 8 Apr 1995 02:53:17 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id CAA21374; Sat, 8 Apr 1995 02:53:04 -0700 From: Poul-Henning Kamp Message-Id: <199504080953.CAA21374@ref.tfs.com> Subject: Re: Disk performance To: taob@gate.sinica.edu.tw (Brian Tao) Date: Sat, 8 Apr 1995 02:53:03 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Brian Tao" at Apr 8, 95 05:34:02 pm Content-Type: text Content-Length: 499 Sender: current-owner@FreeBSD.org Precedence: bulk Just to remind you how far we have got: Seagate ST506, 20Mb "BIOS Type 2" disk: dd if=/dev/rwd0d of=/dev/null bs=8k count=200 200+0 records in 200+0 records out 1638400 bytes transferred in 10 secs (163840 bytes/sec) Imprimis(?) 94186-383 ESDI disk: dd if=/dev/rwd2d of=/dev/null bs=8k count=400 400+0 records in 400+0 records out 3276800 bytes transferred in 8 secs (409600 bytes/sec) And yes, I have now finally some HW where I can attempt to make bad144 work again ;-) Poul-Henning From owner-freebsd-current Sat Apr 8 03:06:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA09320 for current-outgoing; Sat, 8 Apr 1995 03:06:31 -0700 Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id DAA09311 for ; Sat, 8 Apr 1995 03:06:26 -0700 Received: from rks32.pcs.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA12671; Sat, 8 Apr 95 03:03:54 -0700 Received: by rks32.pcs.dec.com (Smail3.1.27.1 #16) id m0rxXKc-0005OqC; Sat, 8 Apr 95 12:01 MSZ Message-Id: Date: Sat, 8 Apr 95 12:01 MSZ From: garyj@rks32.pcs.dec.com (Gary Jennejohn) To: current%freebsd.org@inet-gw-1.pa.dec.com Subject: Re: Disk performance Sender: current-owner@FreeBSD.org Precedence: bulk This is actually more about MB performance. Rodney Grimes wrote: >> I expect to be able towards the end of next week show some really >> amazing numbers on a Pentium system with respect to memory speeds. >> Let's all hope that the new EDO and Pipelined Burst SRAM stand up >> to the theories and we start to see 100++MB/sec main memory speeds on >> a Pentium like we should. c't magazine ran a series of tests on the latest crop of PCI MBs lately. Here are some of the results: ASUS PCI/I-P54TP4 (Triton chipset) with 256kB burst SRAM and 16 MB EDO main mem. 1st level cache: 407 MB/sec 2nd level cache: 65 MB/sec Main mem: 39 MB/sec The same MB without 2nd level cache but 16 MB EDO main mem. 1st level cache: 391 MB/sec 2nd level cache: N/A Main mem: 44 MB/sec This board is actually faster w/o the 2nd level cache when EDO RAM is used ! This was the fastet of all (6) configurations tested. The memmory transfer speeds were tested using some DOS utility developed by c't. Performance might look different under FBSD. They tested a whole slew of other things (SCSI, tranfers to a graphics card, etc.), but it's too much to copy. There's still a ways to go to achieve 100++MB/sec to main mem. Gary J. From owner-freebsd-current Sat Apr 8 03:28:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA09662 for current-outgoing; Sat, 8 Apr 1995 03:28:53 -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 DAA09650 for ; Sat, 8 Apr 1995 03:27:36 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA24575; Sat, 8 Apr 1995 20:21:11 +1000 Date: Sat, 8 Apr 1995 20:21:11 +1000 From: Bruce Evans Message-Id: <199504081021.UAA24575@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, taob@gate.sinica.edu.tw Subject: Re: Disk performance Sender: current-owner@FreeBSD.org Precedence: bulk > My feeling is that it should have been lower and not anywhere >close to 100% usage. Sending out 366 I/O requests to a SCSI device >and waiting for them to return did not seem to warrant a 50% busy >state with a 100-MHz processor on a 33-MHz bus. I gather this is >where IDE drives fare much worse? Actually only 366/8 i/o requests are sent to SCSI devices. Iozone does huge sequential i/o's on which clustering works perfectly, so file data is always read and written 64K at a time (not 8K for a file system with a block size of 8K). Normal file accesses aren't as sequential as for iozone, so clustering doesn't work so well. Normal file accesses are often 8 times as slow as for iozone for this and other reasons (seeking...) :-(. For IDE, drives, sending out 366/8 I/O requests is much faster, but "waiting" for them to return actually requires handling up to 366*16 interrupts (one for each sector) and copying 512 bytes or more per interrupt. Interrupt overhead is about 5usec/interrupt on a P90 and copying overhead is about 155usec/sector for the old IDE interface on all systems. Bruce From owner-freebsd-current Sat Apr 8 03:53:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA09870 for current-outgoing; Sat, 8 Apr 1995 03:53:40 -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 DAA09858 for ; Sat, 8 Apr 1995 03:53:36 -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 MAA15848 ; Sat, 8 Apr 1995 12:53:56 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id MAA20746 ; Sat, 8 Apr 1995 12:53:20 +0200 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.6.11/keltia-uucp-1.21) id XAA04506; Fri, 7 Apr 1995 23:49:15 +0200 From: Ollivier Robert Message-Id: <199504072149.XAA04506@keltia.frmug.fr.net> Subject: Re: Label/slices : how to add a disk ? To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Fri, 7 Apr 1995 23:49:14 +0200 (MET DST) Cc: freebsd-current@FreeBSD.org (FreeBSD Current Users' list) Reply-To: roberto@keltia.freenix.fr (Ollivier Robert) In-Reply-To: <199504070923.CAA07043@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Apr 7, 95 02:23:09 am X-Operating-System: FreeBSD 2.1.0-Development ctm#514 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: 2343 Sender: current-owner@FreeBSD.org Precedence: bulk It seems that Rodney W. Grimes said: > How much memory is in this machine??? As a note to folks it really 20 MB. 2.1-not-so-current. FreeBSD keltia 2.1.0-Development FreeBSD 2.1.0-Development #13: Sun Apr 2 21:38:04 MET DST 1995 roberto@keltia:/spare/usr/src/sys/compile/KELTIA i386 > This is on a 16MB machine, P54C-90, NCR810 controller iozone 2.01: The > buffer cache become ineffective at 8MB transfer size, but still skewed > the numbers some (~200K/sec). I'm sorry for your P90 machine. This is a 486DX-33. It uses a BT-747S EISA controller. The Conner 1080S gives me that with iozone 2.01 : 204 [18:15] root@keltia:/mnt# ~/Src/C/iozone_2.01/iozone 128 8192 IOZONE: Performance Test of Sequential File I/O -- V2.01 (10/21/94) By Bill Norcott Operating System: FreeBSD 2.1 - fsync Send comments to: b_norcott@xway.com IOZONE writes a 128 Megabyte sequential file consisting of 16384 records which are each 8192 bytes in length. It then reads the file. It prints the bytes-per-second rate at which the computer can read and write files. Writing the 128 Megabyte file, 'iozone.tmp'...30.125000 seconds Reading the file...30.554688 seconds IOZONE performance measurements: 4455360 bytes/second for writing the file 4392704 bytes/second for reading the file Even the 128 512 iozone result is amazing : 206 [18:22] root@keltia:/mnt# ~/Src/C/iozone_2.01/iozone 128 512 IOZONE: Performance Test of Sequential File I/O -- V2.01 (10/21/94) By Bill Norcott Operating System: FreeBSD 2.1 - fsync Send comments to: b_norcott@xway.com IOZONE writes a 128 Megabyte sequential file consisting of 262144 records which are each 512 bytes in length. It then reads the file. It prints the bytes-per-second rate at which the computer can read and write files. Writing the 128 Megabyte file, 'iozone.tmp'...86.078125 seconds Reading the file...48.976562 seconds IOZONE performance measurements: 1559254 bytes/second for writing the file 2740448 bytes/second for reading the file -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.1.0-Development #13: Sun Apr 2 21:38:04 MET DST 1995 From owner-freebsd-current Sat Apr 8 04:10:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA12848 for current-outgoing; Sat, 8 Apr 1995 04:10:12 -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 EAA12836 for ; Sat, 8 Apr 1995 04:09:58 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA09377; Sat, 8 Apr 1995 13:09:52 +0200 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id NAA28586 for freebsd-current@FreeBSD.org; Sat, 8 Apr 1995 13:09:52 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id NAA00451 for freebsd-current@FreeBSD.org; Sat, 8 Apr 1995 13:06:22 +0200 From: J Wunsch Message-Id: <199504081106.NAA00451@uriah.heep.sax.de> Subject: mangled file after system crash To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 8 Apr 1995 13:06:22 +0200 (MET DST) 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: 10675 Sender: current-owner@FreeBSD.org Precedence: bulk The file as shown below displayed in my uucp spool after a system crash. It's been the most recent file there, the system crashed right while running UUCP over TCP. The file is totally mangled, it looks like it has got snippets from many files in it. Is this a VM problem? (I'm uuencoding it to avoid mailer problems.) begin 644 /tmp/D.saxN3GOG M1G)O;2!O=VYE"YD92`H."XV+CDO."XV+CDM'EN8FUA4VYPC%W9'9$1#1J-$%:2F9Q,#(U2T9&24DT M4U1*07A914%C>#53>C@*3R]+.79B3VI.>61O6'!2,4Y:<4DR8U5O;#A6&Q-63148FYM"E5J3W!E8U)J2W!8 M9VU!:D9A6D%H5$QW8F9F8G,K>C9G=F(K9&YH=V9N-#%K35HS;3EA4S1Q16$R M;5EG13E0$A,3TES:E)&3$-+97=&2$-#16IB1357635S:#EK M;D%5C@S:55A1V]%2E1&6%I33F9*2&)I0T9A0SEK"F4V1S9Q M,3EE;TPS:F\V3T1$,F1O+RM",#=W4CEF2#DT96=:,3-H8UA7,T0V3DPX;VAD M2D1W0G1";7HO0VEF-V=E43DP;FTV1G=286H*;EHR,W(W>GIK;#)L=$5*;2M0 M4W-2:4ET1FI74S0R;6A+:"MH,3!T56IZ5S9%CE#:'AO;T]8:F9A;3@W5T5:2&5'3&AX0FE! M"FU725)21FE(0U-6>%%&9U-S1$1$25%S0U%N17%-1T-/2C1(34-'9%I32&M9 M0E5M:4I),4-+:VI!:S11:$1I0E-'1TA!1D)Z1U=Q9T(*.79M,DHK06Q(;'@U M4W12-FM)4BMW4'=G.6=/-#1$-FTR=T]X9TDV5GE)-T(Y4).6'=D=&%/-DDU6%%W,78U M>&XV;TLK8T9%0RMK-&U79%8W33!,4U)!8W%+8VUV9T)/33E1,R]46E=72U,O M,&9I-WE%"G=2-$%-,VDK8C%O:U-W,&YE1&%G1U`R-VU#,45U8E)70V=G*VHT MF69(<#1D;DPT M85I05CAA>E-3-6-26%=P;WA(FLU M,CDX-T]4>BLY*V9*<31.96DY0RLK93DW-WBM..38O=79("C0U3WHP+S-$:SDY1TE-8C5/2F-!;%!N53AZ-F1(<'=F M2'4S*T)!,611;DTK;B]X,&5R3#-#:C,O1F$T$)%9D9G M54Q&-6@T2&E-1SER8TE.F5H>F=":45C5S1M43EX2T]N44)W8FE/ M34E*6EIF4#A+4#EK3S!S54I832M!=C!#'EL M3DU$9U)O8T5)-D-324]$=T52.6=X2TLQ:F)1,S45%2FU!8TU% M5,O:&HU9'@U-$PQ*RMF0G%,=U=F=T=M0VQ% M1TE)4C%U66)B2%D*5V%V3GIC,3BLR25A%,%1#:7ET=VIL-$]%1W@R:W0X=&YN9DMA2W$X*S5Q`IR M:F8R.#)O*T55=C!5D9(9S%- M<$ITG9W"E=$3G-R845% M."MG=4AM3C)(959D8S!U,TM,,7!B:'5Q,C)95W%)3&]95$UB2F---&%G1T18 M;S5C5'9!5-H46U.3DUX;&I%35DQ5DE#3$Y. M94M5"B]9-TU),VQQ-7%&=V)..6AJ<%ER0U=X*UE)-W)),3%&435V6&-49S8X M2'HU94%4<'!G:VI"<2]1-6YS>C!04'!*=E=:2$4S>49',4\*25`K.$IJ,SAS M4&8K,"\T0F-T4TAD-FAH4$69*1T]V;3=Q;W-944]W>4I: M0U!I+V9D-4$W-"MH:V-&,T]B.$8W2"LU:F%L2E8Q4W=/-CDR:%I.3%%W3D)B M*SEV:DER='=5"D),341A63E0$9'5W@*1D-$ M*TE(9S8X:VYW4GE!9DQ!=TI(,%DK1T=966$R3',P635X3D=-255#<%IL3G%8 M,7%+=$-1&180D-H241#10I)6$]%0VUO63=12G!7;#A7 ME$R33)%0D9$6FAO>DA)>'%31V)5,75W;VDR6FUW3G-4 M,C8*;D%:<5)M,TYX3W%X4&1Q84-2-&UB5&=.,71M<%)T0S).,#1)1D1D*U5X M:U!A;W!*=D]P2!E=6YE="Y%52YN970@ M*#@N-BXQ,"\X+C8N,3`I('=I=&@@15--5%`@:60@5D%!,#2!F2!N86YO;&]N+F=U;BYD92`H."XV+C@N M,2\X+C8N-BD@=VET:"!554-0(&ED(%9!03(R,C$Y.R!&2!K;F]B96PN1U5.+F1E("@X+C8N.2\X M+C8N.2D@=VET:"!33510"@D@(&ED(%5!03`S.3,V"@D@($9R:2P@-R!!<'(@ M,3DY-2`R,#HT-SHQ,"`K,#(P,`I$871E.B!&C,P,2YI;F8N='4M9')E7!E M.B!415A4+U!,04E..R!C:&%R6]N92`B;W=N(B!P0H^(#X@=V]U;&0@8F4@3DE&5%D@:68@2!T86ME&%C="P@;VYE($A0($1E71H:6YG(&5X8V5P="!F;W(@9'9I M(&9I;&5S('5N9&5R(&%P"!F;W(@; Sat, 8 Apr 1995 04:48:20 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA26041; Sat, 8 Apr 1995 21:44:23 +1000 Date: Sat, 8 Apr 1995 21:44:23 +1000 From: Bruce Evans Message-Id: <199504081144.VAA26041@godzilla.zeta.org.au> To: phk@ref.tfs.com, taob@gate.sinica.edu.tw Subject: Re: Disk performance Cc: freebsd-current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Just to remind you how far we have got: >Seagate ST506, 20Mb "BIOS Type 2" disk: > dd if=/dev/rwd0d of=/dev/null bs=8k count=200 > 200+0 records in > 200+0 records out > 1638400 bytes transferred in 10 secs (163840 bytes/sec) >Imprimis(?) 94186-383 ESDI disk: > dd if=/dev/rwd2d of=/dev/null bs=8k count=400 > 400+0 records in > 400+0 records out > 3276800 bytes transferred in 8 secs (409600 bytes/sec) Just to remind you that IDE is better than SCSI ;-): [All with profiling kernel, profiling off] Toshiba MK537FB disk 486DX2/66 VLB Ultrastor 34F controller: dd if=/dev/rsd0 of=/dev/null bs=512 count=4000 4000+0 records in 4000+0 records out 2048000 bytes transferred in 20 secs (102400 bytes/sec) dd if=/dev/rsd0 of=/dev/null bs=4k count=4000 4000+0 records in 4000+0 records out 16384000 bytes transferred in 21 secs (780190 bytes/sec) dd if=/dev/rsd0 of=/dev/null bs=8k count=4000 4000+0 records in 4000+0 records out 32768000 bytes transferred in 26 secs (1260307 bytes/sec) dd if=/dev/rsd0 of=/dev/null bs=64k count=4000 4000+0 records in 4000+0 records out 262144000 bytes transferred in 102 secs (2570079 bytes/sec) Samsung SHD-3212A disk 486DX/33 IDE: dd if=/dev/rwd0 of=/dev/null bs=512 count=4000 4000+0 records in 4000+0 records out 2048000 bytes transferred in 4 secs (512000 bytes/sec) dd if=/dev/rwd0 of=/dev/null bs=4k count=4000 4000+0 records in 4000+0 records out 16384000 bytes transferred in 13 secs (1260307 bytes/sec) dd if=/dev/rwd0 of=/dev/null bs=8k count=4000 4000+0 records in 4000+0 records out 32768000 bytes transferred in 25 secs (1310720 bytes/sec) dd if=/dev/rwd0 of=/dev/null bs=64k count=4000 4000+0 records in 4000+0 records out 262144000 bytes transferred in 188 secs (1394382 bytes/sec) The SCSI disk has a much lower overhead but it has a worse transfer rate for a block size of 8K, and even worse transfer rate for smaller block sizes. It only has a reasonable transfer rate for huge block sizes (64K or more). Such block sizes get used when iozone is run but don't get used much for normal operations. Operations such as `cvs co' that do a lot of small i/o's run much faster on the IDE drive. A high-end SCSI disk is competitive with the low-end IDE disk for a block size of 4K: Quantum XP34301 disk 486DX2/66 VLB Ultrastor controller: dd if=/dev/rsd1 of=/dev/null bs=512 count=4000 4000+0 records in 4000+0 records out 2048000 bytes transferred in 12 secs (170666 bytes/sec) dd if=/dev/rsd1 of=/dev/null bs=4k count=4000 4000+0 records in 4000+0 records out 16384000 bytes transferred in 14 secs (1170285 bytes/sec) dd if=/dev/rsd1 of=/dev/null bs=8k count=4000 4000+0 records in 4000+0 records out 32768000 bytes transferred in 19 secs (1724631 bytes/sec) dd if=/dev/rsd1 of=/dev/null bs=64k count=4000 4000+0 records in 4000+0 records out 262144000 bytes transferred in 80 secs (3276800 bytes/sec) (5MB/sec before memory is fragmented) Most of the SCSI slowness seems to be caused by the extremely high command overhead of the U34F controller and/or SCSI interface. The minumum overhead seems to be about: Samsung/IDE/noname on 486DX/33: 1msec Quantum/SCSI/BT445C on 486DX2/66: 1.7msec (dd output not shown) Toshiba/SCSI/BT445C on 486DX2/66: 3msec (dd output not shown) Quantum/SCSI/U34F on 486DX2/66: 3.3msec Toshiba/SCSI/U34F on 486DX2/66: 5msec Bruce From owner-freebsd-current Sat Apr 8 05:23:44 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA13764 for current-outgoing; Sat, 8 Apr 1995 05:23:44 -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 FAA13748 for ; Sat, 8 Apr 1995 05:21:28 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA26653; Sat, 8 Apr 1995 22:14:25 +1000 Date: Sat, 8 Apr 1995 22:14:25 +1000 From: Bruce Evans Message-Id: <199504081214.WAA26653@godzilla.zeta.org.au> To: Ollivier.Robert@keltia.frmug.fr.net, rgrimes@gndrsh.aac.dev.com Subject: Re: Label/slices : how to add a disk ? Cc: freebsd-current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Even the 128 512 iozone result is amazing : Not really. >206 [18:22] root@keltia:/mnt# ~/Src/C/iozone_2.01/iozone 128 512 > IOZONE writes a 128 Megabyte sequential file consisting of > 262144 records which are each 512 bytes in length. > ... >Writing the 128 Megabyte file, 'iozone.tmp'...86.078125 seconds >Reading the file...48.976562 seconds >IOZONE performance measurements: > 1559254 bytes/second for writing the file > 2740448 bytes/second for reading the file As explained in other mail, clustering does a good job of turning the too-small 512-byte i/o's into 64K i/o's. The system has to do a lot more work to do the clustering and other things for many more buffers, but if there are enough cycles for this then the i/o speed doesn't suffer. Your speed is slower so you must not have enough cycles :-). This is not surprising for a 486/33. How fast is your controller for `dd if=/dev/rsd0 bs=512 count=4000'? Clustering doesn't apply to the raw device so a block size of 512 really is used. OTOH, unclustering applies to the block device /dev/sd0: for `dd if=dev/sd0 bs=64k count=4000', the specfs driver turns the nice 64K block size into the stupidly small size BLKDEV_IOSIZE = 2K. Bruce From owner-freebsd-current Sat Apr 8 06:03:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA14055 for current-outgoing; Sat, 8 Apr 1995 06:03:09 -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 GAA14038 for ; Sat, 8 Apr 1995 06:02:17 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA27527; Sat, 8 Apr 1995 22:56:47 +1000 Date: Sat, 8 Apr 1995 22:56:47 +1000 From: Bruce Evans Message-Id: <199504081256.WAA27527@godzilla.zeta.org.au> To: gwk@cray.com Subject: Re: 80387 hangs system at divide by zero Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >I am having a problem on my system with post 2.0 snapshots (some >snapshot in January and now 950210-SNAP). My system hangs in the npx >probe routine during bootup. Only the reset switch can wake it up >again. I inserted printf's in the code and could isolate the place: Some npx bugs were introduced on 950103 and fixed on 950217 and 950223, so the January and February snapshots have more npx bugs than usual. >it hangs where the driver forces a divide by zero in order to learn >which type of exception reporting the hardware uses. The system boots >up normally when I either boot the kernel with the -c option and >'disable npx0' (that's what I usually do so that I can work at all) or It's nice to know that `disable npx0' works. >when I skip the divide by zero code in the npx driver, hard coding >IRQ13 exception reporting at that point. In the latter case the >system will hang when I later start a program which divides by zero. Oops. >The 2.0-RELEASE didn't hang during boot, but I assume it also hung >when I divided by zero in a program. At least I could force a lock up It's surprising that it didn't hang during the boot given the other problems that you reported. The probe tries harder to avoid hanging because there is no possibility of ^C'ing out of it, but I don't know of any cases where it does better. >Did you know about this problem? Is IRQ13 exception reporting broken >in the current versions? Some buggy i387 (in)compatibles and/or motherboards are reported to lock up the whole system (interrupts stop working; I think this is an i387 bug); others are reported to only stop IRQ13 working (I think this is a motherboard problem). FreeBSD makes no attempt to handle either problem. Linux handles the second problem using a timeout, so an i387 error only wastes an average of 1/2 a clock tick. The bugs in the Jan/Feb snapshots are only indirectly related to this. >I have a 40 MHz Intel 80386 noname system with a ULSI '387. This Some ULSI '387's are reported to have the first problem :-(. >problem is not too darn important to me, I can currently live with >disabling the '387, and hopefully I can upgrade to some sort of '486 >later this year... :-) ...just thought you might be interested. If >you want me to try anything specific just let me know. Most people seem to have upgraded already, judging by the low number of bug reports for the old SNAPs (only 2 or 3) :-). Please try the divide by zero in an application under a current snapshot, or under 2.0, or even under Linux. Bruce From owner-freebsd-current Sat Apr 8 06:38:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA14543 for current-outgoing; Sat, 8 Apr 1995 06:38:45 -0700 Received: from cyclops.home.com (xtwa4.ess.harris.com [130.41.26.163]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA14537 for ; Sat, 8 Apr 1995 06:38:31 -0700 Received: (from jleppek@localhost) by cyclops.home.com (8.6.11/8.6.9) id JAA05859; Sat, 8 Apr 1995 09:41:33 -0400 Date: Sat, 8 Apr 1995 09:41:33 -0400 From: User Jleppek Message-Id: <199504081341.JAA05859@cyclops.home.com> To: rgrimes@gndrsh.aac.dev.com CC: richardc@CSUA.Berkeley.EDU, FreeBSD-current@freefall.cdrom.com In-reply-to: <199504072129.OAA08492@gndrsh.aac.dev.com> (rgrimes@gndrsh.aac.dev.com) Subject: Re: ppp still not working Sender: current-owner@FreeBSD.org Precedence: bulk I run ppp all the time and I have noticed that the link drops when 2 freebsd-current machines try to telnet or ftp to each other. from a sparc(lx,5,1) to a freebsd-current no problem from a fbsd-c to fbsd-c link drop everything(and everybody) else is ok. I sometimes suspect it could involve their provider as the other 2 fbsd machines I have setup for some local business's are thru the same provider and if it was this bad others would have noticed. I have a set of scripts that take care of autoredial, its not very elegant but it works for me :-) If you want them email. If you are getting hostname not found that usually means a problem with your /etc/resolv.conf or /etc/host.conf or your link is already down and you cannot reach your nameserver. Jim >Would someone who is running ppp on FreeBSD-current help Richard out, >this is the 3rd posting from him about his problem and no one has >responeded to him. I would help but I am not running SLIP or PPP >on -current (all my -current boxes are on ethernet). >> --richardc >-- >Rod Grimes rgrimes@gndrsh.aac.dev.com >Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 06:42:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA14593 for current-outgoing; Sat, 8 Apr 1995 06:42:29 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA14587 for ; Sat, 8 Apr 1995 06:42:25 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id VAA01536; Sat, 8 Apr 1995 21:42:37 +0800 Date: Sat, 8 Apr 1995 21:42:36 +0800 (CST) From: Brian Tao cc: freebsd-current@FreeBSD.org Subject: Re: Disk performance In-Reply-To: <199504081021.UAA24575@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 Sat, 8 Apr 1995, Bruce Evans wrote: > > Actually only 366/8 i/o requests are sent to SCSI devices. So sending 46 I/O requests over the SCSI bus and shuttling the ensuing byte stream occupies 50% of my CPU. *sigh* :( -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sat Apr 8 06:51:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA14670 for current-outgoing; Sat, 8 Apr 1995 06:51:40 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA14664 for ; Sat, 8 Apr 1995 06:51:34 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id VAA01556; Sat, 8 Apr 1995 21:51:58 +0800 Date: Sat, 8 Apr 1995 21:51:56 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: Disk performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sat, 8 Apr 1995, Gary Jennejohn wrote: > > 1st level cache: 407 MB/sec [...] > 1st level cache: 391 MB/sec Why would taking out the L2 cache slow down data transfer to and from the primary cache? -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sat Apr 8 07:02:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA14977 for current-outgoing; Sat, 8 Apr 1995 07:02:42 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA14971 for ; Sat, 8 Apr 1995 07:02:33 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id WAA01624; Sat, 8 Apr 1995 22:02:28 +0800 Date: Sat, 8 Apr 1995 22:02:26 +0800 (CST) From: Brian Tao To: Nate Williams cc: FREEBSD-CURRENT-L Subject: Re: man(1) bug In-Reply-To: <199504071458.IAA10407@trout.sri.MT.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Fri, 7 Apr 1995, Nate Williams wrote: > > It's in /usr/src/gnu/usr.bin/man/*. Figures, it had to be the one incomplete archive on the mirror... anyway, we wait for them to fix it then? -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sat Apr 8 07:05:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA15029 for current-outgoing; Sat, 8 Apr 1995 07:05:45 -0700 Received: from dream.demos.su (dream.demos.su [192.91.186.135]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA15020 for ; Sat, 8 Apr 1995 07:05:35 -0700 Received: by dream.demos.su id SAA08154; (8.6.8/D) Sat, 8 Apr 1995 18:05:12 +0400 To: freebsd-current@freefall.cdrom.com Message-ID: Organization: Demos, Moscow, Russia Date: Sat, 8 Apr 1995 18:05:12 +0400 X-Mailer: Mail/@ [v2.22 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: SUP errors Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 806 Sender: current-owner@FreeBSD.org Precedence: bulk SUP 8.26 (4.3 BSD) for file /etc/supfile at Apr 8 18:02:55 SUP Upgrade of base at Sat Apr 8 18:03:02 1995 SUP Fileserver 8.13 (4.3 BSD) 14979 on freefall.cdrom.com at 18:03:02 SUP Fileserver supports compression. SUP Requesting changes since Apr 3 12:20:58 1995 SUP Updating file README SUP Receiving file TODO SUP Created directory TODO-2.1 for TODO-2.1/CVS/Entries SUP Created directory TODO-2.1/CVS for TODO-2.1/CVS/Entries SUP Receiving file TODO-2.1/CVS/Entries SUP Receiving file TODO-2.1/CVS/Repository -- 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 Apr 8 08:45:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA17127 for current-outgoing; Sat, 8 Apr 1995 08:45: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 IAA17121 for ; Sat, 8 Apr 1995 08:45:55 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id IAA15265; Sat, 8 Apr 1995 08:44:27 -0700 From: "Rodney W. Grimes" Message-Id: <199504081544.IAA15265@gndrsh.aac.dev.com> Subject: Re: Disk performance To: garyj@rks32.pcs.dec.com (Gary Jennejohn) Date: Sat, 8 Apr 1995 08:44:26 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: from "Gary Jennejohn" at Apr 8, 95 12:01:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3451 Sender: current-owner@FreeBSD.org Precedence: bulk [Note to Gary: Dec's gateway leeked the cc: address on this mail as ``current%freebsd.org@inet-gw-1.pa.dec.com'', I corrected it manually, as those address forms from outside often bounce :-(] > > This is actually more about MB performance. > > Rodney Grimes wrote: > >> I expect to be able towards the end of next week show some really > >> amazing numbers on a Pentium system with respect to memory speeds. > >> Let's all hope that the new EDO and Pipelined Burst SRAM stand up > >> to the theories and we start to see 100++MB/sec main memory speeds on > >> a Pentium like we should. > > c't magazine ran a series of tests on the latest crop of PCI MBs > lately. Here are some of the results: > > ASUS PCI/I-P54TP4 (Triton chipset) with 256kB burst SRAM and 16 MB Well, the correct model number is PCI/I-P54TP4PB if it really has Pipelined Burst Sram. > EDO main mem. > 1st level cache: 407 MB/sec > 2nd level cache: 65 MB/sec > Main mem: 39 MB/sec The numbers I get for the PCI/I-P54TP4 with 256k standard async SRAM are: 1st level cache: 227MB/sec 2nd level cache: 90MB/sec Main memeory: 50MB/sec read, 37MB/sec write > The same MB without 2nd level cache but 16 MB EDO main mem. > 1st level cache: 391 MB/sec > 2nd level cache: N/A > Main mem: 44 MB/sec My EDO memory won't be here until next week :-(. > This board is actually faster w/o the 2nd level cache when EDO RAM > is used ! This was the fastet of all (6) configurations tested. Well, since they didn't report the 2nd level cache number I can not draw that conclusion from the above data. I will draw my own conclusion on that after extensive testing. I just don't buy it, how can 70nS EDO DRAM compete with 10nS Pipelined Burst SRAM. Even with EDO DRAM you need 70nS (>4 external P54C-100 clock ticks) to get to the first memory word vs 20nS (<2 external P54C-100 clock ticks) to get to the cache (It's 20nS because you have to do the tag read then the compare before you supply the data). After the first memory word the EDO *might* be able to supply data ever 15nS, but if I recall correctly it is run on a -2-2-2 burst cycle, the Pipelined burst sram can do it -1-1-1. > > The memmory transfer speeds were tested using some DOS utility developed > by c't. Performance might look different under FBSD. It does... humm... wonder what I can do to the code I am using to get that 400MB/sec internal speed :-). > They tested a whole slew of other things (SCSI, tranfers to a graphics > card, etc.), but it's too much to copy. Well, since FreeBSD would never do that in the real world I don't see a need for that type of test, but one I would like to have would be to test the frame buffer speed of the graphics card. Guess I could go hack on XFree86 Superprobe to see if I can stick this type of test in there. > There's still a ways to go to achieve 100++MB/sec to main mem. This bothers me, 70nS access, 140nS cycle time, 8 bytes wide, 1/140nS * 8 = 57MB/sec. And that is not using the ability to do fast page mode access for addresses in the same page, or burst cycles on EDO simms. The other one that upsets me is MB no longer do memory bank interleaving if you have 2 identical banks (4 simms) that are the same size, which would eliminate the 70nS DRAM recovery time between accesses. > Gary J. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 09:20:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA17962 for current-outgoing; Sat, 8 Apr 1995 09:20: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 JAA17956 for ; Sat, 8 Apr 1995 09:20:24 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id JAA15432; Sat, 8 Apr 1995 09:19:53 -0700 From: "Rodney W. Grimes" Message-Id: <199504081619.JAA15432@gndrsh.aac.dev.com> Subject: Re: Disk performance To: taob@gate.sinica.edu.tw (Brian Tao) Date: Sat, 8 Apr 1995 09:19:53 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Brian Tao" at Apr 8, 95 09:51:56 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 686 Sender: current-owner@FreeBSD.org Precedence: bulk > > On Sat, 8 Apr 1995, Gary Jennejohn wrote: > > > > 1st level cache: 407 MB/sec > [...] > > 1st level cache: 391 MB/sec > > Why would taking out the L2 cache slow down data transfer to and > from the primary cache? I attribute the above difference to an insignificant accuracy in the test results. (407-391)/391 = 4%, I suspect repeated runs of the same test on the same exact machine probably have a 5% variance in values. I see similiar variances with the program I use, from 227 to 263MB/sec or about 16% variation. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 09:48:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA18430 for current-outgoing; Sat, 8 Apr 1995 09:48:12 -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 JAA18424 for ; Sat, 8 Apr 1995 09:48:09 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id JAA15531; Sat, 8 Apr 1995 09:47:37 -0700 From: "Rodney W. Grimes" Message-Id: <199504081647.JAA15531@gndrsh.aac.dev.com> Subject: Re: Disk performance To: taob@gate.sinica.edu.tw (Brian Tao) Date: Sat, 8 Apr 1995 09:47:37 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Brian Tao" at Apr 8, 95 05:34:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1277 Sender: current-owner@FreeBSD.org Precedence: bulk > > On Sat, 8 Apr 1995, Rodney W. Grimes wrote: ... > > Yes, IDE drives load the cpu down far more, as they not only have to > > bcopy the bytes to and from user land, they also have to bcopy them > > to and from the disk. > > I presume that EIDE drives and drivers that support DMA wouldn't > suffer from this particular deficiency then. Sorry, I don't mean to > pick your brains in public like this. I hope someone else is learning > the basics of disk transfer too. :) EIDE drives that support mode 2 DMA would not suffer from this problem if the FreeBSD drives also supported mode 2 DMA. ... > > Especially with out detailed information about how the kernel implements > > the buffer copies to and from user land. I'm pretty sure the SGI boxes > > use page flipping, > > Hmmm, the only page flipping I know of is a double-buffered > animation technique used on the Apple II hi-res graphics screen. :) Same concept, different use. Basically you swap the users buffer for a kernel buffer by bit flipping in the vm system, this saves the bcopy operation, just like it does for graphics page flipping. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 09:50:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA18478 for current-outgoing; Sat, 8 Apr 1995 09:50:22 -0700 Received: from dream.demos.su (dream.demos.su [192.91.186.135]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA18471 for ; Sat, 8 Apr 1995 09:50:18 -0700 Received: by dream.demos.su id UAA08633; (8.6.8/D) Sat, 8 Apr 1995 20:50:05 +0400 To: freebsd-current@freefall.cdrom.com Message-ID: Organization: Demos, Moscow, Russia Date: Sat, 8 Apr 1995 20:50:05 +0400 X-Mailer: Mail/@ [v2.22 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: DDB is broken? Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 514 Sender: current-owner@FreeBSD.org Precedence: bulk I config -g my kernel and got (null)(xxxx,...) at xxx (null)(xxxx,...) at xxx etc. on 't' command when I break into DDB. I.e. no function names showed but (null) instead. Moreover, 'show map' cause page fault. Any ideas? -- 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 Apr 8 10:20:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA18992 for current-outgoing; Sat, 8 Apr 1995 10:20:52 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA18986 for ; Sat, 8 Apr 1995 10:20:49 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id LAA23173; Sat, 8 Apr 1995 11:24:46 -0600 Date: Sat, 8 Apr 1995 11:24:46 -0600 Message-Id: <199504081724.LAA23173@trout.sri.MT.net> To: Brian Tao Cc: Nate Williams , FREEBSD-CURRENT-L Subject: Re: man(1) bug In-Reply-To: References: <199504071458.IAA10407@trout.sri.MT.net> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Brian Tao writes: > On Fri, 7 Apr 1995, Nate Williams wrote: > > > > It's in /usr/src/gnu/usr.bin/man/*. > > Figures, it had to be the one incomplete archive on the mirror... > anyway, we wait for them to fix it then? Nope, we are currently the only people using that code as far as I know. They abandoned it a long time ago because (in their words) 'man pages' are outdated and are now replaced by the much better 'info' docs. I don't necessarily agree with it, but that's irrelevant. We need to fix the problem since they aren't going to. Nate From owner-freebsd-current Sat Apr 8 10:24:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA19035 for current-outgoing; Sat, 8 Apr 1995 10:24:06 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA19029 for ; Sat, 8 Apr 1995 10:24:03 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id LAA23253; Sat, 8 Apr 1995 11:28:08 -0600 Date: Sat, 8 Apr 1995 11:28:08 -0600 Message-Id: <199504081728.LAA23253@trout.sri.MT.net> To: "Andrey A. Chernov, Black Mage" Cc: freebsd-current@freefall.cdrom.com Subject: Re: SUP errors In-Reply-To: References: Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Andrey A. Chernov writes: > SUP 8.26 (4.3 BSD) for file /etc/supfile at Apr 8 18:02:55 > SUP Upgrade of base at Sat Apr 8 18:03:02 1995 .. > SUP Created directory TODO-2.1 for TODO-2.1/CVS/Entries > SUP Created directory TODO-2.1/CVS for TODO-2.1/CVS/Entries > SUP Receiving file TODO-2.1/CVS/Entries > SUP Receiving file TODO-2.1/CVS/Repository Fixed by the addition of 'omitany */CVS*' Nate From owner-freebsd-current Sat Apr 8 10:31:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA19142 for current-outgoing; Sat, 8 Apr 1995 10:31:28 -0700 Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA19136 for ; Sat, 8 Apr 1995 10:31:27 -0700 Received: from gilberto.physik.rwth-aachen.de by campino.informatik.rwth-aachen.de (4.1/campino-6) id AA13297; Sat, 8 Apr 95 19:31:15 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.8/8.6.9) id TAA10286; Sat, 8 Apr 1995 19:36:37 +0200 Message-Id: <199504081736.TAA10286@gilberto.physik.rwth-aachen.de> Subject: Re: should su retain ${DISPLAY} To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 8 Apr 1995 19:36:36 +0200 (MET DST) Cc: freebsd-current@freefall.cdrom.com (user alias) In-Reply-To: <199504081344.PAA00343@uriah.heep.sax.de> from "J Wunsch" at Apr 8, 95 03:44:00 pm From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 845 Sender: current-owner@FreeBSD.org Precedence: bulk > > What do people think about an extension to the su(1) command that > retains the ${DISPLAY} variable even across an ``su -''? Excuse my ignorance: What does su - do? I don't see it documented. It looks like it executes roots dotfiles. I also see $DISPLAY preserved during a normal 'su'. When you su to root from a normal user you can't connect to the server (0:0) anyway (unless you have enabled access before - xhost +). > > Seen on IRIX, think it's nice to have it. > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Mon Apr 3 17:10:12 MET DST 1995 root@blues:/usr/src/sys/compile/BLUESGUS i386 From owner-freebsd-current Sat Apr 8 10:56:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA19655 for current-outgoing; Sat, 8 Apr 1995 10:56:09 -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 KAA19631 for ; Sat, 8 Apr 1995 10:55:01 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA02397; Sun, 9 Apr 1995 03:50:02 +1000 Date: Sun, 9 Apr 1995 03:50:02 +1000 From: Bruce Evans Message-Id: <199504081750.DAA02397@godzilla.zeta.org.au> To: ache@astral.msk.su, freebsd-current@freefall.cdrom.com Subject: Re: DDB is broken? Sender: current-owner@FreeBSD.org Precedence: bulk >I config -g my kernel and got >(null)(xxxx,...) at xxx >(null)(xxxx,...) at xxx >etc. on 't' command when I break into DDB. >I.e. no function names showed but (null) instead. >Moreover, 'show map' cause page fault. If you use `strip -x' on the boot kernel, then there is a mmap() bug that sometimes causes an invalid symbol table. This is being fixed. Does anyone boot with full -g kernels? I don't know exactly what ddb will do with all the symbols. Bruce From owner-freebsd-current Sat Apr 8 11:09:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA19851 for current-outgoing; Sat, 8 Apr 1995 11:09:07 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA19845 for ; Sat, 8 Apr 1995 11:09:05 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id CAA03349; Sun, 9 Apr 1995 02:09:22 +0800 Date: Sun, 9 Apr 1995 02:09:22 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: man(1) bug In-Reply-To: <199504081724.LAA23173@trout.sri.MT.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sat, 8 Apr 1995, Nate Williams wrote: > > Nope, we are currently the only people using that code as far as I know. > They abandoned it a long time ago because (in their words) 'man pages' > are outdated and are now replaced by the much better 'info' docs. Blech. :( > I don't necessarily agree with it, but that's irrelevant. We need to > fix the problem since they aren't going to. I think I might be able to handle this one (but knowing GNU code...). Should I be subscribed to the commits list for doing this type of stuff? -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sat Apr 8 11:10:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA19873 for current-outgoing; Sat, 8 Apr 1995 11:10:14 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA19867 for ; Sat, 8 Apr 1995 11:10:13 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id LAA22532; Sat, 8 Apr 1995 11:10:04 -0700 From: Poul-Henning Kamp Message-Id: <199504081810.LAA22532@ref.tfs.com> Subject: Re: Disk performance To: taob@gate.sinica.edu.tw (Brian Tao) Date: Sat, 8 Apr 1995 11:10:04 -0700 (PDT) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Brian Tao" at Apr 8, 95 09:51:56 pm Content-Type: text Content-Length: 379 Sender: current-owner@FreeBSD.org Precedence: bulk > Why would taking out the L2 cache slow down data transfer to and > from the primary cache? because checking the L2 takes time, and they don't start the mem-cycle until they know they missed. -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant' From owner-freebsd-current Sat Apr 8 11:24:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA20077 for current-outgoing; Sat, 8 Apr 1995 11:24:51 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA20067 for ; Sat, 8 Apr 1995 11:24:47 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id MAA24432; Sat, 8 Apr 1995 12:28:41 -0600 Date: Sat, 8 Apr 1995 12:28:41 -0600 Message-Id: <199504081828.MAA24432@trout.sri.MT.net> To: Brian Tao Cc: FREEBSD-CURRENT-L Subject: Re: man(1) bug In-Reply-To: References: <199504081724.LAA23173@trout.sri.MT.net> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk [ problems with GNU-man in our src tree ] > > I don't necessarily agree with it, but that's irrelevant. We need to > > fix the problem since they aren't going to. > > I think I might be able to handle this one (but knowing GNU > code...). Should I be subscribed to the commits list for doing this > type of stuff? You should be subscribed to the commit lists if you are running -current code in any case, but I suppose so. I suspect it's not critical since I doubt anyone else will work on it anytime in the near future, but just in case it's probably a good idea. Nate From owner-freebsd-current Sat Apr 8 12:27:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA20906 for current-outgoing; Sat, 8 Apr 1995 12:27:19 -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 MAA20900 for ; Sat, 8 Apr 1995 12:27:16 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id MAA15834; Sat, 8 Apr 1995 12:26:35 -0700 From: "Rodney W. Grimes" Message-Id: <199504081926.MAA15834@gndrsh.aac.dev.com> Subject: Re: man(1) bug To: nate@sneezy.sri.com Date: Sat, 8 Apr 1995 12:26:34 -0700 (PDT) Cc: taob@gate.sinica.edu.tw, freebsd-current@FreeBSD.org In-Reply-To: <199504081724.LAA23173@trout.sri.MT.net> from "Nate Williams" at Apr 8, 95 11:24:46 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1011 Sender: current-owner@FreeBSD.org Precedence: bulk > > Brian Tao writes: > > On Fri, 7 Apr 1995, Nate Williams wrote: > > > > > > It's in /usr/src/gnu/usr.bin/man/*. > > > > Figures, it had to be the one incomplete archive on the mirror... > > anyway, we wait for them to fix it then? > > Nope, we are currently the only people using that code as far as I know. > They abandoned it a long time ago because (in their words) 'man pages' > are outdated and are now replaced by the much better 'info' docs. I > don't necessarily agree with it, but that's irrelevant. We need to fix > the problem since they aren't going to. Might I suggest taking a serious look at the 4.4 BSD Lite version of man. It was much improved over the Net/2 version. We would still need to go do the gzip hacks (but those are FreeBSD hacks to gnu man any way). If GNU has obsoleted gnu man, maybe we should too! > Nate -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 12:34:17 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA21014 for current-outgoing; Sat, 8 Apr 1995 12:34:17 -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 MAA21008 for ; Sat, 8 Apr 1995 12:34:13 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id MAA15861; Sat, 8 Apr 1995 12:33:35 -0700 From: "Rodney W. Grimes" Message-Id: <199504081933.MAA15861@gndrsh.aac.dev.com> Subject: Re: SUP errors To: nate@sneezy.sri.com Date: Sat, 8 Apr 1995 12:33:35 -0700 (PDT) Cc: ache@astral.msk.su, freebsd-current@freefall.cdrom.com In-Reply-To: <199504081728.LAA23253@trout.sri.MT.net> from "Nate Williams" at Apr 8, 95 11:28:08 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1171 Sender: current-owner@FreeBSD.org Precedence: bulk > > Andrey A. Chernov writes: > > SUP 8.26 (4.3 BSD) for file /etc/supfile at Apr 8 18:02:55 > > SUP Upgrade of base at Sat Apr 8 18:03:02 1995 > .. > > SUP Created directory TODO-2.1 for TODO-2.1/CVS/Entries > > SUP Created directory TODO-2.1/CVS for TODO-2.1/CVS/Entries > > SUP Receiving file TODO-2.1/CVS/Entries > > SUP Receiving file TODO-2.1/CVS/Repository > > Fixed by the addition of 'omitany */CVS*' Humm... wonder if we made a mistake on that regex, should it not be omitany */CVS/*??? I'll do some local testing and see if that gets the same effect. I done like the idea that CVS* could match CVSfiles or CVSfoobar, though the likely hood of names like that ever coming up is near zero. And grepping the sup config files on freefall makes me wonder about the wasted CPU time for some of the others, that should never get hit anyway: omitany *~ omitany *.o omitany */tags Nobody is suppose to muck around in the /usr/src or /usr/ports area, so files by these names should never ever be created. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 12:46:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA21293 for current-outgoing; Sat, 8 Apr 1995 12:46:46 -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 MAA21287 for ; Sat, 8 Apr 1995 12:46:42 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id MAA15893; Sat, 8 Apr 1995 12:45:38 -0700 From: "Rodney W. Grimes" Message-Id: <199504081945.MAA15893@gndrsh.aac.dev.com> Subject: Re: Disk performance To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Sat, 8 Apr 1995 12:45:38 -0700 (PDT) Cc: taob@gate.sinica.edu.tw, freebsd-current@FreeBSD.org In-Reply-To: <199504081810.LAA22532@ref.tfs.com> from "Poul-Henning Kamp" at Apr 8, 95 11:10:04 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1151 Sender: current-owner@FreeBSD.org Precedence: bulk > > > Why would taking out the L2 cache slow down data transfer to and > > from the primary cache? > > because checking the L2 takes time, and they don't start the mem-cycle > until they know they missed. You would be right if he was talking about why turning off the L2 cache increases memory speed. But that is not what he said ``taking out L2 cache slowing down L1 cache''. Nothing, nota, zippo, should effect L1 cache speeds other than code changes, and internal clock frequency. Even bus snoops cycles are not suppose to change the L1 cache access since it has a dedicated snoop port (yes, the tags on the internal Pentium cache are multiported, and the data cache is dual ported). Now on the issue you bring up.. seems PC cache designers never heard of implemented pass through memory start cycles with early abort. It's tricky to design, but it elminates the delay due to cache tag lookup and compare time (30nS for most motherboards, 20nS for the new Pipelined Burst stuff). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 12:47:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA21313 for current-outgoing; Sat, 8 Apr 1995 12:47:48 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA21307 for ; Sat, 8 Apr 1995 12:47:47 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id MAA22769; Sat, 8 Apr 1995 12:47:32 -0700 From: Poul-Henning Kamp Message-Id: <199504081947.MAA22769@ref.tfs.com> Subject: Re: Disk performance To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Sat, 8 Apr 1995 12:47:31 -0700 (PDT) Cc: taob@gate.sinica.edu.tw, freebsd-current@FreeBSD.org In-Reply-To: <199504081945.MAA15893@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Apr 8, 95 12:45:38 pm Content-Type: text Content-Length: 796 Sender: current-owner@FreeBSD.org Precedence: bulk > > > > > > Why would taking out the L2 cache slow down data transfer to and > > > from the primary cache? > > > > because checking the L2 takes time, and they don't start the mem-cycle > > until they know they missed. > > You would be right if he was talking about why turning off the L2 cache > increases memory speed. But that is not what he said ``taking out L2 > cache slowing down L1 cache''. Nothing, nota, zippo, should effect > L1 cache speeds other than code changes, and internal clock frequency. Sure, but they still need to get the stuff to put in the L1 for their test from RAM, right ? -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant' From owner-freebsd-current Sat Apr 8 12:54:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA21419 for current-outgoing; Sat, 8 Apr 1995 12:54: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 MAA21407 for ; Sat, 8 Apr 1995 12:53:55 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id MAA15923; Sat, 8 Apr 1995 12:52:13 -0700 From: "Rodney W. Grimes" Message-Id: <199504081952.MAA15923@gndrsh.aac.dev.com> Subject: Re: Disk performance To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Sat, 8 Apr 1995 12:52:13 -0700 (PDT) Cc: taob@gate.sinica.edu.tw, freebsd-current@FreeBSD.org In-Reply-To: <199504081947.MAA22769@ref.tfs.com> from "Poul-Henning Kamp" at Apr 8, 95 12:47:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1498 Sender: current-owner@FreeBSD.org Precedence: bulk > > > > > > > > > > Why would taking out the L2 cache slow down data transfer to and > > > > from the primary cache? > > > > > > because checking the L2 takes time, and they don't start the mem-cycle > > > until they know they missed. > > > > You would be right if he was talking about why turning off the L2 cache > > increases memory speed. But that is not what he said ``taking out L2 > > cache slowing down L1 cache''. Nothing, nota, zippo, should effect > > L1 cache speeds other than code changes, and internal clock frequency. > > Sure, but they still need to get the stuff to put in the L1 for their > test from RAM, right ? Depends on how the program is written. The program I use will infact get the first copy from main memory, but after that the 10000 iterations are all done in the cache. I am suspecting since thier numbers are almost 2X the numbers I get they are not counting the time for the initial main memory read. The difference the person was talking about was 391 vs 407, I have already explained in other email that this was probably just due to the statistical variance of the test sample. I can produce numbers from repeated runs of my program on the same machine that have 15% variations. I can get it down to 5% if I boot single user, but it still varies (probably due to timer code accuracy). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 13:28:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA22317 for current-outgoing; Sat, 8 Apr 1995 13:28:31 -0700 Received: from kbrown.oldcampus.yale.edu (root@kbrown.oldcampus.yale.edu [130.132.128.124]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA22309 for ; Sat, 8 Apr 1995 13:28:28 -0700 Date: Sat, 8 Apr 1995 16:27:42 -0400 (EDT) From: -Vince- To: FreeBSD-current@freefall.cdrom.com Subject: backspace key doesn't work in X Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Just wanted to report that the backspace key would just generate ^H on the screen for all TCP/IP Clients and not work correctly under X... Anyone know how to fix this? I forgot to mention that it worked before the backspace key changes to Syscons.. Cheers, Vince -*vince@kbrown.oldcampus.yale.edu*- UCLA Physics/Electrical Engineering From owner-freebsd-current Sat Apr 8 13:38:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA22647 for current-outgoing; Sat, 8 Apr 1995 13:38:01 -0700 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA22641 for ; Sat, 8 Apr 1995 13:37:57 -0700 Received: (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id NAA01943; Sat, 8 Apr 1995 13:37:50 -0700 Date: Sat, 8 Apr 1995 13:37:48 -0700 From: Richard Chang To: User Jleppek cc: FreeBSD-current@freefall.cdrom.com Subject: Re: ppp still not working In-Reply-To: <199504081341.JAA05859@cyclops.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Sat, 8 Apr 1995, User Jleppek wrote: > I run ppp all the time and I have noticed that the link drops > when 2 freebsd-current machines try to telnet or ftp to each other. > > from a sparc(lx,5,1) to a freebsd-current no problem > from a fbsd-c to fbsd-c link drop > > everything(and everybody) else is ok. I sometimes suspect > it could involve their provider as the other 2 fbsd > machines I have setup for some local business's > are thru the same provider and if it was this bad others > would have noticed. > > I have a set of scripts that take > care of autoredial, its not very elegant but it works for me :-) > If you want them email. > Sure, that would be great if you can send the setup over ... I actually use kermit to dial and start ppp on the Annex Terminal server then suspend kermit and kill kermit then: bigbang# /usr/sbin/pppd /dev/cua00 115200 /etc/ppp/options contains: bigbang# cat /etc/ppp/options defaultroute crtscts netmask 255.255.255.0 bigbang# > If you are getting hostname not found that usually means > a problem with your /etc/resolv.conf or /etc/host.conf or your > link is already down and you cannot reach your nameserver. > Hmmm, here are my /etc/resolv.conf and /etc/host.conf files... It works fine for slip and the link isn't down since it just doesn't work for slip either if I did ppp first and then I need to reboot the machine in order for slip to work again... bigbang# cat /etc/resolv.conf domain HIP.Berkeley.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 bigbang# cat /etc/host.conf # $Id: host.conf,v 1.2 1993/11/07 01:02:57 wollman Exp $ # Default is to use the nameserver first hosts bind # If that doesn't work, then try the /etc/hosts file # hosts # If you have YP/NIS configured, uncomment the next line # nis bigbang# > Jim --richardc From owner-freebsd-current Sat Apr 8 14:02:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA23349 for current-outgoing; Sat, 8 Apr 1995 14:02:27 -0700 Received: from aries.ibms.sinica.edu.tw ([140.109.40.248]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA23343 for ; Sat, 8 Apr 1995 14:02:22 -0700 Received: (from taob@localhost) by aries.ibms.sinica.edu.tw (8.6.11/8.6.9) id FAA07025; Sun, 9 Apr 1995 05:02:38 +0800 Date: Sun, 9 Apr 1995 05:02:36 +0800 (CST) From: Brian Tao To: FREEBSD-CURRENT-L Subject: Re: man(1) bug In-Reply-To: <199504081926.MAA15834@gndrsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Here's a simple patch that fixes the manpage-starting-with-a-number bug and the can't-find-the-[-man-page-bug. The second fix is really kludgy at the moment, but it's almost 5 am and I spent the last three hours on IRC walking a user through a new FreeBSD installation on his notebook with a zp0 PCMCIA network card, only to find out from a DOS diag utility that the card is toast. :( Anyhow, I'll try to come up with something cleaner tomorrow or the day after... oh, this is applied to /usr/src/gnu/usr.bin/man/man/man.c. 461c461 < if ((strcmp (*vs, name) == NULL) || (isdigit (name[0]))) --- > if ((strcmp (*vs, name) == NULL) || (isdigit (name[0]) && strlen(name) == 1)) 593c593 < sprintf (pathname, "%s/cat%s/%s.%s*", path, section, name, section); --- > sprintf (pathname, "%s/cat%s/\\%s.%s*", path, section, name, section); 595c595 < sprintf (pathname, "%s/man%s/%s.%s*", path, section, name, section); --- > sprintf (pathname, "%s/man%s/\\%s.%s*", path, section, name, section); 605c605 < sprintf (pathname, "%s/cat%s/%s.%c*", path, section, name, *section); --- > sprintf (pathname, "%s/cat%s/\\%s.%c*", path, section, name, *section); 607c607 < sprintf (pathname, "%s/man%s/%s.%c*", path, section, name, *section); --- > sprintf (pathname, "%s/man%s/\\%s.%c*", path, section, name, *section); 614c614 < sprintf (pathname, "%s/cat%s/%s.0*", path, section, name); --- > sprintf (pathname, "%s/cat%s/\\%s.0*", path, section, name); 616c616 < sprintf (pathname, "%s/man%s/%s.0*", path, section, name); --- > sprintf (pathname, "%s/man%s/\\%s.0*", path, section, name); -- Brian ("Though this be madness, yet there is method in't") Tao taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org From owner-freebsd-current Sat Apr 8 14:03:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA23402 for current-outgoing; Sat, 8 Apr 1995 14:03:08 -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 OAA23358 for ; Sat, 8 Apr 1995 14:02:43 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA19585; Sat, 8 Apr 1995 23:02:01 +0200 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id XAA15453 for freebsd-current@FreeBSD.org; Sat, 8 Apr 1995 23:02:00 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id WAA00489 for freebsd-current@FreeBSD.org; Sat, 8 Apr 1995 22:11:22 +0200 From: J Wunsch Message-Id: <199504082011.WAA00489@uriah.heep.sax.de> Subject: Re: should su retain ${DISPLAY} To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 8 Apr 1995 22:11:22 +0200 (MET DST) In-Reply-To: <199504081736.TAA10286@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Apr 8, 95 07:36:36 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: 926 Sender: current-owner@FreeBSD.org Precedence: bulk As Christoph Kukulies wrote: > > > > > What do people think about an extension to the su(1) command that > > retains the ${DISPLAY} variable even across an ``su -''? > > Excuse my ignorance: What does su - do? I don't see it documented. It looks > like it executes roots dotfiles. I also see $DISPLAY preserved during a > normal 'su'. It does not preserve the normal environment, instead it operates (almost) like a login on the target UID. > When you su to root from a normal user you can't connect to the server (0:0) > anyway (unless you have enabled access before - xhost +). Only if you are using the MIT_MAGIC_COOKIE authentication. Most of our users certainly don't, since they work in a more-or-less trusted environment where host-based authorization is sufficient. -- 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 Apr 8 14:31:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA25777 for current-outgoing; Sat, 8 Apr 1995 14:31:32 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA25766 for ; Sat, 8 Apr 1995 14:31:24 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id PAA25993; Sat, 8 Apr 1995 15:35:22 -0600 Date: Sat, 8 Apr 1995 15:35:22 -0600 Message-Id: <199504082135.PAA25993@trout.sri.MT.net> To: "Rodney W. Grimes" Cc: nate@sneezy.sri.com, ache@astral.msk.su, freebsd-current@freefall.cdrom.com Subject: Re: SUP errors In-Reply-To: <199504081933.MAA15861@gndrsh.aac.dev.com> References: <199504081728.LAA23253@trout.sri.MT.net> <199504081933.MAA15861@gndrsh.aac.dev.com> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk > > > SUP Receiving file TODO-2.1/CVS/Repository > > > > Fixed by the addition of 'omitany */CVS*' > > Humm... wonder if we made a mistake on that regex, should it not > be omitany */CVS/*??? I'll do some local testing and see if that > gets the same effect. I done like the idea that CVS* could match > CVSfiles or CVSfoobar, though the likely hood of names like that > ever coming up is near zero. I'll let you do your research. I just followed what was done before. > And grepping the sup config files on freefall makes me wonder about > the wasted CPU time for some of the others, that should never get > hit anyway: > > omitany *~ > omitany *.o > omitany */tags > > Nobody is suppose to muck around in the /usr/src or /usr/ports area, > so files by these names should never ever be created. It's better to be safe than sorry, and I suspect the extra overhead of these is so neglibible that it's not worth worrying about in terms of CPU hit. Nate From owner-freebsd-current Sat Apr 8 14:40:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA26141 for current-outgoing; Sat, 8 Apr 1995 14:40:11 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA26133 for ; Sat, 8 Apr 1995 14:40:07 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id PAA26018; Sat, 8 Apr 1995 15:39:19 -0600 Date: Sat, 8 Apr 1995 15:39:19 -0600 Message-Id: <199504082139.PAA26018@trout.sri.MT.net> To: Brian Tao Cc: FREEBSD-CURRENT-L Subject: Re: man(1) bug In-Reply-To: References: <199504081926.MAA15834@gndrsh.aac.dev.com> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: current-owner@FreeBSD.org Precedence: bulk Brian Tao writes: > Here's a simple patch that fixes the manpage-starting-with-a-number > bug and the can't-find-the-[-man-page-bug. The second fix is really > kludgy at the moment Thanks for doing this, and I hate to be obnoxious, but can you re-send your diffs and: 1) Use context diffs for the patch so we can make sure we're patching the correct portion of the code. It also helps to see the context of the patch. Use 'diff -c'. 2) Separate out the 'kludgy' fix from the not-so-kludgy so we can install the good fix and try and improve on the second. :) Thanks! Nate From owner-freebsd-current Sat Apr 8 15:12:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA27538 for current-outgoing; Sat, 8 Apr 1995 15:12:33 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA27532 for ; Sat, 8 Apr 1995 15:12:25 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Sat, 8 Apr 1995 17:12:20 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 8 Apr 1995 17:12:24 -0500 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: closing bin/295 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >As Richard Wackerbarth wrote: >> >> >No. It should only refer to the version that fixes the problem. >> >Interested parties can check the CVS log for this. We've already been >> >discussing this topic, and it's been the consensus like i've told you. >> >> Where is there an archive of the CVS log that is PUBLICALLY available? > >Hmm. Publically? Problem... maybe we should ask Jordan (or even the >whole hackers' list) to archive them at ftp.freebsd.org. My point is that the Bugs (and their fixes) are much more "public" than the CVS list. 99% (estimate) of the CVS log does not mean anything to someone reading the bug list. Therefore, I think it appropriate to put the info in the message changing/closing the bug. If someone really wants DETAILS, then the CVS area is the correct place. Access to that is a separate question. >> Agree. However, that points up a "problem" with the whole "SNAP-Release" >> system. Perhaps we need to have some way of tracking just what version of >> things is in that "release" eg: In the source files, we could/should >> include the .ctm_status files that reflect the updates that had been >> applied. > >It's not actually related to CTM, so this is not free of potential >raises. Perhaps it would be possible to collect all $Id$s into one >file. OTOH, the SNAPs are rather special in that they're not being >tagged on the CVS tree. For full releases, the CVS tags are a >sufficient method to retrieve the files later. Well, I think that they should be noted somewhere. Remember that many of us who are "testing" the -current stuff do not have access to the CVS tree. The public view of that tree is the -current tree. With the advent of CTM, I think it reasonable to use those numbers as the identification of interim builds of -current. For example, if I choose to build a kernel RIGHT NOW, you need some way to understand exactly which version of [pick something] I have included. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Sat Apr 8 21:00:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01120 for current-outgoing; Sat, 8 Apr 1995 21:00:02 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA01113 ; Sat, 8 Apr 1995 21:00:00 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Christoph Kukulies cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@freefall.cdrom.com (user alias) Subject: Re: should su retain ${DISPLAY} In-reply-to: Your message of "Sat, 08 Apr 95 19:36:36 +0200." <199504081736.TAA10286@gilberto.physik.rwth-aachen.de> Date: Sat, 08 Apr 1995 21:00:00 -0700 Message-ID: <1112.797400000@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > Excuse my ignorance: What does su - do? I don't see it documented. It looks > like it executes roots dotfiles. I also see $DISPLAY preserved during a > normal 'su'. It executes the dotfiles for whichever user you're su'ing to. I think of `su -' as "su, but flush my current environment totally and adopt that of the user I'm su'ing to." It is therefore arguable that not preserving DISPLAY in these cases is, in fact, the right thing to do. Jordan From owner-freebsd-current Sat Apr 8 21:46:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01731 for current-outgoing; Sat, 8 Apr 1995 21:46:22 -0700 Received: from goof.com (root@goof.com [198.82.204.15]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA01725 for ; Sat, 8 Apr 1995 21:46:21 -0700 Received: (from mmead@localhost) by goof.com (8.6.11/8.6.9) id XAA22901 for current@freebsd.org; Sat, 8 Apr 1995 23:35:57 -0400 From: "matthew c. mead" Message-Id: <199504090335.XAA22901@goof.com> Subject: talk - mesg y only To: current@FreeBSD.org Date: Sat, 8 Apr 1995 23:35:56 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 734 Sender: current-owner@FreeBSD.org Precedence: bulk Why does talk want mesg y all the time? It's not needed to be able to talk to others. I like to keep messages on on one xterm, and messages off on everything else, including a talk session - that way it doesn't interrupt the wrong window. I know I could just go change this myself (the change is really trivial), but I thought I might ask if anyone knows another reason it's desirable (?) to keep this behavior... -matt -- Matthew C. Mead -> Virginia Tech Center for Transportation Research - -> Multiple Platform System and Network Administration Work Related -> mmead@ctr.vt.edu | mmead@goof.com <- All Other ---- ------- WWW -> http://www.goof.com/~mmead --- ----- From owner-freebsd-current Sat Apr 8 22:12:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02180 for current-outgoing; Sat, 8 Apr 1995 22:12:30 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA02174 for ; Sat, 8 Apr 1995 22:12:26 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA18008; Sat, 8 Apr 95 22:56:21 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504090456.AA18008@cs.weber.edu> Subject: Re: Disk performance To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Sat, 8 Apr 95 22:56:20 MDT Cc: taob@gate.sinica.edu.tw, freebsd-current@FreeBSD.org In-Reply-To: <199504081647.JAA15531@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Apr 8, 95 09:47:37 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > > Yes, IDE drives load the cpu down far more, as they not only have to > > > bcopy the bytes to and from user land, they also have to bcopy them > > > to and from the disk. > > > > I presume that EIDE drives and drivers that support DMA wouldn't > > suffer from this particular deficiency then. Sorry, I don't mean to > > pick your brains in public like this. I hope someone else is learning > > the basics of disk transfer too. :) > > EIDE drives that support mode 2 DMA would not suffer from this problem > if the FreeBSD drives also supported mode 2 DMA. Luckily all EIDE drives adhere to the same standard for mode 2 DMA. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Apr 8 22:17:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02363 for current-outgoing; Sat, 8 Apr 1995 22:17:19 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA02349 for ; Sat, 8 Apr 1995 22:17:02 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0rxotz-000K0iC; Sat, 8 Apr 95 21:47 WET DST Message-Id: Date: Sat, 8 Apr 95 21:47 WET DST From: pete@pelican.com (Pete Carah) To: current@FreeBSD.org Subject: Re: Disk performance In-Reply-To: Organization: Pelican Consulting Sender: current-owner@FreeBSD.org Precedence: bulk In article you write: > >On Sat, 8 Apr 1995, Rodney W. Grimes wrote: >> .... RG Especially with out detailed information about how the kernel implements RG the buffer copies to and from user land. I'm pretty sure the SGI boxes RG use page flipping, T Hmmm, the only page flipping I know of is a double-buffered T animation technique used on the Apple II hi-res graphics screen. :) SGI indeed does page flipping for the disk buffers *IF* the read is a multiple of the page size and is page-aligned (and they arrange that stdio does so). I've been told by several sgi folk that, at least in 4.0.x, if either of these is not true, then the bcopy is done. This implies that kernel buffers are always page-aligned ... They do this also for network buffers where it applies (MTU for fddi is around 5k, so at 4 they can do it). They do this for raw disk I/O too. They went to a lot of trouble to do this so that video could be transferred to/from disk in real time (remember the "graphics" in the name)... (and supposedly the performance is max'd for read if the read request is 16k; they have a dma limit that isn't much bigger than ours, so can't usually go over 64k in a single (raw) read. longer filesystem reads do work.) Note that their filesystem looks to the user like a UFS but it is really extent based. I had made a comment to JD about that but at the time they were having a big problem just getting the unified page/disk cache to work at all... Also you have to bite the bullet and make the stdio buffers 4k or more and waste up to 4k more to get malloc page-aligned, before you get much (any visible) advantage... Page-flip buffering would make iozone VERY fast since long streams are almost the best kind of I/O for that buffer scheme. Don't know how much help it would be for "normal" apps. Also the onyx and challenge use a 256-bit bus with 21ns (bus) cycle and cache line of 4x that... Handles 200-250mhz processors just fine. *that* is a memory bus. Do remember that D1 video runs at 280Mbits/sec... (and the memory board is 2 or 4 -way interleaved depending on SIMM mix) Their trick for cache consistency is cute, too. Then again, you can't buy one for $1k, either. T About 5MB/sec slower than the 486's. A damn waste of CPU too... all T I see people do on that machine is read news and mail. :( Well, if it runs both sendmail and inn and does both in high volumes, you want lots of disk bandwidth, and lots of ram and that bandwidth too... I'd rather see an SGI or HP there (though HP messed up the OS enough that a lot of the software is hard to port.) 486's and pentiums aren't all that bad for networking. Our 386-25 gets half the ftp rate that the mid-sized SGI's do (about 450kbytes/sec, to/from IDE drives, on 1.1.5 to or from an sgi.) Not bad for a hand-me-down slow motherboard and $100 ethernet boards. This is over twice as fast as svr4 with Lachman TCP on the same machine, with UFS filesystems, too. The indigos and 4D35's do about 850-900; the 380, crimson, and onyx will ftp at 1.1-1.2m, just below the ethernet maximum. They didn't want to spring for a 486 for the firewall; with a 56k net link you don't really need it either... RG I expect to be able towards the end of next week show some really RG amazing numbers on a Pentium system with respect to memory speeds. RG Let's all hope that the new EDO and Pipelined Burst SRAM stand up RG to the theories and we start to see 100++MB/sec main memory speeds on RG a Pentium like we should. Agreed... Looking forward to it. PCI specs are pretty good but PC motherboards have never been very good in the memory interface dept. Is the idea of EDO that you hit RAS for the next cycle while the out data is still current? Bank interleave probably helps more for cheaper, if you have/need enough memory. Eeek. Here I go back to my old mainframe days :-) -- Pete From owner-freebsd-current Sat Apr 8 22:17:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02375 for current-outgoing; Sat, 8 Apr 1995 22:17:40 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA02369 for ; Sat, 8 Apr 1995 22:17:29 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0rxp8a-000K0jC; Sat, 8 Apr 95 22:02 WET DST Message-Id: Date: Sat, 8 Apr 95 22:02 WET DST From: pete@pelican.com (Pete Carah) To: current@FreeBSD.org Subject: Re: Disk performance In-Reply-To: <199504081952.MAA15923@gndrsh.aac.dev.com> Organization: Pelican Consulting Sender: current-owner@FreeBSD.org Precedence: bulk In article <199504081952.MAA15923@gndrsh.aac.dev.com> rgrimes writes: (and various others, too): >> > > > Why would taking out the L2 cache slow down data transfer to and >> > > > from the primary cache? >> > > because checking the L2 takes time, and they don't start the mem-cycle >> > > until they know they missed. The SGI challenge starts both on the same clock, then throws away the mem data if some cache hit first. I don't know if they abort the CAS part of the memory cycle in that case, but I think not. That is part of the distributed-cache-coherency scheme too. Doing this hurts you badly in the absence of memory interleave, though, since you can't abort a RAS-cycle; you are better off waiting like they do in that case. >> > You would be right if he was talking about why turning off the L2 cache >> > increases memory speed. But that is not what he said ``taking out L2 >> > cache slowing down L1 cache''. Nothing, nota, zippo, should effect >> > L1 cache speeds other than code changes, and internal clock frequency. Possibly worse hit rates; isn't the L2 controller on the main chip too? Also L2 may be wider than main mem too and do background fetch of the other half; I don't know about that motherboard. Bigger ($$$$$) systems do this. Then L1 fills will come from the L2 about half more often than from main memory directly. -- Pete From owner-freebsd-current Sat Apr 8 22:28:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02531 for current-outgoing; Sat, 8 Apr 1995 22:28:02 -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 WAA02525 for ; Sat, 8 Apr 1995 22:27:57 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id WAA17109; Sat, 8 Apr 1995 22:27:36 -0700 From: "Rodney W. Grimes" Message-Id: <199504090527.WAA17109@gndrsh.aac.dev.com> Subject: Re: Disk performance To: pete@pelican.com (Pete Carah) Date: Sat, 8 Apr 1995 22:27:36 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: from "Pete Carah" at Apr 8, 95 09:47:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1188 Sender: current-owner@FreeBSD.org Precedence: bulk ... > RG I expect to be able towards the end of next week show some really > RG amazing numbers on a Pentium system with respect to memory speeds. > RG Let's all hope that the new EDO and Pipelined Burst SRAM stand up > RG to the theories and we start to see 100++MB/sec main memory speeds on > RG a Pentium like we should. > > Agreed... Looking forward to it. PCI specs are pretty good but PC > motherboards have never been very good in the memory interface dept. > > Is the idea of EDO that you hit RAS for the next cycle while the out > data is still current? Bank interleave probably helps more for cheaper, > if you have/need enough memory. Eeek. Here I go back to my old > mainframe days :-) I have not been able to find much technical data on exactly how the EDO simms work. I do know that it is suppose to eliminate the RAS precharge time between access cycles, and still support the equivilent of fast page mode accesses. I need to go dig in the magazines and see if I can find some more indepth articles on EDO. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 22:33:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02755 for current-outgoing; Sat, 8 Apr 1995 22:33:47 -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 WAA02745 for ; Sat, 8 Apr 1995 22:33:40 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id WAA17143; Sat, 8 Apr 1995 22:33:18 -0700 From: "Rodney W. Grimes" Message-Id: <199504090533.WAA17143@gndrsh.aac.dev.com> Subject: Re: Disk performance To: pete@pelican.com (Pete Carah) Date: Sat, 8 Apr 1995 22:33:17 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: from "Pete Carah" at Apr 8, 95 10:02:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2214 Sender: current-owner@FreeBSD.org Precedence: bulk > > In article <199504081952.MAA15923@gndrsh.aac.dev.com> rgrimes writes: > (and various others, too): > > >> > > > Why would taking out the L2 cache slow down data transfer to and > >> > > > from the primary cache? > > >> > > because checking the L2 takes time, and they don't start the mem-cycle > >> > > until they know they missed. > > The SGI challenge starts both on the same clock, then throws away the > mem data if some cache hit first. I don't know if they abort the CAS > part of the memory cycle in that case, but I think not. That is part > of the distributed-cache-coherency scheme too. Doing this hurts you > badly in the absence of memory interleave, though, since you can't abort > a RAS-cycle; you are better off waiting like they do in that case. Ahhhh!! A good memory system! The cache hit signal usually comes valid before the CAS cycle has started, so they probably do abort the CAS cycle by dropping RAS at this point in time and never asserting CAS. You still have to wait the RAS precharge time after doing this though, since you have infact sucked the storage charge out of the capacitors during the RAS assertion :-(. > > >> > You would be right if he was talking about why turning off the L2 cache > >> > increases memory speed. But that is not what he said ``taking out L2 > >> > cache slowing down L1 cache''. Nothing, nota, zippo, should effect > >> > L1 cache speeds other than code changes, and internal clock frequency. > > Possibly worse hit rates; isn't the L2 controller on the main chip too? No, the L2 cache controller is completly external from the Pentium CPU. > Also L2 may be wider than main mem too and do background fetch of the other > half; I don't know about that motherboard. Bigger ($$$$$) systems do this. I haven't see a L2 cache wider than the CPU (well, other than in a certain prototype some place I saw.). Main memory was also widened in this design to 128 bits. > Then L1 fills will come from the L2 about half more often than from > main memory directly. > > -- Pete > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sat Apr 8 22:48:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03793 for current-outgoing; Sat, 8 Apr 1995 22:48:19 -0700 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03784 for current; Sat, 8 Apr 1995 22:48:18 -0700 Date: Sat, 8 Apr 1995 22:48:18 -0700 From: "Jordan K. Hubbard" Message-Id: <199504090548.WAA03784@freefall.cdrom.com> To: current Subject: some current iozone figures Sender: current-owner@FreeBSD.org Precedence: bulk Just FYI.. Environment was thud.cdrom.com - Bt747C controller and a Seagate Barracuda formatted as a single 4GB partition: [previous values deleted due to hitting cache] 4 512 2182402 2767375 4 1024 2418337 2917776 4 2048 2429280 2999278 4 4096 2407492 2999278 4 8192 2407492 3033168 8 512 2209345 2825636 8 1024 2386092 2949840 8 2048 2457075 3024624 8 4096 2434788 3067833 8 8192 2434788 3076624 16 512 2213900 2855696 16 1024 2454267 2986764 16 2048 2434788 2995095 16 4096 2454267 3089904 16 8192 2445881 3112295 From owner-freebsd-current Sat Apr 8 22:54:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA04160 for current-outgoing; Sat, 8 Apr 1995 22:54: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 WAA04141 ; Sat, 8 Apr 1995 22:54:04 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id WAA17251; Sat, 8 Apr 1995 22:53:53 -0700 From: "Rodney W. Grimes" Message-Id: <199504090553.WAA17251@gndrsh.aac.dev.com> Subject: Re: some current iozone figures To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Sat, 8 Apr 1995 22:53:52 -0700 (PDT) Cc: current@freefall.cdrom.com In-Reply-To: <199504090548.WAA03784@freefall.cdrom.com> from "Jordan K. Hubbard" at Apr 8, 95 10:48:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1534 Sender: current-owner@FreeBSD.org Precedence: bulk > > Just FYI.. Environment was thud.cdrom.com - Bt747C controller and > a Seagate Barracuda formatted as a single 4GB partition: Can you do the same test on a Quantum Grand Prix 4G? It will tell you who makes a better drive for about the same cost :-) :-) Even the 5400RPM 2.1G Quantum Empire out performs this.... > [previous values deleted due to hitting cache] > 4 512 2182402 2767375 > 4 1024 2418337 2917776 > 4 2048 2429280 2999278 > 4 4096 2407492 2999278 > 4 8192 2407492 3033168 > 8 512 2209345 2825636 > 8 1024 2386092 2949840 > 8 2048 2457075 3024624 > 8 4096 2434788 3067833 > 8 8192 2434788 3076624 > 16 512 2213900 2855696 > 16 1024 2454267 2986764 > 16 2048 2434788 2995095 > 16 4096 2454267 3089904 > 16 8192 2445881 3112295 > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD